Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C - Comments

Impressive! Very complete on first glance. You might want to soften or qualify the RTOS statement so people focus on its compactness and low latency. As you are already seeing in the comments the RTOS aspect has a lot of opinions depending on what one is trying to accomplish.

Very cool! Thanks for sharing.

I would appreciate an honest comparison with FreeRTOS. Building something like this is an excellent learning exercise for the coder, but someone who has to balance the risks, learning curve and feature set has to justify the adventure in a different way.

One thing that would be interesting to hear more about would be your own recounting of the places where you made opinionated decisions about how things should work.

Looks like a fun project, but I’m curious what you actually tested on. There’s real numbers for estimated context switch timing, and you mentioned implementing context switching, but I can’t find any actual implementations of the context switching routine in your code. You don’t need to do this yourself, but it’s weird to talk about it if you haven’t.

Did you never even try compiling it?

> Runs on (your target hardware or environment)

Nice try, OpenClaw

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.

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

> 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! :)

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.

It doesn't implement task switching at all...

It doesn't even compile, the whole thing is evidently built on vibes.

Impressive! Very complete on first glance. You might want to soften or qualify the RTOS statement so people focus on its compactness and low latency. As you are already seeing in the comments the RTOS aspect has a lot of opinions depending on what one is trying to accomplish.

Very cool! Thanks for sharing.

I would appreciate an honest comparison with FreeRTOS. Building something like this is an excellent learning exercise for the coder, but someone who has to balance the risks, learning curve and feature set has to justify the adventure in a different way.

One thing that would be interesting to hear more about would be your own recounting of the places where you made opinionated decisions about how things should work.

Looks like a fun project, but I’m curious what you actually tested on. There’s real numbers for estimated context switch timing, and you mentioned implementing context switching, but I can’t find any actual implementations of the context switching routine in your code. You don’t need to do this yourself, but it’s weird to talk about it if you haven’t.

Did you never even try compiling it?

> Runs on (your target hardware or environment)

Nice try, OpenClaw

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.

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

> 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! :)

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.

It doesn't implement task switching at all...

It doesn't even compile, the whole thing is evidently built on vibes.