What this is.
Opinion + Experience + Fact (40% opinion · 35% experience · 20% fact · 5% fiction)
Written in collaboration with AI — I discuss, I do not outsource.

Chapter 1. The Deadline Is Real

The layer above the RTOS is real. So is the deadline ⏳.

Mbed OS — the runtime that has lived inside a generation of cellular modules, Cortex-M reference boards, and connected products — reaches end of maintenance in July 2026. ARM has been clear and public about the date. Many teams have known for a while. Many more are looking at the calendar this month and starting the conversation.

The conversation usually starts at the RTOS. Which one replaces Mbed? Zephyr, FreeRTOS, NuttX, ThreadX, a POSIX runtime for host work? That is the first question every team asks. It is the right question to ask. It is also the smaller half of the answer.

The larger half is the layer above. The architecture above the RTOS is the part of the choice that compounds — across this migration, the one after it, and the AI agent reading the codebase next year.

▸ First principle. The RTOS choice is the visible half of the migration. The architecture above it is the half that compounds.

Chapter 2. Migration Is A Recurring Tax

I have watched a few migration cycles up close over 20+ years 📦.

MicroC/OS to FreeRTOS, one product. ThreadX to a custom kernel, another. A bare-metal main loop to FreeRTOS, a third. Mbed OS picked up somewhere along the way for the cellular module work. Each migration cost something close to the same — three to six months of rework, the same drivers re-ported, the same message bus re-invented, the same state machines re-typed.

The technical answer was different every time. The shape of the work was identical every time.

That repetition was the tax. The team paid it because the architecture above the kernel had not been written down. Each RTOS swap was also an application rewrite, because the application had grown attached to the kernel underneath it — semaphore here, queue type there, timer callback over there, all tangled into the same files as the business logic 🪢.

When the layer above the RTOS is written down — message contracts, table-driven state machines, a small observability taxonomy, an explicit lifecycle, a fault policy — the migration changes shape. The kernel underneath becomes swappable. The application above moves with the layer, not with the kernel.

The tax stops being a five-year tax. It becomes a one-time cost.

▸ First principle. Migration cost compounds when the layer is implicit. Migration cost amortises when the layer is written down.

Chapter 3. Three Ways To Read The Deadline

Every Mbed team I have spoken with this spring is reading the deadline one of three ways 🗺️.

Read it as a port. Find the closest one-to-one mapping — Mbed thread to FreeRTOS task, Mbed queue to FreeRTOS queue, Mbed timer to a software timer. Get the build green, get the product shipping again. Defer the architecture conversation.

Read it as an RTOS choice. Pick the new RTOS carefully. Run benchmarks. Pick the one with the right footprint, the right vendor support, the right community. Spend most of the migration budget on the kernel decision.

Read it as an architecture choice. Write down what lives above the RTOS first — the contracts, the state machines, the observability events, the fault policy. Pick the kernel underneath after, because the kernel is now the part the team owns the least of.

All three ship a product. Only one of them changes the cost of the next migration. The third one is the one that pays the team back for the next five years and the one that the AI agent in the loop can actually extend.

▸ First principle. A migration is a port, an RTOS choice, or an architecture choice. Only the third compounds.

Chapter 4. The Five Criteria That Decide The Next Five Years

When a team writes the architecture down first, five criteria show up every time. Whichever path the team picks, these criteria are the questions worth answering before the build starts 📐.

RTOS portability. Does the application code refer to RTOS primitives directly, or does it call into a thin OSAL wrapper? The first option ties the application to the kernel. The second option lets the kernel be swapped without rewriting modules.

Host simulation. Can the application code build and run on a developer laptop with a POSIX adapter underneath? If yes, the CI loop runs in seconds. If not, every test waits for the bench.

Observability built-in. Does the application emit structured events — boot, message, state, fault, function — from day one? Or does observability get bolted on at certification time?

AI-readable contracts. Are message types defined in a schema the AI agent can read? Are state machines flat tables an agent can extend? Or is the structure spread across header files and convention?

License clarity. Is the runtime Apache-2.0-ish, vendor-restricted, or GPL? The answer affects what the next product can do with this code.

These five questions outlast the kernel underneath. The kernel can be the best on the market and still be the wrong choice if the application above is anchored to it 🔗.

▸ First principle. The right migration question is not which RTOS. It is which five things the team wants to be true for the next product.

Chapter 5. The Migration Decision Matrix

Here is the matrix every Mbed team can copy and run against their own list 📋:

                              │  Read it    │  Read it as  │  Read it as
  Criterion                   │  as a port  │  RTOS choice │  architecture
 ─────────────────────────────┼─────────────┼──────────────┼────────────────
  Time to first build         │  Days       │  Weeks       │  A few weeks
  Migration cost — next time  │  Same       │  Same        │  Lower each time
  RTOS portability            │  Low        │  Medium      │  High
  Host simulation             │  Bench-only │  Sometimes   │  Built in
  Observability built-in      │  Bolt-on    │  Sometimes   │  Built in
  AI-readable contracts       │  No         │  No          │  Yes
  License clarity             │  Inherits   │  Decided     │  Decided
  Pays back across migrations │  Once       │  Once        │  Each time

Copy the matrix. Fill in the second and third columns with the actual RTOS candidates your team is considering. Fill in the fourth column with what the team would build above the kernel if the architecture conversation happened first.

The matrix gives the conversation a shape. It moves the discussion from which RTOS to which architecture in about ten minutes 🎯.

▸ First principle. A decision matrix replaces an opinion-driven debate with a structured one. The structure surfaces the question the team should be asking.

Chapter 6. The Calmer Migration After This One

The reason to write the architecture down during this Mbed migration is the migration after this one.

A team that ports Mbed to the next kernel without writing the layer down will be back here in five or six years, paying the same tax for the same reason. The product changes. The chip changes. The kernel changes. The application stays tangled with the kernel underneath, and the migration takes the same three to six months 🔄.

A team that writes the layer down during this migration adds a few weeks up front. Those few weeks buy a different next migration. Modules move with the layer. Tests run on a laptop. The kernel underneath becomes the easiest piece to swap, instead of the hardest.

I have watched the second pattern play out on smaller migrations — a HAL port, a driver framework change, a transport switch. Each one was calm because the layer above had a name and a shape. The kernel migration is the larger version of the same story.

The calmer migration after this one is the prize. The Mbed deadline is the prompt to claim it 🎁.

▸ First principle. This migration writes the architecture. The next migration reads it. Calm migrations compound from this single act.

Chapter 7. What I Would Do This Week

If I were on a team with an Mbed dependency right now, here is the order I would work in 📌.

This week. Read the matrix above with the lead engineer and one other team member. Decide which read is closest to where the team is today — port, RTOS choice, or architecture. Write the answer down.

Next week. Pick the five elements of the layer above the RTOS (lifecycle, message contracts, FSM convention, observability taxonomy, fault policy). Write a one-page draft of each, even if the draft is rough. The drafts are the architecture the next migration will reuse.

Within the month. Identify which RTOS primitives the application code currently uses directly. Move each one behind a thin OSAL call. The application then becomes ready for the kernel underneath to change without rewriting modules.

By July. Pick the kernel. Run the port. The port will be the shortest step of the migration, because the architecture work has already been done.

The Mbed deadline is not the problem. The problem is the architecture conversation the deadline forces. Have the conversation now — every product after this one inherits the answer ✨.

If your team is reading the Mbed deadline this month — which of the three reads is closest to where your team starts?

Next: every migration story I've watched ship has one move that pays back harder than the rest — observability built into the layer itself, before the first sensor read.

▸ First principle. The deadline is a prompt, not a problem. The architecture conversation the deadline forces is what the team gets to keep.

Labeled: Opinion + Experience + Fact
(40% opinion · 35% experience · 20% fact · 5% fiction)

Sources:

(Written in collaboration with AI — I discuss, I do not outsource.)

New to this labeling? Read the framework → 20+ Years of Ideas. Articulation Is the Craft.

— Ritesh | ritzylab.com

#EmbeddedSystems #MbedOS #Firmware #RTOS #Architecture