Discussing FreeRTOS architecture for sort of a data logger application

Ask QuestionAsked todayActive todayViewed 51 times0

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 1 hour agoasked 5 hours agoJazzy111 bronze badge

• 2please ask a specific, answerable question … this site is not meant for braistorming – jsotola 4 hours ago
• 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 4 hours ago
• 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 3 hours ago
• 1@jonk – sorry for the confusion. I have updated the description. Let me know if it’s still unclear – Jazzy 3 hours ago
• 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 3 hours ago
• For the most part, what you describe is event driven. Depending on the timing requirements, i see no specific reason for using an RTOS. – Kartman 3 hours ago
• 1@Kartman any way this could be made so RTOS’ is justified? – Jazzy 3 hours ago
• 1If you want to get some mileage with FreeRTOS, go for it. In general, though, if everything has roughly the same response time you can just use a superloop. Where you really need an RTOS is if you have very different response times in play — e.g., a motor control loop that needs to respond in 1ms, running on a processor with a human interface that can take 50ms to respond. – TimWescott 3 hours ago
• 1from my understanding, as long as things are sequential, you’re fine without RTOS but if you want to be doing multiple things around the same time, you may wanna consider RTOS, no? – Jazzy 3 hours ago
• 1‘Same time’ – concurrency on a single cpu is an illusion- Only one task executes at a given time. Multitasking is achieved by swapping tasks co- operatively or pre-emptively. An RTOS gives you a franework for managing this and methods to schedule and manage inter-process communications. It is a common solution but there is a cost in overhead with memory (data and code) and execution time. For larger projects this is justified. It may be overkill for small projects. – Kartman 2 hours ago
• 1that’s why I said “around the same time”. You’re right. – Jazzy 2 hours ago
• @Jazzy Kartman is talking to you about the way I would. An O/S on a single cpu core will only execute one thing at a time. Ever. Perhaps the simplest and most important addition an O/S can offer is separate stacks as most languages don’t offer it. This allows two different threads to appear isolated in the sense of call parameters and return values. That’s NOT a win in terms of performance or real-time behavior. It IS a win in terms of avoiding spaghetti-code and improving the maintainability of your application. – jonk 2 hours ago
• 1@Jazzy The next most important thing an O/S might provide is pre-emption. Separate stacks alone can be handled in a “co-operative” way without pre-emption. Which is a lot safer and easier to implement as you don’t have to worry about static state of library functions, for example. But pre-emption provides the ability to interrupt a thread, suspend it for a moment, and run start a different thread at the point it was last interrupted. Pre-emption can be useful for time-critical threads. But again, the price is all of the static state saving and restoring time. So it’s still not faster. – jonk 2 hours ago
• 1@Jazzy Pretty much, most of what an O/S buys you is about keeping threads or processes relatively isolated (not co-mingled) and therefore simple to read, to write, and to maintain. Up to a point, anyway. At some point, the O/S itself has such a high learning curve and so many functions you need to call, that your code can become quite difficult, again. Microsoft’s .NET Core 5 would be such an example. Then, it’s about all the software stacks and massive libraries you get that make the trade-off worth the trouble, once again. An O/S is not a panacea. You just need to understand your needs well. – jonk 1 hour ago
• 1@jonk – yes, I understand that aspect and I never really meant or said that tasks execute at exactly the same time, and rather around the same time. Sorry, I should’ve been more clear but that wasn’t really a concern. – Jazzy 1 hour ago
• 1@Jazzy I’d recommend learning how to set up separate stacks and perform cooperative switching. This means one data structure and one assembly routine called switch(). It can take you easily less than a day to write (half-hour if you have the compiler manual’s section on mixed code already in front of you.) Perhaps the best book on the topic is this one by Douglas Comer. (DO NOT BUY A NEWER VERSION! ONLY THIS ONE!) – jonk 1 hour ago
• 1Many people get confused in this regard. That is why we’ve been explicit. In terms of tasks, think how a chworks- he’ll set the water to boil, whilst that is happening he’ll chop the carrots, when that is done, check the water otherwise prepare the peas. Other tasks are performed whilst waiting for something else. Eg a keypress. To read the key press takes microseconds, but the user might press it every 200ms. No use sitting in a loop to wait. – Kartman 1 hour ago
• @Jazzy, your “question” is interesting but confusing, though I agree with you saying that “practice clears things up”. I am curious which RTOS stuff you have been reading. Sometime ago I read this interesting article of placing FreeRTOS inside Rpi Pico: (1) Rust, RT-Thread OS & FreeRTOS come to the Raspberry Pi Pico By Jonathan Tan – Seeedstudio 2021jan seeedstudio.com/blog/2021/02/05/…, / to continue, … – tlfong01 1 hour ago   
• @Jazzy, I read the above comments and also found things confusing, because I have forgotten all the OS concepts I learned ages ago. So I googled for a free ebook to refresh my memory. I was happy to have googled one of my old favorite OS books, the “Dinosaur OS Book” . (2) Operating System Concepts, 8th Ed (The Free Electronic PDF “Dinosaur” OS book 980+ pages), Silberchatz 2009 uobabylon.edu.iq/download/M.S%202013-2014/…. / to continue, … – tlfong01 59 mins ago   
• @Jazzy, so I skimmed the dinosaur book and focused on the following: Ch 3, Process Concept (pipes, interprocess communication), Ch 4, Multithreaded Programming (for multi-core systems), Ch 5, Process Scheduling (virtual machine scheduling and multithreaded, multicore architectures etc), Ch 6, Synchronization (mutual exclusion locks etc). / to continue, … – tlfong01 41 mins ago   
• @Jazzy, now I have a brainstorming suggestion for the title of your question: “”How can a MCU based FreeRTOS talk to a smart phone through BlueTooth to get sensor data?. Ah, locking down lunch time. See you later. – tlfong01 25 mins ago    
• @Jazzy, and now I am thinking of which MCU to use. Just now I watch the following YT to get a rough idea of what might be a good choice: Rpi Pico vs ESP32 and STM32 – Andreas Spiess 2021jan31 youtube.com/watch?v=cVHCllbN3bQ, Contents: Intro, What we will compare, Competitors, The Ecosystem, The role of ARM (and RISC-V), Start of comparison, The Cores/PIO/Memory, The Pins/ADC/DMA, USB/MicroPython/Thonny/Debugging, 10:35​ Wi-Fi and BLE, Power Consumption/Deep-Sleep/Powering Options, Price, 13:17 My Verdict, Outro. / to continue, … – tlfong01 4 mins ago    Edit   

Add a comment

1 Answer

ActiveOldestVotes0

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.ShareCiteEditFollowFlaganswered 1 hour agoDamien5,64511 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 43 mins ago 

Add a comment