What's reason to choose an RTOS ?

Thread Starter

aspirea5745

Joined Apr 17, 2019
99
Real time system is system that has hard time constraints. I think if a system is real time system its not mandatory to run RTOS. I would never choose to use an RTOS for single task that needs critical timing. I would like to using interrupt.

What's reason to choose an RTOS ?

Its seems to me that if the system is too large and many task's are time critical , then perhaps RTOS can be used.
 

BobTPH

Joined Jun 5, 2013
3,652
That is correct, you do not need an RTOS to do real time, especially if there is only one task.

RTOS is useful when you have a complex set of tasks that must run concurrently.

For a true real time response , you can’t beat interrupts, either with or without an RTOS.

Bob
 

Yaakov

Joined Jan 27, 2019
3,464
An RTOS manages multiple time critical tasks and allows for simplified code since you can write blocking code in a task without compromising access for other time critical processes.
 

Irving

Joined Jan 30, 2016
2,058
RTOS definitely simplifies/facilitates cross-core communications. While perfectly possible without RTOS, if you have several tasks where you need to deploy them at random times, assign a certain level of priority with a statistically demonstrable allocation of processing time, RTOS is hard to beat. If you have only 1 or 2 event processes and a detailed understanding of how they perform/interact and you want the absolute specific control of how they will be scheduled then roll it yourself.

FreeRTOS gives you lots of useful tools; you don't have to use the scheduler. So robust ring buffers, lists & stacks for instance. I use RTOS on ESP32, 1 core associated with many low/medium speed external events (e.g sampling sensors on various time-frames from 500Hz to 1 per minute - crudely just 1 thread per sensor, triggered by a timer) & the second core associated with CANbus and other comms. Originally was translated from a huge event driven Arduino loop where every 1mS an array of sensors was polled, readings taken from each as necessary by time allocation & placed in a per sensor buffer and then some additional background processing performed before transmission over the CANBus. It was a maintenance nightmare. Now its just one simple templated task/thread per sensor (or somet6imes by sensor type), with a priority setting for each. Adding/removing/upgrading sensors is just so simple now. And scheduling data transmission with mutex across cores makes it much easier to understand and manage.
 

nsaspook

Joined Aug 27, 2009
8,653
Just know what you're getting into with a RTOS. The RTOS abstraction can simplify complex event interactions but it won't simplify complex applications. Even simple RTOS tasks can have complex runtimes that make debugging tricky when looking at code traces. Synchronization deadlocks between tasks with shared data is a classic problem that simple priority based tasks can fall into.

https://www.rapitasystems.com/blog/what-really-happened-software-mars-pathfinder-spacecraft
 

MrChips

Joined Oct 2, 2009
24,143
What is RTOS?

RTOS is a suite of library functions that someone wrote that allows you to run concurrent processes in pseudo-real-time.
It means that you don't have to write these functions yourself.

If you don't use RTOS, you have to write it yourself.
And that is what I do.
 

BobaMosfet

Joined Jul 1, 2009
1,848
Real time system is system that has hard time constraints. I think if a system is real time system its not mandatory to run RTOS. I would never choose to use an RTOS for single task that needs critical timing. I would like to using interrupt.

What's reason to choose an RTOS ?

Its seems to me that if the system is too large and many task's are time critical , then perhaps RTOS can be used.
As I write RTOS kernels for embedded, extremely small and efficient, I wouldn't do any serious project without using one. Because the kernel does all the heavy lifting, my core code winds up being a few lines to handle very complex things, reliably. The key word is _serious_ project.

For me, the power the kernel gives me to handle things simultaneously and interface with any external device easily, far outweighs the 6K of Flash that it takes. Just having a device manager to present a uniform interface for any external adjunct is worth its weight in gold- whether that's an RTC, DRAM, a display, a disk-drive, flashcard, RFID reader/writer, keypad, or any other thing I might want the MCU to talk to, it reduces the overall code I have to write by thousands of lines of code. And it reduces errors, because once a piece of kernel logic is written, and tested, it doesn't need changed. And even if it did, it means my application code doesn't have to compensate for kernel changes, because how the kernel works is opaque to the application (as it should be).
 

BobaMosfet

Joined Jul 1, 2009
1,848
Just know what you're getting into with a RTOS. The RTOS abstraction can simplify complex event interactions but it won't simplify complex applications. Even simple RTOS tasks can have complex runtimes that make debugging tricky when looking at code traces. Synchronization deadlocks between tasks with shared data is a classic problem that simple priority based tasks can fall into.

https://www.rapitasystems.com/blog/what-really-happened-software-mars-pathfinder-spacecraft
Actually, that isn't true. An RTOS can significantly simplify complex applications- that's one of the main reasons to use one. However, the RTOS has to be built correctly. The NASA people today are amateurs. The article you reference sums up the entire problem with this line:

(Engineers later confessed that system resets had occurred during pre-flight tests. They put these down to a hardware glitch and returned to focusing on the mission-critical landing software.)

The error was a logic error that could have easily been prevented if they had understood what 'MISSION CRITICAL' actually menas and flow-charted their code and understood what they were actually doing. The fact that they idiots are using a C intepreter rather than using actual C means that

a) the thing is dead slow compared to what it could be, and
b) they are so primitive in their skillset that they have no idea how to modify binary on the fly to make the changes

Professional Developers never assume. If they witness a problem, they find it, they isolate it, they correct it.

I weep with how far people have falling in technical skill since my time....

:/
 

nsaspook

Joined Aug 27, 2009
8,653
In terms of most embedded aplications without actual process protection, memory isolation or VM (most microcontroller applications seen here) I really don't consider the RTOS kernel abstraction level implementation (threads, semaphores, mutexes, queues, and timers) to be that important in the complexity of a given application. The standardization of hardware interfaces is nice, but it's something that will need to be done on any processing system or IDE beyond a trivial example. The application libraries integrated in a typical RTOS total package are helpful to reduce complexity but those equivalent libraries are implementable without the complete RTOS process abstraction.
 

andrewmm

Joined Feb 25, 2011
1,751
I would like to ask two questions

What has RTOS got to do with your project.?
Where is critical timing involved in your project ?


agree
@aspirea5745

As you imply,
there is no need to ever use an RTOS,
I have seen many systems , some quiet complex, that do not use an RTOS.
after all, an RTOS adds to the amount of code that runs
....BUT...

The advantage of an RTOS in my experience FAR out weigh any reason not to use one

As some one that has to come in and sort out "problems"
I find often that, a reason is that code has been modified over the years by many people.

An RTOS isolates each "process" from each other,

The first time a lot most of us my age heard of an RTOS was on Apollo 11, and the classic error code 1201.
The RTOS saved the flight ,


So personally , I'd always like to see an RTOS on anything that's not just a simple state machine,
 

nsaspook

Joined Aug 27, 2009
8,653
IMO the raw RTOS (something like FreeRTOS ) programming blocking "flowchart" model is outdated with modern embedded hardware and language usage. Blocking superloop threads with mutexes and semaphores are vestiges of a primitive CPU and I/O hardware. It's not that a good RTOS won't work as a improvement over sequential super-loop/interrupt systems, it's just that there are better methods today than the 80's concept of pseudo-concurrent uniprocessor programming at the controller level that's mainly event-driven by I/O registers and dataflow. You can use a raw RTOS to implement event-driven state machine frameworks that don't use the default blocking model.

The absolute lowest latencies and response times are driven by concurrent hardware that only sends events to the processing CPU that changes main processing program 'state' when the critical hardware module sequence is done.
https://www.embedded.com/programming-embedded-systems-the-easy-way-with-state-machines/
 

Yaakov

Joined Jan 27, 2019
3,464
There are many reasons to use an RTOS but one of them that is relevant today reflects the use of MCUs.

Today, MCUs run naïve code written by end users. That is, MCUs are platforms that start out with some code infrastructure (wireless stacks, etc.) and the code that runs on them in user space is written without knowledge of proper realtime code practice.

With an RTOS on a "consumer" MCU, the critical timing sections of the platform code don't rely on good behavior of the user-programmer to get access to CPU and resources. This allows the user-programmer to write what looks to them like blocking code while never actually being able to block the system code.

The value of this shouldn't be underestimated.
 

Irving

Joined Jan 30, 2016
2,058
Teaching non-computer-science graduates on our Biomech Engineering Masters course the rudiments of real-time processing for robotics, prosthetics control, and the like is hard enough as it is, RTOS makes it a lot simpler to get something up and running that can communicate over wifi or BLE. If they ever become commercial I'll worry about the embedded aspects then...
 

BobaMosfet

Joined Jul 1, 2009
1,848
I would like to ask two questions

What has RTOS got to do with your project.?
Where is critical timing involved in your project ?


agree
@aspirea5745 An RTOS provides a platform upon which the application can stand. The sole purpose of any Operating System is to manage resources- that's it. An RTOS provides a means to manage the most important resource: _TIME_ with an arbitrary level of accuracy. Time is the most important aspect of any project. Whether that is accurate time, or simply repeatable time. That is the very foundation of any operating system, and application.

Slicing time into discrete, uniform slices allows decision making between slices. Which allows for events, context switching, idle time, device management, etc. It allows a single processor to appear to be able to reliably do many things simultaneously. And this is without prioritization. If you add the ability to prioritize time-slicing you then can add reliability for tasks that must be performed at regular intervals. This is also why it is important to understand heuristics- timeframes in whcih people work, as well as time-frames in which machines work- and make these many different 'circles of time' work together harmoniously. Many people think prioritization is just establishing the importance of an interrupt- but that isn't so. Prioritization is also designed into understanding the above. Priorities can be inherently established without arbitrary value setting.

Many of my devices are in medical, financial, and biological sectors. Such devices require precise, regular timing depending on what they do, or a number of negative consequences could occur (health, finance, or safety). As all my products are using 8-bit MCUs, the fastest guaranteed resolution for any application interrupt is 1ms, so my RTOS provides more than a dozen prioritizable interrupts at that resolution. Most of my projects run at 16Mhz, or faster.
 

BobaMosfet

Joined Jul 1, 2009
1,848
IMO the raw RTOS (something like FreeRTOS ) programming blocking "flowchart" model is outdated with modern embedded hardware and language usage. Blocking superloop threads with mutexes and semaphores are vestiges of a primitive CPU and I/O hardware. It's not that a good RTOS won't work as a improvement over sequential super-loop/interrupt systems, it's just that there are better methods today than the 80's concept of pseudo-concurrent uniprocessor programming at the controller level that's mainly event-driven by I/O registers and dataflow. You can use a raw RTOS to implement event-driven state machine frameworks that don't use the default blocking model.

The absolute lowest latencies and response times are driven by concurrent hardware that only sends events to the processing CPU that changes main processing program 'state' when the critical hardware module sequence is done.
https://www.embedded.com/programming-embedded-systems-the-easy-way-with-state-machines/
I think most people misunderstand the role of RTOS and STATE machine. RTOS manages time- that's its primary function. An application manages STATE- that is its primary function. And that is the correct way that both an RTOS and a STATE machine interact seemlessly. This concept is not new- this is how it's always been by professional developers who understand how to efficiently work _with_ the machine and not against it.

The majority of people writing code today shouldn't be- they need to go do something else, as coding is NOT (nor will it ever be) where their strengths lie. Contrary to popular opinion, people cannot be anything they want to be with great success. Some people are academics, some people are creatives, and some people dig ditches. And there is no shame in that. Everybody is different. Unfortunately people have an idea (largely due to marketing) that if you don't have a degree you're, stupid. I *hate* this sort of psychological warfare that society uses against people. F! I'd _LOVE_ to be a mathematician.... but that isn't ever going to happen- no matter how much I've tried. IMHO.
 
Top