Concurrency, mutexes, scheduler...

[Elm]

Hi,

I am writing an application on top of NRF51, using a S130 Softdevice. I wonder about the concurrenceness (?) of the code I write, and especially if I need to use critical sections, mutexes (muticies?) or similar to protect critical sections in the application.

The application functions are called:

1. when BLE events occur, using a handler supplied to softdevice_ble_evt_handler_set(),
2. application timers, created by app_timer_create(),
3. button presses using a handler supplied to bsp_init().

Also, the application is using the scheduler, started by APP_SCHED_INIT()

My question is: Can any of my functions be interrupted by any of my functions?

If so, I need to protect critical sections myself. If not, Nordic has taken care of that for me, which would be splendid!

Also, is this documented somewhere?

regards, Elm

[Anders Strand]

The softdevice will take of all timing critical BLE protocol business. It will do this in high priority, and will therefore interrupt anything that you might be doing. These interrupts are periodically based on various parameters, and last between a couple of us to a couple of ms at the most.

Check out the infocenter page on processor availability when using a softdevice. It describes the different interrupt priorities in the system.

1. Ble events are run from a software interrupt with priority APP_LOW.
2. Application timer priority is set at initiation, either APP_LOW or APP_HIGH. Default (and recommended is APP_LOW). A timer event with APP_LOW will be queued after a BLE event in progress (which is also at APP_LOW).
3. Buttons can also be assigned priority, but i recommend APP_LOW (default).

If you use APP_HIGH for anything, it will not interrupt BLE transmissions, but it will interrupt processing of BLE packets and in that way impact BLE performance. Only use this priority for very short and important tasks. None of your APP_LOW tasks will interrupt one another.

If you are using the app_scheduler, you put events in a queue and execute them from main() context, which is the lowest priority. This is a good thing to do in most cases, unless something has to happen right away. The app_scheduler is documented here.

If you design you application correctly, i do not see any need for mutexes or critical sections. The tasks that interrupt you (the softdevice) will not use any common resources with your application.

-Anders

[Elm]

Thanks a lot. This is exactly what I hoped for. The scheduler makes my application a lot less complex. :-)