Your RTOS Is Not Your Architecture

Every few months, I watch an engineering team spend weeks debating FreeRTOS vs Zephyr.

They compare tick rates. Memory footprints. Community size. Licensing. They build evaluation boards. They write comparison docs. Eventually, someone makes the call.

Then they build on top of it — and the same structural problems show up again.

Not because the engineers are careless. The opposite. These are good teams doing careful work. But the RTOS doesn't tell you how to structure your application. And without that guidance, every team figures it out differently.

Here's what I mean.

An RTOS gives you tasks, semaphores, queues, and a scheduler. That's its job. It manages concurrency and timing.

But it doesn't define how your sensor task talks to your comms task. It doesn't enforce boundaries between subsystems. It doesn't prevent one module from reaching into another module's state. That's not the RTOS's job.

That's the architecture's job.

And most embedded projects don't have a formal one.

What they have is conventions. A lead engineer who carries the system map in their head. A naming scheme. Maybe a block diagram drawn during the first sprint that nobody updated since.

That works for a while. Then the team grows. Or the product ships and field bugs come in. Or you port to a new MCU and discover that your "architecture" was really just assumptions wired to a specific BSP.

I've worked on products where a state machine in one module was reading a global variable set by an ISR in a completely different module. No contract between them. No typed interface. Just a shared volatile and a convention that both sides understood.

Nobody wrote that to be reckless. It was the pragmatic shortcut when there's no framework enforcing a better pattern. And it works — until it doesn't.

Web development figured this out years ago. Nobody builds a production web app by wiring raw HTTP handlers together with global state. You use a framework. The framework enforces structure. Your code plugs into it.

Embedded never got that layer.

We got great RTOSes. We got HALs. We got BSPs. But the application layer — the thing that defines how your firmware modules are structured, how they communicate, how they're observed — that layer has been left to each team to reinvent.

Every project. From scratch. With the same structural problems emerging at scale.

I decided to stop watching that cycle and build the layer that's missing. Not another RTOS. The thing that sits above it — RTOS-agnostic, structured, observable from day one.

Still building. But the architecture is clear, and the pattern has held across every codebase I've tested it against.

What's your experience — has your team ever spent weeks on the RTOS decision and then zero time designing what sits above it?

— Ritesh | ritzylab.com

#EmbeddedSystems #RTOS #FirmwareDevelopment #EmbeddedEngineering #IoT