The Fragmented World of Embedded Development: Why We Need a Standardised Future

In my nearly two decades working across defence, pharmaceutical, and robotics industries, embedded development has been one of the most powerful—and painful—domains in engineering. We’re building incredible things with microcontrollers and edge devices, yet we’re still doing it in a landscape riddled with fragmentation, vendor lock-in, and unnecessary complexity.

Unlike web development—which has evolved into a relatively cohesive ecosystem—embedded developers are still navigating a Wild West of incompatible tools, proprietary IDEs, and opaque drivers.

From my experience, this lack of unity isn’t just inconvenient. It actively slows innovation, raises costs, and creates unnecessary barriers for new engineers entering the field.

The Vendor Problem: Silos Everywhere

Let’s start with the most obvious issue: every chip vendor brings their own baggage.

ST has STM32CubeMX. NXP has MCUXpresso. Microchip pushes MPLAB X. Nordic has nRF Connect. Each offers its own “integrated development environment,” complete with its own quirks, UI conventions, build systems, and project structure.

These tools aren’t designed to play nicely with one another. In fact, they often do the opposite—locking developers into ecosystems where porting code to another chipset can feel like rewriting from scratch.

Want to migrate from an STM32 to an nRF52? Good luck. You’ll be rewriting drivers, restructuring your project, and learning a whole new build flow—just to blink the same LED.

This isn’t engineering. It’s babysitting toolchains.

Drivers and Interfaces: No Universal Language

Another issue I’ve run into time and again is the lack of standardisation in drivers and hardware abstraction layers.

GPIO, I2C, SPI, UART—these are fundamental interfaces. Yet every vendor implements them differently. Function signatures vary. Behaviour varies. Error handling varies. There's no consistent abstraction.

Compare that to how the web works. If I want to make an HTTP request in JavaScript, I don’t care who made my CPU or what OS I’m running. I write fetch() or use Axios, and I’m off.

Embedded? You’re reading 300-page reference manuals just to understand how to initialise I2C on a new board—and praying the vendor’s example code actually compiles.

It’s exhausting. And worse, it’s completely avoidable.

RTOS Madness: So Many Choices, So Little Compatibility

Then there’s the operating system mess.

FreeRTOS, Zephyr, ThreadX (now Azure RTOS), ChibiOS, Mbed OS, RIOT, NuttX—the list goes on. While choice is good in theory, in practice, it fragments the developer base and multiplies the effort needed to port and maintain code.

Each RTOS has its own APIs, configuration style, scheduler behaviours, and memory models. Even something as basic as creating a task or configuring a timer can differ wildly across systems.

And don’t get me started on debugging multithreaded issues across these platforms with vendor-specific tools.

The result? Teams either waste time learning multiple ecosystems or lock themselves into a single vendor and lose flexibility.

What We Need: A Standardised, Open Embedded Ecosystem

Imagine a world where embedded development worked more like web development:

A universal package manager like yarn add, pip install or go get, where hardware drivers are versioned, published, and shared as modular packages.
Drivers written to a common standard, not to a specific vendor. Write once, run on any supported MCU.
A simple, declarative hardware.toml or board.yaml file to define pins, peripherals, clocks, and memory layout.
One build system. One project format. One consistent debugging interface.

This isn’t fantasy. The tooling already exists—it just needs coordination and community willpower.

How We Could Build It

Here’s what I believe such a system could look like:

A centralised driver registry, where contributors submit tested drivers for interfaces like SPI, UART, I2C, etc.—agnostic to silicon vendor.
An abstraction layer, where vendors implement a “target” definition (similar to how WebAssembly abstracts away the underlying platform).
A declarative configuration file (board.yaml, project.toml) for mapping hardware resources to high-level drivers—human readable and portable.
Standardised RTOS interfaces, perhaps via a POSIX-like API layer, or something like CMSIS-RTOS but done right.

We already see glimpses of this in frameworks like Zephyr and Mbed OS. But too often, these systems still default to favouring certain vendors or tightly couple to their own ecosystems.

It’s time to do better.

Why It Matters

The embedded space is too important to be this messy.

We’re talking about the systems running medical devices, satellites, defence systems, and next-gen robotics. We need a world where developers can focus on innovation, not on deciphering vendor IDEs and reimplementing boilerplate.

In my view, a standardised embedded ecosystem would:

Reduce time to market for hardware startups.
Make it easier to hire and onboard engineers.
Enable broader community contributions.
Increase code reuse and interoperability across industries.

We’ve seen the power of open ecosystems in software. It’s time we brought that same ethos to embedded.

Final Thoughts

I’ve worked on everything from IoT sensors and robotic arms to edge AI camera systems. The underlying tech is fascinating, but the workflow is often archaic. Too much time is spent fighting the tools instead of building the product.

If we want embedded systems to thrive—especially as AI and edge computing push complexity to the endpoint—we need to simplify, standardise, and open up.

Let’s stop reinventing the wheel for every chip. Let’s start building a shared foundation.