The README mentions ARMv7-M, RISC-V, and AVR, but no actual SoCs or boards, and the source code contains unconditional inline assembly for Arm. Similarly, there are measurements of context switch time on RISC-V, while the scheduler is one big stub that doesn't even enter a task, only returns from itself using Arm-specific assembly [0]. The examples rely on this scheduler never returning, so there's no way any of them can run [1]. The bootloader is also a stub [2]. Not a single exception vector table, but plenty of LLM-style comments explaining every single line.
Others (well, two people really) have also noted the lack of a linker script, start-up code, and that the project doesn't even build.
82 points at the time of writing, which is 4 hours from the post's submission. Already on the main page. The only previous activity of the author? Two other vibe-coded projects of similar quality and a few comments with broken list formatting, suggesting that they were never even reviewed by a human prior to posting.
Does anybody read past the headline these days? Had my hopes higher for this site.
HN used to provide a really high signal to noise ratio for me, but it's degrading pretty quickly. There are new accounts below saying "hey I just learned what RTOS means, thanks!"
I reflexively reload HN many times per day, but I'm wondering if I need a walled garden with some sort of curation of individuals - which sucks - to get the signal level I want.
This probably isn't just an HN problem (GH's model is broken now). It's so cheap to make software that the previous process of releasing something new associated with a person is probably outdated. AI knows what sounds impressive too. So now we're drowning in software releases and attributing software to a person is meaningless.
This site is very much drowning in all the slop. It's over half of posts now I think, not just the "Show HN" posts. Those are 100% slop, as are all the non-show-hn new project announcements.
All the moderators have done is drop Show HN posts by newish accounts. It fixed nothing. I have to hope they have some ambitious plan along the lines of what you suggest.
As a rule people do not read the linked content, they come to discuss the headline.
The first indication to me this was AI was simply the 'project structure' nonsense in the README. Why AI feel this strong need to show off the project's folder structure when you're going to look at it via the repo anyway is one of life's current mysteries.
A web-of-trust-like implementation of votes and flags, as suggested below, might be a solution, but I feel like it's an overkill. I've recently flagged a different clickbait submission, about Android Developer Verification, whose title suggested a significant update but that merely linked to the same old generic page about the anti-feature that was posted here months prior. Around 100 points too, before a mod stepped in, changed the title, and took it down.
Maybe the upvote button is just too easy to reach? I have a feeling that hiding it behind CSS :visited could make a massive difference.
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.
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.
Yeah, I read that note and stopped looking further. I was hoping that maybe the hardware-specific code was in a different project and just wanted to be nice in case.
I just don’t get the point of making AI slop out of something like a toy RTOS, which is inherently a learning project more than anything else. There’s nothing even fun about doing it if you won’t even try to get it to run on an STM32 or something.
Question: Do you mean real time, meaning there is some kind of expectation of task switching time, nothing can stop other threads from executing, etc; or do you really mean embedded?
I did my master thesis working with that in 2006.
It was fun but challenging to work with a so primitive OS (no memory dynamic allocation, etc.) and so many bugs.
Interesting this kernel implements kernel message queues, which are almost never used out in the wild. Are there any examples of popular software projects that use POSIX/SysV message queues?
It doesn't compile for you or doesn't compile at all? Honest question. It's a nice project in the face of it but if it's all AI fever dreams that would be disappointing. I don't have the cycles to try it out right now.
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?
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).
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.
> 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! :)
The README mentions ARMv7-M, RISC-V, and AVR, but no actual SoCs or boards, and the source code contains unconditional inline assembly for Arm. Similarly, there are measurements of context switch time on RISC-V, while the scheduler is one big stub that doesn't even enter a task, only returns from itself using Arm-specific assembly [0]. The examples rely on this scheduler never returning, so there's no way any of them can run [1]. The bootloader is also a stub [2]. Not a single exception vector table, but plenty of LLM-style comments explaining every single line.
Others (well, two people really) have also noted the lack of a linker script, start-up code, and that the project doesn't even build.
82 points at the time of writing, which is 4 hours from the post's submission. Already on the main page. The only previous activity of the author? Two other vibe-coded projects of similar quality and a few comments with broken list formatting, suggesting that they were never even reviewed by a human prior to posting.
Does anybody read past the headline these days? Had my hopes higher for this site.
[0] https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...
[1] https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...
[2] https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...
HN these days is filled with people saying basically "Show HN: I had an LLM shit out something I wanted, I didn't read it, but you should!".
And then a bunch of green new accounts commenting on how it's cool and they learned something. It's just a never ending attack on our attention.
HN used to provide a really high signal to noise ratio for me, but it's degrading pretty quickly. There are new accounts below saying "hey I just learned what RTOS means, thanks!"
I reflexively reload HN many times per day, but I'm wondering if I need a walled garden with some sort of curation of individuals - which sucks - to get the signal level I want.
This probably isn't just an HN problem (GH's model is broken now). It's so cheap to make software that the previous process of releasing something new associated with a person is probably outdated. AI knows what sounds impressive too. So now we're drowning in software releases and attributing software to a person is meaningless.
I wish HN upvote data was public, I feel like I could build some kind of improved algorithm that reduces the vote weight of people who upvote slop.
This site is very much drowning in all the slop. It's over half of posts now I think, not just the "Show HN" posts. Those are 100% slop, as are all the non-show-hn new project announcements.
All the moderators have done is drop Show HN posts by newish accounts. It fixed nothing. I have to hope they have some ambitious plan along the lines of what you suggest.
As a rule people do not read the linked content, they come to discuss the headline.
The first indication to me this was AI was simply the 'project structure' nonsense in the README. Why AI feel this strong need to show off the project's folder structure when you're going to look at it via the repo anyway is one of life's current mysteries.
Honestly, maybe this is the problem.
A web-of-trust-like implementation of votes and flags, as suggested below, might be a solution, but I feel like it's an overkill. I've recently flagged a different clickbait submission, about Android Developer Verification, whose title suggested a significant update but that merely linked to the same old generic page about the anti-feature that was posted here months prior. Around 100 points too, before a mod stepped in, changed the title, and took it down.
Maybe the upvote button is just too easy to reach? I have a feeling that hiding it behind CSS :visited could make a massive difference.
Don't forget the 71 stars on github, and counting!
Oh wow, was 60 just a while ago. Guess the dead Internet theory is no longer just a theory.
Hi HN,
I’ve been working on a tiny RTOS as a personal project to better understand how operating systems and schedulers work internally.
This project includes: - Basic task scheduler - Context switching - Simple memory management - Runs on (your target hardware or environment)
Motivation: I wanted to learn OS internals by building everything from scratch rather than relying on existing frameworks.
Challenges: - Implementing context switching correctly - Designing a minimal but usable scheduler - Keeping the codebase simple and readable
I’d really appreciate feedback, especially on: - Architecture design - Scheduler implementation - Code structure
GitHub: https://github.com/cmc-labo/tinyos-rtos
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.
https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...
"Context switch (to be implemented in assembly for target architecture)"
There's no asm in the repo so I can only assume this is not something that actually compiles and runs.
Other things that are missing:
- No startup code (stack setup etc.)
- No linker script ("to be created", per makefile comment)
Yeah, I read that note and stopped looking further. I was hoping that maybe the hardware-specific code was in a different project and just wanted to be nice in case. I just don’t get the point of making AI slop out of something like a toy RTOS, which is inherently a learning project more than anything else. There’s nothing even fun about doing it if you won’t even try to get it to run on an STM32 or something.
> Runs on (your target hardware or environment)
Nice try, OpenClaw
Did you never even try compiling it?
What ever happened to μC/OS?
Seemed both well documented and well suited to have taken over for the current MCU explosion. I almost never see anyone talk about it.
Looks like it open-sourced in 2020.
https://github.com/weston-embedded
Question: Do you mean real time, meaning there is some kind of expectation of task switching time, nothing can stop other threads from executing, etc; or do you really mean embedded?
It doesn't implement task switching at all...
Can you back that up? It supports `os_task_create()`, `ps`, `top`, and the default for `MAX_TASKS` is 8.
https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...
This codebase is essentially a stage prop, it has never been compiled nor executed.
I thought this was about UC Berkeley's TinyOS: https://github.com/tinyos/tinyos-main
This was a big deal in some academic circles in the early 2000s
I did my master thesis working with that in 2006. It was fun but challenging to work with a so primitive OS (no memory dynamic allocation, etc.) and so many bugs.
Interesting this kernel implements kernel message queues, which are almost never used out in the wild. Are there any examples of popular software projects that use POSIX/SysV message queues?
this reminds me of: https://github.com/tinyos/tinyos-main more than one decade ago
How much of this was by AI?
It doesn't even compile, the whole thing is evidently built on vibes.
It doesn't compile for you or doesn't compile at all? Honest question. It's a nice project in the face of it but if it's all AI fever dreams that would be disappointing. I don't have the cycles to try it out right now.
It won't compile for anyone, it's not a real software project.
Bummer
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?
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! :)
There is already a TinyOS in the sensor networks space. I've used it with MicaZ motes over a decade ago.
https://github.com/tp-freeforall/prod
Thanks for sharing