How to run low-latency tasks?

[Alex]

I need to use a nRF52 chip to handle interrupts with low (and known) latency.  Basically, there are specific ~100 us long intervals during which I need interrupt latency to be in the 1 us range.  These intervals happen on an irregular (but known in advance) schedule, ~1-200 times per second.  The interrupt handlers are very fast, also 1 us range, to reset timers and/or flip a couple of GPIO pins.  The Bluetooth radio should be able to maintain a connection; it is okay to (deliberately) drop some packets to accomplish this.  Additionally, if I know when the CPU would be needed for Bluetooth I can schedule around that.

I looked at doing something similar a few years ago on nRF51 and found there was simply no way to guarantee short latency; with a Bluetooth connection active, a task that is supposed to run every 1ms would not run for 3-6ms once in a while.

Could you please let me know how nRF52 behaves in this regard?  Is it possible to briefly reserve the CPU for user code during an active connection?  Alternately, is it possible to check with an API call when the Bluetooth stack will next need the CPU, and for how long?

Best,

Alex

[Turbo J]

Alex said:

to reset timers and/or flip a couple of GPIO pins

Sounds like it could be done in hardware via PPI channels (see GPIOTE, PPI and Timer Tasks/Events) - without using CPU interrupts.

There is a radio notification event handler library. This would call an application event handler X ms (see NRF_RADIO_NOTIFICATION_DISTANCES) before the actual radio usage.

[Alex]

Thank you, this looks quite interesting. 

Does the radio notification happen before radio usage, or before any non-interruptible CPU usage by the softdevice?  (is there even a difference between these two - ie does the softdevice ever reserve the CPU in a way that does not call this event handler?)

[Einar Thorsrud]

Hi,

Radio notification only informs you when the radio is in use (such as when there is a BLE connectinon event). You should probably use the timeslot API instead if you need some time where the application is guaranteed to not be interrupted.

[Alex]

Hello Einar - Thanks, I'll try that.

Could you please confirm that the timeslot API **guarantees** no interruptions?

Per Dimitry's reply below that seems to not be the case.

Best,

Alex

[Einar Thorsrud]

Hi Alex,

Yes, if you are granted a timeslot by the SoftDevice, you are also guaranteed that there will not be any SoftDevice interrupt for that duration. Other interrupts that you manage yourself could, of course, happen if you have them enabled, but that is all up to the application to handle.

[Dmitry]

Einar Thorsrud said:

Yes, if you are granted a timeslot by the SoftDevice, you are also guaranteed that there will not be any SoftDevice interrupt for that duration.

I can confirm this. My below message regarding slot scheduler - there's no guarantee that we will obtain a slot at required time, moreover, already sheduled slot may be canceled afterwards. The only solution I found is to set high local latency (BLE_GAP_OPT_LOCAL_CONN_LATENCY) for the time when I'm working with time-critical peripheral, then switch it back to 0.