I’m fairly new to RTOS architecture and been reading up on articles on FreeRTOS.org, but as it’s commonly agreed, practice clears things up even more.
I have a basic project idea which I’d ideally want to be RTOS-based as I’ll explain below along with some questions:
My understanding is RTOS comes in handy when you’re computing multiple tasks concurrently. Based on that, I came up with the idea which involves a BLE-supported MCU, sensors, BLE-supported app, and a display component.
Working:
A request is sent over BLE from an app (acting as a central), which is processed by the MCU (acting as a peripheral), and does the following concurrently:
- sending the data from the desired sensor back to the app over BLE
- updating the display with the value on an LCD
In an RTOS context, I’d then have:
-
TaskA - constantly reads the inputs coming over BLE from an app using a blocking call
xQueueReceive()
-
Process the request in either
TaskA
or a different task (?), and obtain the desired data and put it inqueueB
. -
TaskB - as soon as
queueB
is no longer empty, send the data out to the app over BLE -
TaskC - as soon as
queueB
is no longer empty, update the display with the data
I think with this approach, there isn’t any shared data that I need to worry about locking mechanisms…unless I’m missing something. Does the idea sound okay? I’m afraid I’m RTOS isn’t justified and if so, what could else be done?
A usecase:
I have a BLE-compatible phone (acting as a central) with an app that’s connected to, say, the BLE of nRF52 (acting as a peripheral). After the connection, the user wants to retrieve some information from sensorA
, so they send out “A”, which is received by the peripheral device, processes it, and responds back to the central with the desired data which was requested, and at the same time, the LCD display is updated with the data as well