Strange Timer granularity issue on nRF53832 project

RE: Strange Timer granularity issue on nRF53832 project

AmbystomaLabs — Wed, 10 May 2017 17:05:39 GMT

If you are trying to get a gpio indication the microsecond the sample is done the above should do it. You can always fork off the task you create to drive the interrupt for a software handler.

RE: Strange Timer granularity issue on nRF53832 project

AmbystomaLabs — Wed, 10 May 2017 16:54:43 GMT

Not sure where Nordic documents it, but keil seemed to know the SAADC event registers. Seems like it should be something like: NRF_SAADC->EVENTS_RESULTDONE So, if you wanted to you can use that to drive the task. Not sure if you'll still be able to have it also drive an interrupt handler at the same time. If you look around in the NRF headers you should be able to find it out for sure how the event is defined. Generally Nordic seems to comment the header files well.

RE: Strange Timer granularity issue on nRF53832 project

RHTPaul — Wed, 10 May 2017 16:44:41 GMT

Mocrosecond resolution timing must be done in hardware using PPI and GPIOTE.

RE: Strange Timer granularity issue on nRF53832 project

AmbystomaLabs — Wed, 10 May 2017 16:35:03 GMT

I'm not sure what function you are trying to implement.

The outcome from the SAADC is a 16bit word, though it could probably get passed via DMA to a communications channel, normally software gets involved to do something with the sample. And, since this means a software handler for the SAADC, you can just trigger your GPIOTE task from there. Or, at that point you really don't need a GPIOTE task you could also just toggle the gpio using the registers.

RE: Strange Timer granularity issue on nRF53832 project

RHTPaul — Wed, 10 May 2017 16:21:23 GMT

I can now successfully use TIMER events to trigger GPIOTE tasks.

Looking at the Nordic SAADC example, I can see how to trigger ADC sampling from a TIMER event.

However, I cannot find anything to get an event from SAADC to trigger a GPIOTE task. Is this possible? If so, how do you do it?

RE: Strange Timer granularity issue on nRF53832 project

RHTPaul — Tue, 09 May 2017 17:39:24 GMT

OK I used the Nordic gpiote example as a basis and hacked it into my test project to toggle a debug pin when the events for two timer compare registers are reached. I can now get intervals that correcrtly track the intervals I am trying to set. I now have confidence that AmbystomalLabs is absolutely correct in asserting thatr it is necessary to use PPI/GPIOTE to get accurate intervals in the microsecond range.

I will now need to integrate such functionality into the handling of the control signals I am trying to control. Since I need to turn on and off multiple GPIO lines and, perhaps integrate this with triggering the capture of some ADC samples and turn control signals on and off when the ADC sample event occurs, I am somewhat daunted by this being new to using PPI and GPIOTE. Accordingly, I would be most grateful if anyone can provide more documentation on the use of this functionality (Nordic are execellent at documenting individaul calls and the like, but, in my opinion, not very good at documenting how to use the calls) or provide more complex examples than this simple Nordic GPIOTE example, I would be most grateful.

Thanks in advance for any additional help anyone can provide.

RE: Strange Timer granularity issue on nRF53832 project

AmbystomaLabs — Tue, 09 May 2017 14:10:15 GMT

You can't do that and have microsecond switching. An interrupt service request takes quite a while for a processor to handle. 12 cycles according to Turbo, but even more depending on how many local variables are in use when the request happens. The only way to do this is completely within ppi/gpiote (ie, hardware).

RE: Strange Timer granularity issue on nRF53832 project

RHTPaul — Tue, 09 May 2017 13:45:18 GMT

Yes I am toggling in the event handler and I do not have a softdevice in the project I am looking at.

RE: Strange Timer granularity issue on nRF53832 project

Turbo J — Mon, 08 May 2017 22:29:34 GMT

Are you toggeling in the Timer_IRQhandler? An IRQ handler needs at least 12 clock cycles (64 MHz main clock) for interrupt entry and exit each - and some more µs with the softdevice. Your 45 µs sounds about right when a softdevice is present.

RE: Strange Timer granularity issue on nRF53832 project

AmbystomaLabs — Mon, 08 May 2017 20:27:37 GMT

This is being done fully in PPI/GPIOTE correct? You are not using the events to drive a software handler, right?