nRF52 scheduler

RE: nRF52 scheduler

Einar Thorsrud — Mon, 19 Sep 2016 07:03:11 GMT

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.

RE: nRF52 scheduler

Einar Thorsrud — Mon, 19 Sep 2016 06:50:48 GMT

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.

RE: nRF52 scheduler

Tosa — Sat, 17 Sep 2016 19:20:12 GMT

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!

RE: nRF52 scheduler

Tosa — Thu, 15 Sep 2016 20:53:46 GMT

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?

RE: nRF52 scheduler

Einar Thorsrud — Thu, 15 Sep 2016 05:53:46 GMT

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.