About PPI priorities

RE: About PPI priorities

Stefan Birnir Sverrisson — Fri, 17 Jun 2016 12:23:49 GMT

The designer says that it should work the same every time at least. There should be no race condition. So if you have it working already, it should do that reliably all the time.

RE: About PPI priorities

tellg — Wed, 08 Jun 2016 11:21:01 GMT

Hello

I have a similar usage on the nRF52: TIMER CAPTURE and TIMER CLEAR as shown below

NRF_PPI->CH[0].EEP = (uint32_t)&NRF_GPIOTE->EVENTS_IN[0];
NRF_PPI->CH[0].TEP = (uint32_t)&NRF_TIMER1->TASKS_CAPTURE[0];
NRF_PPI->FORK[0].TEP = (uint32_t)&NRF_TIMER1->TASKS_CLEAR;

// Enable PPI channel 0
NRF_PPI->CHEN = (PPI_CHEN_CH0_Enabled << PPI_CHEN_CH0_Pos);

The nRF52 ref manual does not say anything on priorities between CAPTURE and CLEAR tasks Will I risk losing the capture on the nRF52 (silicon rev 1) ?

At least on my development kit, PCA10040 V1.1.0, the capture works fine

RE: About PPI priorities

Ole Morten — Wed, 05 Feb 2014 10:01:24 GMT

Yes, this is as designed and hence expected to be consistent on the XLR2 chip revision. I agree that this information should be in the RM, so I'll create a task internally to add this information in a future version.

For now, I'd as usual be happy if you could accept my reply above as an answer, since I believe that answers the original question. :-)

RE: About PPI priorities

Paul — Tue, 04 Feb 2014 17:33:15 GMT

I agree. If as you have described in the previous response, the PPI happens in the same clock cycle, then it is the task priority related. Official document only describes START and STOP priorities.

Based on my test CAPTURE TASK happens first then the TIMER gets cleared, which is most people would want. If it is always consistent in XLR2 silicon level, then it is great, and should always keep that way :-D.

Thanks

RE: About PPI priorities

Ole Morten — Tue, 04 Feb 2014 17:09:05 GMT

This then becomes a question about the task priority in the TIMER more than priorities in the PPI, but I checked it internally, and it seems that at least with XLR2, you should get a valid value in COMPARE, and a TIMER that is cleared on the next clock cycle. What kind of behavior do you see?

RE: About PPI priorities

Paul — Tue, 04 Feb 2014 16:32:28 GMT

Here is an example: Use a pin change to trigger TIMER CAPTURE and TIMER CLEAR. Is there a guarantee that I can get the TIMER value before it gets cleared?

Thanks

RE: About PPI priorities

Ole Morten — Tue, 04 Feb 2014 16:22:19 GMT

Sorry for the delayed answer, but from a hardware perspective there is no priority difference between the PPI channels. As long as they are all configured before the event happens, the associated task should be triggered within the same 16 MHz clock cycle.

I'm hence having some trouble understanding what you say. If my explanation above does not align with your findings, can you please explain how you test this, and possibly share any code?