using RTOS in ble_app_uart example

[morpho]

Have a few questions about ble_app_uart example.

• From the way I see it, it sets uart_event_handle as the callback, and every time there's an "event" that takes place be it in the form of receiving data, it invokes uart_evt_handler which in turns calls the callback. Is that the basic high level flow?
• I set the breakpoint inside uart_evt_handler but it doesn't get triggered at all. I see there's been issues debugging in softdevice. Is this normal?
• I'm still a bit unfamiliar with event-driven programming but if you were to incorporate RTOS in such an application such that say there's a specific task that's waiting on the data to be received from the app through message queues (which is taken care of by nus_data_handler() currently), and a different task that's dealing with the serial data to be sent, would it be doable? So for instance: if the data is being received from the BLE app, nus_data_handler gets triggered which would then set the flag/write to stream buffer that the freeRTOS task is waiting on...and once that's done, the task will continue processing it. Does this idea sound reasonable or there's a possibility of not using nus_data_handler() instead and the task gets the indication rightaway?

[Susheel Nuguru]

Hi morpho,

From the way I see it, it sets uart_event_handle as the callback, and every time there's an "event" that takes place be it in the form of receiving data, it invokes uart_evt_handler which in turns calls the callback. Is that the basic high level flow?

 Yes, UART_ISR->registered_evt_handler->registered_callback_handler

I set the breakpoint inside uart_evt_handler but it doesn't get triggered at all. I see there's been issues debugging in softdevice. Is this normal?

You cannot step for a longer period of time when softdevice is enabled (unless you are using Monitor Mode Debugging MMD). But breakpoints should be hit if that instruction is being executed by the MCU. Please check if you have the code compiled with no optimizations and with best debugging performance. Also check if the module where you are trying to set the breakpoint is actually included by the linker. Most of the module inclusion are controlled by the  XXX_ENABLED flag in the sdk_config.h file

 

I'm still a bit unfamiliar with event-driven programming but if you were to incorporate RTOS in such an application such that say there's a specific task that's waiting on the data to be received from the app through message queues (which is taken care of by nus_data_handler() currently), and a different task that's dealing with the serial data to be sent, would it be doable? So for instance: if the data is being received from the BLE app, nus_data_handler gets triggered which would then set the flag/write to stream buffer that the freeRTOS task is waiting on...and once that's done, the task will continue processing it. Does this idea sound reasonable or there's a possibility of not using nus_data_handler() instead and the task gets the indication rightaway?

 That is very doable all I see is that you need to introduce the RTOS based signaling mechanism between the two tasks within the nus_data_handler. In short, the event based architecture is not limiting you to use any RTOS on our solutions. There are many customers of Nordic who have developed very simple to quite a complex state machines on top of this event driven system using FreeRTOS.

[morpho]

Is it actually common for most of the vendors to be using the existing UART library provided by nRF as is? I was thinking of implementing a stripped-down version for my own learning purposes and in C++. Any resources shall help alot!

from the looks of it, the generic approach that nordic takes is it registers the user-provided event handler which gets called inside the IRQ handler. So in case of FreeRTOS, an approach would be to set a flag or write to a stream buffer inside the UART handler to indicate another task that's waiting on it, yeah?

[Susheel Nuguru]

morpho said:

Is it actually common for most of the vendors to be using the existing UART library provided by nRF as is? I was thinking of implementing a stripped-down version for my own learning purposes and in C++. Any resources shall help alot!

 Yes, it is very common that product vendors use the drivers/libraries from the SDK as they are, but they are obviously encouraged to change/optimize them as it suits to them. That is one of the reasons we have most of our solution given in source codes. There are few users who tried to make some C++ wrappers around some of our libraries but those things are outside our control. So we cannot suggest you to use them as we do not know their quality. Just search devzone for "c++" to get some hints on this.

morpho said:

So in case of FreeRTOS, an approach would be to set a flag or write to a stream buffer inside the UART handler to indicate another task that's waiting on it, yeah?

 When using RTOS it is better to use inter task communication rather than just using flags to keep it architecturally future proof.