Hacker News Reader

Comment by raphui | Hacker News Reader

I’ve been working on a custom RTOS for Cortex-M for the past 10 years: https://github.com/raphui/rnk It started as a way to learn RTOS internals, and over time it has grown into something with lots of nice features. I’m even using it in a dirtbike anti-theft tracker I am building. Also, 2 months ago, I did a weekend challenge to build an embedded software parameter DSL and compiler. Its goal is to let firmware developers define configuration values, thresholds, constants, and other application-level parameters in a structured, human-readable format, and compile them into binary data that the firmware can directly use. https://github.com/raphui/epc

Happy to get any feedback :)

View on HN

Had to read the wikipedia article on Real-Time Operating System (RTOS) to figure out what it was supposed to mean. https://en.wikipedia.org/wiki/Real-time_operating_system

They compare it to timeshare systems, which seems horribly out of date (although apparently that's still kind of what occurs anyways on CPUs). What's the part that's "Real Time" relative to anything else people do with Cortex processors? The preemptive part? Not trying to be critical, just not getting the real time part. Does it not share CPU resources among tasks? Get a fixed core per task or something? Minimal interrupts and minimal thread switching?

An RTOS compared to bare metal just means it is some nice abstractions that you would expect from an OS : tasks, mutexes rtc.

An RTOS compared to an OS like linux basically just means it is deterministic, you can guarantee some interrupt is handled within a certain time. Not necessarily faster

Cool, thanks for the clarification. The Wiki article was kind of confusing and seemed to refer to a bunch of topics from back in the tape punching days.

As ab71e5 said, "Real time" in the context of OSes, means the operating system is optimized for determinism. The OS guarantees that events will be handle in a particular time-window and that high priority task will always run first.

Cool, thanks for the reply. Why does a dirtbike anti-theft tracker care about time-windows and that high priority tasks?

Actually, what kind of stuff other than the stock market actually cares that much about strict determinism and task priority? Only, other that really suggests itself is schedulers for multiple groups running big iron tasks, rather than micro-controllers.

Not familiar enough, just doesn't seem like there would be a lot of groups fighting about priority on micro-controllers. Usually seem very focused and single task specific anyways.

In my use case (dirtbike anti theft tracker), it is useful to use an RTOS, not specifically for hard time constraints, as I don't have those, but more to have all the other functionality: task synchronisation mechanisms, driver abstraction, etc. That allows to better design the application. For example, having separate tasks for GPS updates, cellular communication, and motion detection with proper prioritization makes the code much cleaner than a giant main loop with interrupts. About other industries, I would say highly critical medical systems, avionics and automotive find it useful to use RTOSes because they have use cases where time constraints are really hard.

Reply on news.ycombinator.com