nRF52 scheduler

[Tosa]

I am creating a system (nRF52 SDK11.0.0 s132) that will get a data ready interrupt on a GPIO (configured via GPIOTE with a handler) from a sensor every 4ms. The sensor has an SPI slave interface for reading the data. The handler will either set a flag for that will trigger an SPI data read in the main superloop, use the scheduler to trigger an SPI data read, or trigger an SPI data read directly.

After a number of samples, a data processing function will be run on these samples that takes 10ms to run (a double buffer scheme will be used). Hence the data processing function needs to run in a lower priority context than the data reads, otherwise I will miss samples.

Can I use the scheduler in this scheme, and if so, how do I set the priorities of the data read versus the algorithm tasks? If not, what's the simplest (and robust) way to do this without RTOS?

[Einar Thorsrud]

The way I understand it, the main point is that your algorithm "task" needs to run with a lower priority than the sampling. The scheduler from the SDK does not have a concept of priorities, but you could for example use the scheduler (or another custom mechanism) to move the algorithm to the main context. The sampling and SPI read could be in a higher interrupt priority context, where you handle it directly in the interrupt routine / event handler. Typically you would use the application timer to sample at a regular interval, and the priority would be APP_LOW.

[Tosa]

GPIOTE uses _PRIO_APP_HIGH (=2). If I call the blocking SPI read directly from the GPIOTE handler, will SPI function properly with _PRIO_APP_LOW (=6)? And even if it matches the GPIOTE priority, will it still work since it cannot preempt another interrupt of the same priority? Would the similar concept apply if using the application timer, except that in this case the SPI priority could be set higher than the timer priority?

[Tosa]

Actually I'm using SDK11.0.0 (updated my question to reflect this), but noticed that SDK12.0.0 sets the GPIOTE IRQ priority to 6, so the SPI IRQ priority could be set higher. Einar (or other Nordic employees): any comments? Thanks!

[Einar Thorsrud]

Regarding GPIOTE, the interrupt priority is configurable, and is set in the driver configuration header file. For example, in the GPIOTE example in SDK 11, you can see the following line in the driver configuration file (examples/peripheral/gpiote/config/gpiote_pca10040/):

#define GPIOTE_CONFIG_IRQ_PRIORITY APP_IRQ_PRIORITY_LOW

You can also configure the interrupt priority of the SPI master driver. It is done by setting the irq_priority field of the nrf_drv_spi_config_t struct, that is passed to nrf_drv_spi_init().

You are right that if you have two interrupts of same priority, the first interrupt routine will finish before the second has time to run. A higher priority interrupt on the other hand will result in immediately servicing the new (high priority) interrupt. The ISR of the lower priority interrupt will continue when the higher priority ISR has finished.

You do not have to use blocking SPI reads, particularly, it does not seems sensible to do blocking reads from a interrupt / event handler.

Regarding the application timer, it may not be useful as you anyway get a ready signal from the sensor every time you need to sample data. I must have missed that information when I wrote the initial question.

[Einar Thorsrud]

When using a SoftDevice on the nRF52 there are 4 interrupt priorities available to the application. Though the SDK mostly use only 2, there is support for using all 4, which are defined by the app_irq_priority_t enum.

Another thing which you should remember is that if you have a BLE link active, BLE event will have high priority, and can delay high priority application interrupts. The details about this is found in BLE processor usage patterns.