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.

[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.