Discussing FreeRTOS architecture for sort of a data logger application

Ask QuestionAsked yesterdayActive todayViewed 150 times2

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 some sort of a display component be it LCD, and how it works is a request is sent over BLE from an app, which is processed by the MCU, 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 requests coming over BLE from an app
• Process the request in either TaskA or a different task (?), and obtain the desired data and put it in queueB.
• 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. Is the use of RTOS justified? If not, what else could 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 wellembeddedfreertosrtosShareCiteEditFollowFlagedited yesterdayasked yesterdayJazzy2133 bronze badges

• 3please ask a specific, answerable question … this site is not meant for braistorming – jsotola yesterday
• 1I’m confused. You have inputs coming from BLE and then you “send it out” over BLE. What’s the point of just sending it right back? Or are these two different BLE source/sinks? It would help a lot if you would be willing to discuss more details about what exactly you are trying to do. And no, an RTOS is not a saws-all nor does what you describe necessarily require anything even similar to FreeRTOS. More details would help a great deal. – jonk yesterday
• 1So, much as I like discussion and opinion, StackExchange wants a clear question which maps to a clear answer. So this isn’t the place for your question as posed (www.reddit.com/r/ece, however…). If you could rephrase your question into something that could have a definitive answer, that would work. (And: (1) while the app is pretty small for an RTOS, it’s not a bad thing to put under an RTOS; and (2) your TaskB and TaskC may both be reading data from the queue at the same time — so you’d need a mechanism to deal with that). – TimWescott yesterday
• 1@jonk – sorry for the confusion. I have updated the description. Let me know if it’s still unclear – Jazzy yesterday
• 1@TimWescott – thanks for the suggestion. My main concern being whether my idea and usage of RTOS in this context make sense and if not, what could be done instead – Jazzy yesterday

Add a comment  |  Show 18 more comments

2 Answers

ActiveOldestVotes2

First off, good choice of using FreeRTOS, I’ve used several RTOS and FreeRTOS is by far the most stable and perhaps the best-written code of any embedded library I’ve seen so far.

Although the downside of an RTOS is that it will take you some processing from the MCU, and the task switch has a computing cost (delay). That is why it is better used on some fairly powerful MCUs.

Don’t imagine that an RTOS will make your MCU faster, especially if you need to handle a graphic library and a display. It allows, however, to write much cleaner and modular code and handle systems of larger complexity.

Don’t forget that despite you can have multiple tasks, only one can execute at a time, when a task switch occurs, the stack memory will be copied and this has a processing cost that is not negligible.

In your situation, you only have 3 things to achieve which are reading the sensor, updating the display, and sending the data over Bluetooth, which is not so many tasks, and is fairly simple, perhaps simpler to achieve without an RTOS. Using an RTOS may be overkill for that application and will introduce delays in your system. I personally wouldn’t use an RTOS for that application.

However, if you wish to use an RTOS, your general vision is fine, the tricky part is about the task priorities and when to switch tasks, this mostly depends on your application.

We can guess that the display update probably can be the lowest priority.

Then it really depends on what the data are used for. If you are doing some sort of monitoring and you don’t want to lose any data, you can set up the sensor read as the higher priority hand have a large queue. Depending on the sensor you use, if you can generate an interrupt from the sensor when you have data (like a Ready pin, or a timer) you can then use an interrupt outside the RTOS to write the data in a buffer or in DMA memory, then use a CRITICAL section in the RTOS to copy the data. You can also use double buffer implementation with a MUTEX and this sort of thing.

On the other hand, if you wish to have low latency to the app and don’t care about sometimes losing data, you can set the BLE task as the highest priority.

Implementation is really dependant of what you want to achieve.

Edit Add: When to use an RTOS: Basically when you have an MCU handling several logic tasks of different nature, and you want non-blocking code.

Before Rtos, this was mostly done by state machine architecture. However, state machine architecture is difficult to maintain, and easily ends up in disaster, like the microchip harmony stack which is all state machine based, it becomes a huge mess as you start to have several libraries. Rtos allows a much cleaner way to handle that kind of needs, and allows to cleanly separate the code and is way more manageable, especially when you have a lot of code.

It is also much simpler to write non blocking code with an rtos than state machine or callbacks as you can just write blocking code and call the task switch function on the blocking parts of the code, which allows to have a readable flow.ShareCiteEditFollowFlagedited 16 hours agoanswered yesterdayDamien5,67211 gold badge99 silver badges2525 bronze badges

• 1thanks a lot for your clear explanation. I understand this application is fairly simple but my main goal is really to get a better grasp of RTOS. If you have any other ideas to justify RTOS, please feel free to share! For sensors, I’d most likely be using interrupts so every time there’s an interrupt, a callback would be invoked which would copy the data into a circular buffer and then passed into an RTOS queue. CRITICAL SECTION because the buffer is also being passed to the RTOS queue and we don’t want to corrupt the data while it’s being used inside, say, xQueueGenericSend()? – Jazzy yesterday 
• 1FreeRTOS has specific functions to pass data to queues directly from interrupts xQueueSendFromISR freertos.org/a00119.html also in your case you can use queue peek function to avoid semaphores, you just need to check whether the queue has data. – Damien yesterday 
• determining whether the queue has the data could be achieved via xQueueReceive() right? I could have that in a sensor task that waits on the queue that’s supposed to take in the user request. Can you also confirm whether CRITICAL SECTION is going to be needed to avoid the corruption of the buffer? What would be a potential scenario? – Jazzy 16 hours ago
• xQueueReceive() will pull data from the queue, peek will tell you if the queue has data, all depending how you write your code, both can be OK. If you use the rtos functions you do not need critical. – Damien 16 hours ago
• are you implying there’s no need to explicitly use taskENTER_CRITICAL because that’s already taken care of by RTOS APIs? – Jazzy 14 hours ago
• Yes @Jazzy. taskENTER_CRITICAL is kind of the nuclear option to disable task switch and interrupts. If you use the queues and semaphores, you don’t need to use it. You may want to use it if you copy data from non RTOS functions, or have sensitive communication that should not be interrupted. – Damien 2 hours ago

Add a comment-3

Question

How can a MCU based FreeRTOS talk to a smart phone through BlueTooth to get sensor data?

Answer

Contents

Part 1 – Short Answer

Part 2 – TL;DR Long Answer

References

Appendices

Part 1 – Short Answer

(1) Introduction

1.1 Prerequisite and Recommended Reading

This answer is for newbies who has no previous experience with RTOS (Real Time Operating Systems) and very little knowledge and skills in the following:

(a) “process” concepts, such as multi-tasking/multi-threading/multi-processing,

(b) “processing synchronizing/locking concepts, such as seamaphore, critical section, mutex, coroutines etc.

I would recommend the newbies to read the following *free Operating Systems eBook:

Operating System Concepts, 8th Ed (The Free Electronic PDF “Dinosaur” OS book 980+ pages!), Silberchatz 2009,

paying particular attention on the following chapters:

Ch 3 – Process Concept (pipes, interprocess communication),

Ch 4 – Multi-threaded Programming (for multi-core systems),

Ch 5 – Process Scheduling (virtual machine scheduling and multithreaded, multicore architectures etc),

Ch 6 – Synchronization (mutual exclusion locks etc)

1.2 Practice makes thing clear

Multiprocessing and/or event programming stuff is very hard to develop and debug. For newbies, I strong recommend NOT to dive into any RTOS but be humble to start with writing python multi-processing toy programs. A good getting started is the python multiprocessing library/module, which you can import into the very newbie friendly Thonny Python IDE (more about this later).

1.3 Which MCU to use

For those who are not familiar with modern MCUs, I would recommend to watch the MCU comparison YouTube by the Swiss guy Andreas Spiess:

After watching the Swiss guy’s MCU review, I think it is a good idea for newbies to dip their fee wet into Rpi Pico + Thonny IDE + MicroPython. I would also recommend to use WinPC over Rpi/ESP as the host machine.

My recommendation is based on playing with Pico and MicroPython and learnt from the Rpi Foundation’s newbie tutorial on the following:

(1) Blinking a LED (using interrupt), reading a push button,

(2) Using on board 12 bit ADC and also external sensor DS18B20,

(3) Two two core (PIO) Programmable I/O programming with NeoPixel RGB LED strips.

(4) DC motor drivers

1.4 Incremental Learning Plan

The Swiss guy Spiess mentioned that he spent 4 hour struggling with Pico C++ SDK. The other RUST expert Jonathan Tan mention that he knew how to blink a LED. RUST base FreeRTOS seems not yet very mature in Pico. So I would recommend newbies not to start with Pico C++ or RUSt, but be humble and play with barebone python programs on multi-processing (yes, playing with interrupt to blink a LED is already multiprocessing). So I would recommend to eat the big elephant bite by bite, in three big bites.

(1) Win10 PC Thonny python IDE and Rpi Pico (for newbies)

(2) Rpi4B and Rpi Pico C++ SDK (ninjas only)

(3) Rpi Pcio RUST FreeRTOS (hackers only)

1.5 Learning Rpi Pico MicroPython Multiprocessing Programming

How to use the two Cores of the Pi Pico (for multi-processing)? And how fast are Interrupts? – Andreas Spiess

Another good newbie friendly video to learn Pico based FreeRTOS is also from the Swiss guy Spiess. This video shows how to use MicroPython to write a very simple two core/thread program to do multiprocessing using an interruptable button to blink a LED. In other words, you don’t need FreeRTOS to learn or appreciate the very basic idea of multiprocessing in RTOS, with the limitation of only two threads/processes are allowed in the demo program. Ah yes, 64-bit Rpi4B with 4 cores can do 4 processes in real time, and more than 4 processes “a bit slower” using a process queue/pool.

/ to continue, …

Part 2 – Long TL;DR Answer

References

(1) Operating System Concepts, 8th Ed (The Free Electronic PDF “Dinosaur” OS book 980+ pages!), Silberchatz 2009

(2) The Python 3.9 Standard Library » Concurrent Execution » multiprocessing — Process-based parallelism

(3) Rpi Pico vs ESP32 and STM32 (15 min YouTube) – Andreas Spiess 2021jan31

(4) Rust, RT-Thread OS & FreeRTOS come to the Raspberry Pi Pico – Jonathan Tan, SeeedStudio 2021Jan

(5) FreeRTOS – Wikipedia

(6) FreeRTOS Real-time operating system for microcontrollers Home page and down load – FreeRTOS

(7) Rpi Pico vs ESP32 and STM32 – Andreas Spiess, 2021jan31, 190,293 views

(8) How to use the two Cores of the Pi Pico (15 minutes YouTube video)? And how fast are Interrupts? – Andreas Spiess

Appendices

Appendix A – Wikipedia’s short introduction to FreeRTOS

1. Introduction

FreeRTOS is a real-time operating system kernel for embedded devices that has been ported to 35 microcontroller platforms. It is distributed under the MIT License.

2. Implementation

FreeRTOS is designed to be small and simple. The kernel itself consists of only three C files. To make the code readable, easy to port, and maintainable, it is written mostly in C, but there are a few assembly functions included where needed (mostly in architecture-specific scheduler routines).

FreeRTOS provides methods for multiple threads or tasks, mutexes, semaphores and software timers. A tick-less mode is provided for low power applications. Thread priorities are supported. FreeRTOS applications can be completely statically allocated. Alternatively RTOS objects can be dynamically allocated with five schemes of memory allocation.

3. Key features

Small memory footprint, low overhead, and fast execution.

Tick-less option for low power applications.

Intended for both hobbyists and professional developers working on commercial products.

Scheduler can be configured for both preemptive or cooperative operation.

Coroutine support (coroutines in FreeRTOS are simple and lightweight tasks with limited use of the call stack)

Trace support through generic trace macros, including task scheduling and kernel calls for semaphore and queue operations.

Appendix B – Getting Started with newbie friendly FreeRTOS tutorials

My learning plan is summarized below.

1. Skim Arduino FreeRTOS tutorials to get a rough idea of what sort of multliprocessing stuff they usually recommend, eg. interrupt, semaphore, mutex etc. Then write some newbie demo programs using Rpi4B and Rpi Pico using the same stuff: semaphore, mutex etc
2. Following the Swiss guy Andreas Spiess’s YouTube video tutorial, write a 2 core/two process Rpi Thonny Python/Rpi Pico MicroPython multiprocessing demo program, illustrating the use of (a) Interrupt, (b) Semaphore, (c) Process queue/pool to do the following event driven program:

(i) any one of two buttons pressed would cause an interrupt routine to setup a semaphore and blink a LED 3 times,

(ii) while the button service is in progress, no further interrupt from the other button will be serviced.

(iii) when the blinking service is completed, locked semaphore will be released, and all interrupt will be entertained again.

This two processes program using Interrupt and Semaphore can be seen as a very very oversimplified portion of RTOS. So when the real RUST FreeRTOs ofr Rpi Pico arrives, hopefully in a couple of months time, this demo program can be used as a starting started test of the FreeRTOS.

/ to continue, …

ShareCiteEditDeleteFlagedited just nowanswered yesterdaytlfong011,61711 gold badge66 silver badges1111 bronze badges

• 1I fail to appreciate those who down-vote considerable efforts without the slightest effort made to add comments or reasons or suggest improvements. Those users are simply lazy and judgemental with a problem on the mental side. – Tony Stewart Sunnyskyguy EE75 19 hours ago
• 2@TonyStewartSunnyskyguyEE75 Multiple people have made multiple comments across multiple very similar posts, which aren’t being heeded. Eventually it gets boring. Considerable effort isn’t, in and of itself, worthwile. – awjlogan 18 hours ago
• 1Yet if one can be negatively judgemental, it doesn’t take much effort to comment – Tony Stewart Sunnyskyguy EE75 18 hours ago
• 1@TonyStewartSunnyskyguyEE75 Of course, agreed 🙂 Shouldn’t have to comment for the n-th time either, but such is life! – awjlogan 17 hours ago
• 2This answer looks like copy paste of different random website and confuses multiprocessing and rtos which are not related, rtos generally does not support multiprocessing and this answer will add confusion to understanding what an rtos actually is. Rtos does not have processes, pipes and so forth… Author clearly does not know what an rtos is. – Damien 16 hours ago 

Add a comment