FreeRTOS BLE architecture questions - SDK 14.0.0

[leonhart88]

Hi All,

I have a general question about the FreeRTOS implementation for SDK 14.0.0.

I've added FreeRTOS onto a basic UART BLE peripheral example that I wrote.  I referenced the HRS FreeRTOS example that comes with the SDK in order to add FreeRTOS to my example.  The code seems to be working and I can connect and communicate with my device as before once I migrated some things to FreeRTOS (eg. nrf_sdh_freertos_init()).

I have some general architecture questions though:

• From my understanding, the soft device gets put into its own task.  However, what about the service handlers or any of the BLE/advertising handlers which normally reside in functions defined in the main.c file? Are these technically running on the soft device thread/task as well?
  
  
• Prior to using FreeRTOS, I would set a flag in, say, the UART service handler once data was received, and this was processed in the while loop in main.  If I am now using FreeRTOS I know I'll need to move that processing code over to a separate task.  However, does this mean that the flags set in my BLE handlers need to be put into semaphores now so that my processing task can access the flag?  Or keep the flag as a global variable but use mutexes to access them?

If there is any documentation detailing this a bit more, please let me know!  Thanks!

[Susheel Nuguru]

Hi Philip,

Using FreeRTOS with BLE is a special case. Our softdevice will always run with highest priority. Which means that the FreeRTOS kernel is running as an application on top of softdevice. The task that you mention is created for BLE activity in the example is to process the BLE events. Since softdevice runs out of FreeRTOS scope. Which means that FreeRTOS does not have any clue about the softdevice activity, since softdevice runs not as a FreeRTOS thread, but within its own interrupt context.

This might be little confusing to digest at the first, but please ask me more questions if this is the case. 

About the flags, Yes, trying to communicate between threads, using semaphores will be a good way instead of using a global flags. When you have inherited the nicer features by using an RTOS then use those features instead of the basic flag. With flags, you need to add the complexity of protecting it in multicontext, with semaphores, you do not need to worry about that.

[leonhart88]

Thanks Aryan.  So all the BLE events & handlers are executed in the BLE task that is created, correct?

And in reference to the flags, I agree that I might as well use semaphores since I have that ability.  However, are set and check operations of boolean flags atomic in the system?  Just curious if they are inherently thread safe or not.

Thanks!

[Susheel Nuguru]

You are correct about the BLE task.

set might be atomic for boolean but check is definitely not as it needs atleast two instructions. (one for loading the value in register and the other for comparing)

[leonhart88]

OK thanks!