Hacker News Reader

Comment by Yokohiii | Hacker News Reader

I have no practical insight on RTOS in general, if anyone bothers to give me a hint, please. From all what I've looked into, RTOS does mean to create software systems that are almost perfectly predictable and safe to execute. Predictable latency, runtime and memory usage, plus maybe side channels to do the unpredictable stuff in between. It's actual rocket science, as no systemic mistakes are allowed. The confusion is that this project doesn't mention any of it. Is it just hijacking of a fancy acronym, are there two worlds side by side or am I completely misled?

View on HN

RTOS can be used a lot looser than you describe. Like a build system, scheduling, and interrupt framework that allows you to program an MCU like you describe. Zephyr RTOS and Free RTOS provide easy enough ways to write code that uses blocking APIs but probably runs your code according to the timing constraints if you hold it right. As an alternative, you could write for “bare metal” and handle the control flow, scheduling, interrupting, etc. yourself. If you are writing to “random” addresses according to some datasheet to effect some real world change, you are probably reaching for an RTOS or bare metal unless you are writing OS driversn. If you look at the linux drivers, you will see a lot of similarities to the Zephyr RTOS drivers, but one of them is probably clocking in the MHz while the other in the GHz

RTOS doesn't give any guarantees about "safe to compute/execute" - that's more the domain of formal verification. In the sense that you can make guarantees about how the program will behave given some domain of inputs. But predictable (or bounded) latency, yes.

You might execute formally verified code within an RTOS, which is your two worlds? Consider you have some critical control loop, like an autopilot (see Ardupilot). That control loop must run at some minimum rate, and the action of the system must be well characterized. Similarly you might want to guarantee that you sample a bunch of sensors frequently enough (so the most recent reading is no older than some time period).

TIL I learned that I am also a rocket scientist!

I would suggest that a slightly more approachable way to view an RTOS for MCUs is a library that sits on your bare metal that takes primary responsibility for efficiently dividing up available resources across multiple task functions.

An RTOS will usually provide a well documented SDK with support for memory safe queues, semaphores and message brokering.

Think of it as a software enforced contract + best practices to ensure that you get stable, predictable timing loops without ugly polling and blocking.

You're probably thinking of a hard real-time RTOS with time slices and WCET constraints.

For soft real-time, you basically only need low latency.

Threads with priorities, synchronization primitives and some way of handling interrupts is generally considered good enough.

From the description, this sounds like the kind of RTOS that runs most embedded RT applications currently if perhaps a bit heavier in features than the average with filesystem and networking support.

The distinction between hard and soft RTOS explains my confusion. Thanks for the heads up!

Can someone explain this whole boondoggle with RTOS and latency means in practice?

Why would someone make a context switch HIGH latency? That defeats the purpose.

Not sure what you are referring to, no one said that?

> It's actual rocket science, as no systemic mistakes are allowed

Lots of everyday stuff is running on bare metal code that exceeds so-called "real time" requirements without an OS at all, and those programmers are definitely not rocket scientists! :)

Reply on news.ycombinator.com