RE: Delay implementation from scratch and interrupt handlers

ovrebekk — Wed, 15 Jan 2020 14:06:12 GMT

1) I can't really think of any way to improve this other than using interrupts, no. In order to allow the peripherals to run in the background, without blocking code execution, the interrupts are necessary to alert the MCU that an event has occurred.

The best way to set this up using the standard libraries is to use the app_timer module. Then you can schedule a number of callbacks after a certain delay, or set up callbacks to be run repeatedly.
app_timer uses the RTC module which means the current consumption will be very low.

2) Did you find this case?
https://devzone.nordicsemi.com/f/nordic-q-a/172/hardware-interrupt-example

I think the example shared by Håkon is pretty short and concise.

3) Ideally I would recommend the app_timer module, as mentioned earlier. This module has been used by countless customers and is tested thoroughly over time, to make sure it works reliably both with and without a SoftDevice running.

Most interrupt based implementations are reliable as long as the interrupt processing can complete before the next interrupt is about to occur. Put another way, if you expect interrupts every millisecond, and the interrupt processing is delayed by more than a millisecond, then you will normally get into problems.

When using a BLE SoftDevice you should expect interrupts of several hundred microseconds whenever the Bluetooth stack needs to do some critical processing.

Best regards
Torbjørn