RE: Soft device intro

RK — Sun, 18 Sep 2016 01:06:38 GMT

Yes all the softdevice operations are executed in interrupt context. In fact you can consider the softdevice an entirely separate process running on the device, separate from your application code. When the app wants to perform a softdevice function it calls one of the API methods and that just executes an interrupt-type instruction which passes control to the softdevice. Similarly when the softdevice has events for the app to process, it triggers a software interrupt which your app code processes. The Nordic SDK has a standard module which most people use for capturing BLE events, but you can write your own if you like, it's just an interrupt handler in the end.

Internally the softdevice runs a number of peripherals, radio, a timer or two + more and those interrupts trigger it to do things, the critical softdevice operations run at a higher priority than anything else, to ensure that BLE timing is maintained.

That do-nothing power_manage() loop is again a standard in the Nordic examples because most events are triggered asynchronously by interrupts of one sort or another, so there's really nothing for the main context to do. You will find some which do work there however, for instance there's a simple event dispatch module where you enqueue events as responses to interrupts, but actually process them later in the main loop, in a case like that the main loop would feed the event system each time it wakes up.

There are other options too, there's several RTOS supported if you like using those, look over on the right-hand column of this page for the Blog entries, someone just wrote a nice one about available RTOSes.

I'm sure you'll like the Nordic stuff as much as, or more than, the TI BLE when you get to know your way around, I always found the TI stuff rather opaque, the Nordic SDK is a bit more verbose, but you can always drill down and figure out what it's doing.