7 ms·

RTEMS Real Time Operating System

139 points by inamberclad 4y ago

inamberclad 4y ago
The Real-Time Executive for Multiprocessor Systems or RTEMS is an open source Real Time Operating System (RTOS) that supports open standard application programming interfaces (API) such as POSIX. It is used in space flight, medical, networking and many more embedded devices. RTEMS currently supports 18 processor architectures and approximately 200 BSPs. These include ARM, PowerPC, Intel, SPARC, RISC-V, MIPS, and more. RTEMS includes multiple file systems, symmetric multiprocessing (SMP), embedded shell, and dynamic loading as well as a high-performance, full-featured IPV4/IPV6 TCP/IP stack from FreeBSD which also provides RTEMS with USB.
loa_in_ 4y ago
Largely off topic: Discord is clearly doing a lot of things right.
- sitzkrieg 4y ago
  no they are not
zik 4y ago
I've worked with RTEMS a bit and it's quite an impressive system. It's a shame it isn't better known.
mgsouth 4y ago
Waaaaayyyy back in the day (1988) it started out as "Real-Time Executive for Missile Systems" [0]. Hard-core hard-real-time. Today the "MS" stands for "Multiprocessor Systems". Heterogenous multiple processors [1]. The OS is perfectly happy running x86, ARM and RISC-V in the same system, though I don't know which of the canned Board Support Packages use that capability. It's a pretty good introduction to RT--small enough to get your head around, but lots of capability. I used it for my first major embedded software project (LAN NIC driver, based on Linux driver for similar chip) 15 years ago and it was pretty straight-forward. Rate it 4 1/2 stars, would code again. [0] https://devel.rtems.org/wiki/History/Timeline https://devel.rtems.org/wiki/History/Timeline [1] https://docs.rtems.org/releases/rtemsdocs-4.8.0/share/rtems/html/c_user/c_user00427.html https://docs.rtems.org/releases/rtemsdocs-4.8.0/share/rtems/...
- inamberclad 4y ago
  I'd love to hear more about your experiences!
  - mgsouth 4y ago
    Not much to tell. I was looking at maybe using an RTOS to reduce VoIP jitter. Picked RTEMS on a generic x86 PC, there wasn't a driver for the NICs we were using, so wrote a driver using a FreeBSD driver (for an unrelated chip) as a base template and a Linux driver for a related chip as a kind of spec. Don't remember if had to do the top-end or just the bottom-end for the NIC. The driver worked fine on RTEMS, but the UDP stack was basically straight from FreeBSD and was definitely not real-time. Wound up not being much of an improvement, it wasn't worth rewriting the entire UDP stack or introducing RT to my non-RT team, so dropped the idea. Did find a performance bug in the core I don't remember much about (unfortunate choice of operations that flushed caches or something and realllly slowed down... something). Submitted the half-a-dozen line patch upstream that Joel Sherrill pulled without drama, even though my test case was overly complicated and opaque.
    - elcritch 4y ago
      What limited the networking stack in terms of RT? I'm having difficulty imagining where the real time blockers would be, but curious as thats a big motivator for me.
      - mgsouth 4y ago
        We wanted to handle 10's K of VoIP channels, on multiple processors, with each channel sending a UDP packet every 20 mSec +/- a couple of mSec. The network stack was just the standard FreeBSD "box" and had no provision for that kind of clocking or time-to-process guarentees. Our application could call send() on a fixed schedule, but couldn't control when the packet would actually pop out. The process time would vary because of things such as global locks for buffers, varying code paths (do we ARP?), and varying amounts of competition from other processes. The only way to get reasonably consistent times was to way over-provision the system so it was loafing. We were already doing that with Solaris, so not worth it. What we needed was something like Linux's scheduling queue disciplines [0]; it would have allowed us to say "here's a packet, schedule it for 10 mSec from now", and we'd be good as long as the vast majority of packets took less than 10 msec to wend through the stack. But that didn't exist at that point. [0] https://tsn.readthedocs.io/qdiscs.html https://tsn.readthedocs.io/qdiscs.html
schaefer 4y ago
can anyone say a word or two about how RTEMS compairs to FreeRTOS?
- inamberclad 4y ago
  It's a much bigger project. FreeRTOS is, to my understanding just a scheduler. RTEMS provides POSIX APIs, a shell, networking stack, etc.
__void 4y ago
no support for xtensa/esp32 :<
- ncmncm 4y ago
  Yet. But maybe that says more about esp32 than about RTEMS?
  - __void 4y ago
    ..and what should this say about esp32? I don't understand what you are implying... xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture and weird memory structure because out there I find very few loader/relocator impementations (nominally I only know niicoooo's version[1], brian pug's derivative[2] for his interesting joltos, mongoose/Zephyr's supercustom versions, and my own) and this seems to be the main stumbling block for new os development in this platform [1] https://github.com/niicoooo/esp32-elfloader https://github.com/niicoooo/esp32-elfloader [2] https://github.com/joltwallet/jolt_wallet/tree/master/jolt_os/jelf_loader/src https://github.com/joltwallet/jolt_wallet/tree/master/jolt_o...
    - p_l 4y ago
      Most ESP32 devices are on the small side from RTEMS PoV, plus harvard architecture is probably an issue as well. Even with external memory, I'm not sure if I've seen any ESP32 with more than 8MB of SPI-attached RAM - this would be enough for RTEMS, but I'm not sure about viability of using SPI-attached SRAM as main memory. EDIT: Looking through processor supplements documentation for RTEMS, the 520kB of RAM in ESP32 would be enough. I guess RTEMS is simply less well known and its main users target heavier platforms whereas many people are fine with just the provided ESP32 toolkit as base "OS"
    - ajross 4y ago
      > xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture Pedantry: everyone uses a Harvard architecture, that just means having separate buses internally for instructions and data -- essentially if you have a separate icache/dcache, you're Harvard. Xtensa is weird because it's L1 caches are incoherent. As far as the architecture, it's sort of too clever for its own good. The register windowing scheme seems amazing, just a few comparators at runtime and some special exception handlers is all it takes to get 64 hardware registers to work. But... no one ever taught compilers how to deal with the complexity (the generated code needs to decide how many of its local registers to preserve across a call, which is a global optimization that depends on the behavior of the code it's invoking). So the end result is that for the same code, Xtensa code actually uses significantly more stack space than conventional architectures like ARM or RISC-V. (Their own toolchain is better at this than gcc, but still bad). And FWIW: Zephyr doesn't do dynamic loading yet. We have crazy linker behavior, but it's all static.
vodou 4y ago
RTEMS is fairly popular in space industry. I have been involved in two sateliite projects using RTEMS, one using the somewhat obscure OpenRISC architecture and one using LEON3/SPARC (also quite popular in space industry).
- marsRoverDev 4y ago
  Me too - ESA is a pretty heavy user of RTEMS.
  - okl 4y ago
    While smaller ESA projects like satellite instruments are usually free to choose which version of RTEMS they use, larger and more important projects use ESA's own version. This version is known as the "EDISOFT" version because it was re-developed/qualified by a portuguese company of that name. It is basically a rewrite of a subset of the RTEMS API. You can read more about it here: https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Software_Systems_Engineering/RTEMS_EDISOFT https://www.esa.int/Enabling_Support/Space_Engineering_Techn... Like most of ESA's software engineering tools, it is hopelessly outdated and relies on a patched GCC 4.2.1 which is missing a lot of useful features and bug fixes, especially for the SPARC architecture which is often used in ESA spacecraft. See -mfix-* switches here https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/SPARC-Options.html https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/SPARC-Options.... While RTEMS is GPL-licensed ESA does not want the code to be freely available -- you probably won't find it online. Some years ago they realized that, if they don't upstream their code, they have no chance to keep up to date and started an initiative to improve the situation: https://rtems-qual.io.esa.int https://rtems-qual.io.esa.int, https://rtems-qual.io.esa.int/ https://rtems-qual.io.esa.int/
    - inamberclad 4y ago
      I believe RTEMS is BSD licensed.
      - okl 4y ago
elcritch 4y ago
I was working a lot with Zephyr until recently. Unfortunately Zephyr just seemed to always be painful somehow. The DTS layer is both the best and worst part of it. I'd written off RTEMS as a serious modern RTOS, but it looks pretty alive. I am intrigued by the FreeBSD heritage of the network code. Anyone tried both?
- JoelSherrill 4y ago
  RTEMS now has a choice of network stacks. You can choose from libbsd which is a port of (currently) FreeBSD 12 services including TCP/IP, USB, SD/MMC, and more including the network shell commands. We have an implementation of core kernel services which make porting the code easier. There was an article in the FreeBSD Journal about this a few years ago. We also have a port of lwip which is appropriate for smaller systems. Finally we have the older legacy FreeBSD stack which we don't recommend for new projects but some BSPs still only have drivers in there.
  - inamberclad 4y ago
    Wow, great to see you here! What's your opinion of the FreeBSD stack in general for future projects?
- nix23 4y ago
  I'm a big proponent of rtems and riot-os, but just worked with rtems regularly.
deadcore 4y ago
I really hate to be naive - any chance someone would be able to ELI5 RTOS please? How they may differ from say MS Windows, why use one, their applications. Always struggled to bend my head around them
- nix23 4y ago
  >I really hate to be naive Being naive/curious is the best way to start learning. https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f... >>In the context of multitasking systems the scheduling policy is normally priority driven (pre-emptive schedulers). In some situations, these can guarantee hard real-time performance (for instance if the set of tasks and their priorities is known in advance). There are other hard real-time schedulers such as rate-monotonic which is not common in general-purpose systems, as it requires additional information in order to schedule a task: namely a bound or worst-case estimate for how long the task must execute. Specific algorithms for scheduling such hard real-time tasks exist, such as earliest deadline first, which, ignoring the overhead of context switching, is sufficient for system loads of less than 100%.[7] New overlay scheduling systems, such as an adaptive partition scheduler assist in managing large systems with a mixture of hard real-time and non real-time applications.
- jiggawatts 4y ago
  Basically the same as any other OS, but typically stripped down to the bare essentials. The key differentiator is the kernel scheduler, which is typically set up to provide regular and guaranteed time slices to processes. Normal operating systems provide time slices in big chunks, and not very predictably. The RTOS approach is less efficient overall and has lower total throughput, but some applications don’t need a lot of horsepower, just consistency. Think: robotics, audio, servo motor controllers, etc…
- adrian_b 4y ago
  Unlike a general-purpose operating system, when using a RTOS it is possible to guarantee that a given action will be executed before a certain deadline in time. The general-purpose operating systems attempt to execute all available tasks as quickly as possible and in a fair manner between users, but they cannot make guarantees about the worst-case execution times, which can be very bad even when the average execution times are very good. In order to be able to provide time guarantees, a RTOS avoids any algorithms that are not deterministic and it uses different policies for scheduling the execution threads, unlike those used by a general-purpose OS. Most RTOSes use fixed priorities for the execution threads, where any higher-priority thread always preempts immediately a lower-priority thread, whenever an interrupt signals an event which must be handled by the high-priority thread, while the threads of equal priority are scheduled in a round-robin manner. Unlike when programming for a general-purpose OS, when programming for a RTOS a very important additional task for the programmer is to assign priorities for all the execution threads. If the priorities are assigned in a wrong way, it can be impossible to guarantee the time deadlines. For some common cases there are easy rules for priority assignments. E.g. when having a set of threads that are activated periodically, which must always finish their work within a period, then the priorities must be assigned, from the highest to the lowest, to the threads ordered from the smallest period to the greatest period. The programs which may execute for an indefinite time after they receive control, like many of those written for Windows or Linux, must be put on the lowest priority level available, because any program with a lower priority than them would never be executed by an RTOS. When there are more such programs, they are executed in round-robin manner, being preempted after a configurable time interval.
p_l 4y ago
https://www.rtems.org/sites/default/files/RTEMS_Army_Brochure_1993.pdf https://www.rtems.org/sites/default/files/RTEMS_Army_Brochur... The old brochure is pretty interesting overview of the program goals.
okl 4y ago
A real pain with RTEMS is that it requires a customized GCC version. This means that you're stuck with a specific version unless you apply/update the patches manually to a newer version.
- JoelSherrill 4y ago
  This isn't uncommon for an OS to provide its own tooling. This is how you get the GCC language runtimes tailored for the OS. We support C, C++, and Ada fully out of the box. Our current GCC should be tracking gcc 12. Did you know that we provide a tool to build all tooling from source including application of patches? It's similar in concept to BSD ports. This gives users full source and the ability to put it under configuration control for long term projects.
  - adrian_b 4y ago
    I am glad to see that you are still well and working at RTEMS after so many years. Several decades ago, when I was young and I have discovered RTEMS by chance, I have learned many useful things from its documentation, source code and tooling scripts. IIRC, I have also got some very helpful e-mail responses from you, to some of my newbie questions. So I have always been grateful for your RTEMS work. One of the useful things that I have learned then from the RTEMS scripts was precisely how to build my own customized toolset with binutils/gcc/gdb and so on, for cross-development for an embedded system target. I have always done this, instead of attempting to use one of the pre-built but less suited for my purposes toolsets that can be found in various places, and it has always helped me a lot.
irq-1 4y ago
Supports Raspberry Pi if anyone wants to try it out. https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi https://docs.rtems.org/branches/master/user/bsps/bsps-arm.ht... > The ‘raspberrypi’ BSP supports the single core models (Zero, Zero W, A+, B+), and the ‘raspberrypi2’ BSP supports the Raspberry Pi 2, Raspberry Pi 3 A+, and Raspberry Pi 3. The Raspberry Pi 4 is not supported currently. The default bootloader on the Raspberry Pi which is used to boot Raspbian or other OS can be also used to boot RTEMS. U-boot can also be used.
- mgsouth 4y ago
  Pretty limited support. No USB, graphics, SD card, or Ethernet. [0] The good news is there's lots of opportunity to make a contribution! [0] https://devel.rtems.org/ticket/2899 https://devel.rtems.org/ticket/2899

139 points by inamberclad 4y ago

The Real-Time Executive for Multiprocessor Systems or RTEMS is an open source Real Time Operating System (RTOS) that supports open standard application programming interfaces (API) such as POSIX. It is used in space flight, medical, networking and many more embedded devices. RTEMS currently supports 18 processor architectures and approximately 200 BSPs. These include ARM, PowerPC, Intel, SPARC, RISC-V, MIPS, and more. RTEMS includes multiple file systems, symmetric multiprocessing (SMP), embedded shell, and dynamic loading as well as a high-performance, full-featured IPV4/IPV6 TCP/IP stack from FreeBSD which also provides RTEMS with USB.

loa_in_ 4y ago

Largely off topic: Discord is clearly doing a lot of things right.

sitzkrieg 4y ago
no they are not

zik 4y ago

I've worked with RTEMS a bit and it's quite an impressive system. It's a shame it isn't better known.

mgsouth 4y ago

Waaaaayyyy back in the day (1988) it started out as "Real-Time Executive for Missile Systems" [0]. Hard-core hard-real-time. Today the "MS" stands for "Multiprocessor Systems". Heterogenous multiple processors [1]. The OS is perfectly happy running x86, ARM and RISC-V in the same system, though I don't know which of the canned Board Support Packages use that capability. It's a pretty good introduction to RT--small enough to get your head around, but lots of capability. I used it for my first major embedded software project (LAN NIC driver, based on Linux driver for similar chip) 15 years ago and it was pretty straight-forward. Rate it 4 1/2 stars, would code again. [0] https://devel.rtems.org/wiki/History/Timeline https://devel.rtems.org/wiki/History/Timeline [1] https://docs.rtems.org/releases/rtemsdocs-4.8.0/share/rtems/html/c_user/c_user00427.html https://docs.rtems.org/releases/rtemsdocs-4.8.0/share/rtems/...

inamberclad 4y ago
I'd love to hear more about your experiences!
- mgsouth 4y ago
  Not much to tell. I was looking at maybe using an RTOS to reduce VoIP jitter. Picked RTEMS on a generic x86 PC, there wasn't a driver for the NICs we were using, so wrote a driver using a FreeBSD driver (for an unrelated chip) as a base template and a Linux driver for a related chip as a kind of spec. Don't remember if had to do the top-end or just the bottom-end for the NIC. The driver worked fine on RTEMS, but the UDP stack was basically straight from FreeBSD and was definitely not real-time. Wound up not being much of an improvement, it wasn't worth rewriting the entire UDP stack or introducing RT to my non-RT team, so dropped the idea. Did find a performance bug in the core I don't remember much about (unfortunate choice of operations that flushed caches or something and realllly slowed down... something). Submitted the half-a-dozen line patch upstream that Joel Sherrill pulled without drama, even though my test case was overly complicated and opaque.
  - elcritch 4y ago
    What limited the networking stack in terms of RT? I'm having difficulty imagining where the real time blockers would be, but curious as thats a big motivator for me.
    - mgsouth 4y ago
      We wanted to handle 10's K of VoIP channels, on multiple processors, with each channel sending a UDP packet every 20 mSec +/- a couple of mSec. The network stack was just the standard FreeBSD "box" and had no provision for that kind of clocking or time-to-process guarentees. Our application could call send() on a fixed schedule, but couldn't control when the packet would actually pop out. The process time would vary because of things such as global locks for buffers, varying code paths (do we ARP?), and varying amounts of competition from other processes. The only way to get reasonably consistent times was to way over-provision the system so it was loafing. We were already doing that with Solaris, so not worth it. What we needed was something like Linux's scheduling queue disciplines [0]; it would have allowed us to say "here's a packet, schedule it for 10 mSec from now", and we'd be good as long as the vast majority of packets took less than 10 msec to wend through the stack. But that didn't exist at that point. [0] https://tsn.readthedocs.io/qdiscs.html https://tsn.readthedocs.io/qdiscs.html

schaefer 4y ago

can anyone say a word or two about how RTEMS compairs to FreeRTOS?

inamberclad 4y ago
It's a much bigger project. FreeRTOS is, to my understanding just a scheduler. RTEMS provides POSIX APIs, a shell, networking stack, etc.

__void 4y ago

no support for xtensa/esp32 :<

ncmncm 4y ago
Yet. But maybe that says more about esp32 than about RTEMS?
- __void 4y ago
  ..and what should this say about esp32? I don't understand what you are implying... xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture and weird memory structure because out there I find very few loader/relocator impementations (nominally I only know niicoooo's version[1], brian pug's derivative[2] for his interesting joltos, mongoose/Zephyr's supercustom versions, and my own) and this seems to be the main stumbling block for new os development in this platform [1] https://github.com/niicoooo/esp32-elfloader https://github.com/niicoooo/esp32-elfloader [2] https://github.com/joltwallet/jolt_wallet/tree/master/jolt_os/jelf_loader/src https://github.com/joltwallet/jolt_wallet/tree/master/jolt_o...
  - p_l 4y ago
    Most ESP32 devices are on the small side from RTEMS PoV, plus harvard architecture is probably an issue as well. Even with external memory, I'm not sure if I've seen any ESP32 with more than 8MB of SPI-attached RAM - this would be enough for RTEMS, but I'm not sure about viability of using SPI-attached SRAM as main memory. EDIT: Looking through processor supplements documentation for RTEMS, the 520kB of RAM in ESP32 would be enough. I guess RTEMS is simply less well known and its main users target heavier platforms whereas many people are fine with just the provided ESP32 toolkit as base "OS"
  - ajross 4y ago
    > xtensa/tensilica is a good architecture, cheap and lean, unfortunately its biggest problem seems to be its harvard architecture Pedantry: everyone uses a Harvard architecture, that just means having separate buses internally for instructions and data -- essentially if you have a separate icache/dcache, you're Harvard. Xtensa is weird because it's L1 caches are incoherent. As far as the architecture, it's sort of too clever for its own good. The register windowing scheme seems amazing, just a few comparators at runtime and some special exception handlers is all it takes to get 64 hardware registers to work. But... no one ever taught compilers how to deal with the complexity (the generated code needs to decide how many of its local registers to preserve across a call, which is a global optimization that depends on the behavior of the code it's invoking). So the end result is that for the same code, Xtensa code actually uses significantly more stack space than conventional architectures like ARM or RISC-V. (Their own toolchain is better at this than gcc, but still bad). And FWIW: Zephyr doesn't do dynamic loading yet. We have crazy linker behavior, but it's all static.

vodou 4y ago

RTEMS is fairly popular in space industry. I have been involved in two sateliite projects using RTEMS, one using the somewhat obscure OpenRISC architecture and one using LEON3/SPARC (also quite popular in space industry).

marsRoverDev 4y ago
Me too - ESA is a pretty heavy user of RTEMS.
- okl 4y ago
  While smaller ESA projects like satellite instruments are usually free to choose which version of RTEMS they use, larger and more important projects use ESA's own version. This version is known as the "EDISOFT" version because it was re-developed/qualified by a portuguese company of that name. It is basically a rewrite of a subset of the RTEMS API. You can read more about it here: https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Software_Systems_Engineering/RTEMS_EDISOFT https://www.esa.int/Enabling_Support/Space_Engineering_Techn... Like most of ESA's software engineering tools, it is hopelessly outdated and relies on a patched GCC 4.2.1 which is missing a lot of useful features and bug fixes, especially for the SPARC architecture which is often used in ESA spacecraft. See -mfix-* switches here https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/SPARC-Options.html https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/SPARC-Options.... While RTEMS is GPL-licensed ESA does not want the code to be freely available -- you probably won't find it online. Some years ago they realized that, if they don't upstream their code, they have no chance to keep up to date and started an initiative to improve the situation: https://rtems-qual.io.esa.int https://rtems-qual.io.esa.int, https://rtems-qual.io.esa.int/ https://rtems-qual.io.esa.int/
  - inamberclad 4y ago
    I believe RTEMS is BSD licensed.
    - okl 4y ago

elcritch 4y ago

I was working a lot with Zephyr until recently. Unfortunately Zephyr just seemed to always be painful somehow. The DTS layer is both the best and worst part of it. I'd written off RTEMS as a serious modern RTOS, but it looks pretty alive. I am intrigued by the FreeBSD heritage of the network code. Anyone tried both?

JoelSherrill 4y ago
RTEMS now has a choice of network stacks. You can choose from libbsd which is a port of (currently) FreeBSD 12 services including TCP/IP, USB, SD/MMC, and more including the network shell commands. We have an implementation of core kernel services which make porting the code easier. There was an article in the FreeBSD Journal about this a few years ago. We also have a port of lwip which is appropriate for smaller systems. Finally we have the older legacy FreeBSD stack which we don't recommend for new projects but some BSPs still only have drivers in there.
- inamberclad 4y ago
  Wow, great to see you here! What's your opinion of the FreeBSD stack in general for future projects?
nix23 4y ago
I'm a big proponent of rtems and riot-os, but just worked with rtems regularly.

deadcore 4y ago

I really hate to be naive - any chance someone would be able to ELI5 RTOS please? How they may differ from say MS Windows, why use one, their applications. Always struggled to bend my head around them

nix23 4y ago
>I really hate to be naive Being naive/curious is the best way to start learning. https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f... >>In the context of multitasking systems the scheduling policy is normally priority driven (pre-emptive schedulers). In some situations, these can guarantee hard real-time performance (for instance if the set of tasks and their priorities is known in advance). There are other hard real-time schedulers such as rate-monotonic which is not common in general-purpose systems, as it requires additional information in order to schedule a task: namely a bound or worst-case estimate for how long the task must execute. Specific algorithms for scheduling such hard real-time tasks exist, such as earliest deadline first, which, ignoring the overhead of context switching, is sufficient for system loads of less than 100%.[7] New overlay scheduling systems, such as an adaptive partition scheduler assist in managing large systems with a mixture of hard real-time and non real-time applications.
jiggawatts 4y ago
Basically the same as any other OS, but typically stripped down to the bare essentials. The key differentiator is the kernel scheduler, which is typically set up to provide regular and guaranteed time slices to processes. Normal operating systems provide time slices in big chunks, and not very predictably. The RTOS approach is less efficient overall and has lower total throughput, but some applications don’t need a lot of horsepower, just consistency. Think: robotics, audio, servo motor controllers, etc…
adrian_b 4y ago
Unlike a general-purpose operating system, when using a RTOS it is possible to guarantee that a given action will be executed before a certain deadline in time. The general-purpose operating systems attempt to execute all available tasks as quickly as possible and in a fair manner between users, but they cannot make guarantees about the worst-case execution times, which can be very bad even when the average execution times are very good. In order to be able to provide time guarantees, a RTOS avoids any algorithms that are not deterministic and it uses different policies for scheduling the execution threads, unlike those used by a general-purpose OS. Most RTOSes use fixed priorities for the execution threads, where any higher-priority thread always preempts immediately a lower-priority thread, whenever an interrupt signals an event which must be handled by the high-priority thread, while the threads of equal priority are scheduled in a round-robin manner. Unlike when programming for a general-purpose OS, when programming for a RTOS a very important additional task for the programmer is to assign priorities for all the execution threads. If the priorities are assigned in a wrong way, it can be impossible to guarantee the time deadlines. For some common cases there are easy rules for priority assignments. E.g. when having a set of threads that are activated periodically, which must always finish their work within a period, then the priorities must be assigned, from the highest to the lowest, to the threads ordered from the smallest period to the greatest period. The programs which may execute for an indefinite time after they receive control, like many of those written for Windows or Linux, must be put on the lowest priority level available, because any program with a lower priority than them would never be executed by an RTOS. When there are more such programs, they are executed in round-robin manner, being preempted after a configurable time interval.

p_l 4y ago

https://www.rtems.org/sites/default/files/RTEMS_Army_Brochure_1993.pdf https://www.rtems.org/sites/default/files/RTEMS_Army_Brochur... The old brochure is pretty interesting overview of the program goals.

okl 4y ago

A real pain with RTEMS is that it requires a customized GCC version. This means that you're stuck with a specific version unless you apply/update the patches manually to a newer version.

JoelSherrill 4y ago
This isn't uncommon for an OS to provide its own tooling. This is how you get the GCC language runtimes tailored for the OS. We support C, C++, and Ada fully out of the box. Our current GCC should be tracking gcc 12. Did you know that we provide a tool to build all tooling from source including application of patches? It's similar in concept to BSD ports. This gives users full source and the ability to put it under configuration control for long term projects.
- adrian_b 4y ago
  I am glad to see that you are still well and working at RTEMS after so many years. Several decades ago, when I was young and I have discovered RTEMS by chance, I have learned many useful things from its documentation, source code and tooling scripts. IIRC, I have also got some very helpful e-mail responses from you, to some of my newbie questions. So I have always been grateful for your RTEMS work. One of the useful things that I have learned then from the RTEMS scripts was precisely how to build my own customized toolset with binutils/gcc/gdb and so on, for cross-development for an embedded system target. I have always done this, instead of attempting to use one of the pre-built but less suited for my purposes toolsets that can be found in various places, and it has always helped me a lot.

irq-1 4y ago

Supports Raspberry Pi if anyone wants to try it out. https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#raspberrypi https://docs.rtems.org/branches/master/user/bsps/bsps-arm.ht... > The ‘raspberrypi’ BSP supports the single core models (Zero, Zero W, A+, B+), and the ‘raspberrypi2’ BSP supports the Raspberry Pi 2, Raspberry Pi 3 A+, and Raspberry Pi 3. The Raspberry Pi 4 is not supported currently. The default bootloader on the Raspberry Pi which is used to boot Raspbian or other OS can be also used to boot RTEMS. U-boot can also be used.

mgsouth 4y ago
Pretty limited support. No USB, graphics, SD card, or Ethernet. [0] The good news is there's lots of opportunity to make a contribution! [0] https://devel.rtems.org/ticket/2899 https://devel.rtems.org/ticket/2899