RE: Concurrency, mutexes, scheduler...

Elm — Thu, 07 Jan 2016 08:24:17 GMT

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

RE: Concurrency, mutexes, scheduler...

Anders Strand — Tue, 05 Jan 2016 15:18:33 GMT

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.

Ble events are run from a software interrupt with priority APP_LOW.
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).
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