kamaitachi 2 days ago | prev | next |

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.

ebruchez 8 hours ago | prev | next |

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.

itslennysfault 9 hours ago | prev | next |

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?

pbrowne011 9 hours ago | root | parent | next |

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

kev009 8 hours ago | root | parent | prev | next |

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.

inkyoto 6 hours ago | root | parent | prev |

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.

wakawaka28 4 hours ago | prev |

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?

inamberclad an hour ago | root | parent |

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.