I ported RTEMS on a 68k family microcontroller in 1997 for my computer science thesis, as part of a larger project. It was quite easy to work with, as I remember.
They dropped the ball with the acronym though. Call it "A Real-Time Executive for Multiprocessor Information Systems (ARTEMIS), and then cue in all the cool Greek mythology puns about hunting goddesses and deer and swift reflexes and whatnot :p
Linux real-time has existed for many years, but it's still Linux. That means that it's a big, underspecified project. RTEMS is designed for high reliability embedded environments, especially spaceflight. These systems are smaller and have very high standards for reliability and verification. Linux doesn't fit well in that niche, but RTEMS is very good.
I don't think I have ever read about the latter. Maybe because real-time Linux is barely used where real-time behavior has more important consequences than audio dropouts. And it's difficult on PC hardware with stuff like surprise system management mode intervention, various hardware probably hogging some bus sometimes...
In embedded systems with hard real-time requirements, there are several ways to schedule tasks. Once the number of tasks you need to execute grows long enough, scheduling becomes a challenge. An RTOS is one way to manage these tasks with guaranteed, deterministic timing.
A concrete example: if you're in a car (an embedded system doing many things at once) and press the brakes, you want the car to be as responsive as possible. A real-time operating system will sacrifice other features of a general purpose OS to guarantee that the brakes are applied within a specified time interval after you press them.
There are a lot of systems that rely on precise timing, for instance clock generation/recovery, or opening/changing/closing a control valve in some process. It has to be precise or you lose sync in the first case or legitimate catastrophes can happen in the second.
A realtime OS makes some guarantees about the timeliness of things like interrupt service routines, and that necessarily excludes unbounded and unknown workloads from getting in the way -- something that every general purpose or soft realtime OS struggles with as the lack of determinism can improve throughput and scalability.
It's important for manipulating dynamic physical objects. Things tied stronger to wall clock than CPU clock, like rockets flying through the atmosphere and EV motors rotating as car rolls downhill.
They don't care about cache hits and branch predictions, so whatever you do with pulsating fuel pressure or flowing back regen electricity better happen predictably on-time than just ASAP off quuees. RTOS offer you that stability in time direction.
One of main differences between a traditional multiprocessing operating system and a real time one is that in the latter each process gets a fixed time slot to run and the kernel provides a guarantee that the process will be preempted no matter what. This gives every process running under the supervision of a real-time kernel a chance to do something useful.
Whereas in non-RT systems, a process may «overstay the welcome», and the time slot it has been allotted may lengthen (e.g. due to a computationally intensive unit of work or a blocking I/O operation) at the expense of other processes waiting in the scheduler run queue.
So non-RT kernels operate on the best effort basis («I will try my best to ensure each time slot has the same duration») vs guaranteed preemption in RT kernels («I hereby underwrite a guarantee that each time slot has the same duration and pledge that offending squatters will be evicted»).
Other than an example with the car, real-time processing is important in the audio engineering or processing where an audio stream will stutter in a non-RT operating system. There are other similar scenarios as well.
Related. Others?
RTEMS Real Time Operating System - https://news.ycombinator.com/item?id=32327518 - Aug 2022 (48 comments)
Thoughts on Supporting Rump Kernels on RTEMS - https://news.ycombinator.com/item?id=9086016 - Feb 2015 (1 comment)
I ported RTEMS on a 68k family microcontroller in 1997 for my computer science thesis, as part of a larger project. It was quite easy to work with, as I remember.
This takes me back to the mid 1990’s. Glad to see it’s still going.
Back then, I worked on porting it to some proprietary hardware. Was definitely an adventure!
I’d previously ported pSOS to a proprietary 68k board (different company) and that was a walk in the park by comparison.
They dropped the ball with the acronym though. Call it "A Real-Time Executive for Multiprocessor Information Systems (ARTEMIS), and then cue in all the cool Greek mythology puns about hunting goddesses and deer and swift reflexes and whatnot :p
Seems like the new website is why this is getting posted now.
One thing I like about RTEMS is the BSD affinity, https://gitlab.rtems.org/rtems/pkg/rtems-libbsd it seems like a pragmatic way to get some of the desired features.
Tangentially related, seL4 recently held its 2024 summit[0].
0. https://sel4.systems/Foundation/Summit/2024/abstracts2024
What are the requirements for this OS ? Will it run on synthesizable RISC-V core with 512K SRAM ?
I don't know much about real-time. Does the recent decision to make Linux kernel have real-time support by default make this obsolete?
Linux real-time has existed for many years, but it's still Linux. That means that it's a big, underspecified project. RTEMS is designed for high reliability embedded environments, especially spaceflight. These systems are smaller and have very high standards for reliability and verification. Linux doesn't fit well in that niche, but RTEMS is very good.
About that:
- Real-time is about guaranteed response times
- What are the guarantees of real-time Linux?
I don't think I have ever read about the latter. Maybe because real-time Linux is barely used where real-time behavior has more important consequences than audio dropouts. And it's difficult on PC hardware with stuff like surprise system management mode intervention, various hardware probably hogging some bus sometimes...
Could anyone here provide me a TLDR of why a real time OS is beneficial and specifically when/where it would be needed or most beneficial?
In embedded systems with hard real-time requirements, there are several ways to schedule tasks. Once the number of tasks you need to execute grows long enough, scheduling becomes a challenge. An RTOS is one way to manage these tasks with guaranteed, deterministic timing.
A concrete example: if you're in a car (an embedded system doing many things at once) and press the brakes, you want the car to be as responsive as possible. A real-time operating system will sacrifice other features of a general purpose OS to guarantee that the brakes are applied within a specified time interval after you press them.
Also, there are responses to a similar comment from when this was previously posted: https://news.ycombinator.com/item?id=32329499
There are a lot of systems that rely on precise timing, for instance clock generation/recovery, or opening/changing/closing a control valve in some process. It has to be precise or you lose sync in the first case or legitimate catastrophes can happen in the second.
A realtime OS makes some guarantees about the timeliness of things like interrupt service routines, and that necessarily excludes unbounded and unknown workloads from getting in the way -- something that every general purpose or soft realtime OS struggles with as the lack of determinism can improve throughput and scalability.
It's important for manipulating dynamic physical objects. Things tied stronger to wall clock than CPU clock, like rockets flying through the atmosphere and EV motors rotating as car rolls downhill.
They don't care about cache hits and branch predictions, so whatever you do with pulsating fuel pressure or flowing back regen electricity better happen predictably on-time than just ASAP off quuees. RTOS offer you that stability in time direction.
One of main differences between a traditional multiprocessing operating system and a real time one is that in the latter each process gets a fixed time slot to run and the kernel provides a guarantee that the process will be preempted no matter what. This gives every process running under the supervision of a real-time kernel a chance to do something useful.
Whereas in non-RT systems, a process may «overstay the welcome», and the time slot it has been allotted may lengthen (e.g. due to a computationally intensive unit of work or a blocking I/O operation) at the expense of other processes waiting in the scheduler run queue.
So non-RT kernels operate on the best effort basis («I will try my best to ensure each time slot has the same duration») vs guaranteed preemption in RT kernels («I hereby underwrite a guarantee that each time slot has the same duration and pledge that offending squatters will be evicted»).
Other than an example with the car, real-time processing is important in the audio engineering or processing where an audio stream will stutter in a non-RT operating system. There are other similar scenarios as well.
I learned about RTOS in the context of flight and air traffic control systems, as another concrete example