About This Project
The software in most embedded projects written in 2026 looks like the software in embedded projects written in 1996. This isn’t because 1996 was the peak of innovation and quality but rather has more to do with biases and FUD (fear, uncertainty, and doubt). Unfortunately, most of the world suffers from these choices: users, developers, managers, and shareholders.
There are better ways to write firmware for embedded systems — techniques and implementation strategies that I will describe throughout this project.
Time to Hello World
Sadly, we are an impatient species that often makes poor judgements based on how “easy” or quick we perceive the solution to be. Sales and marketing are largely about understanding the buyer (not the user) and playing into those poor judgements.
CAD software, EDA tools, UI libraries, frameworks, embedded solutions with their IDEs all play into the Time to Hello World (TTHW) metric. How quickly can you extrude a block, round the corners, and place some threaded holes? What does it take to layout your favorite little test circuit and get some suggestions for trace widths? How many lines of code does it take to blink an LED or send some data on a serial port?
The problem with the TTHW metric — it is not grounded in the complexity of problems we actually solve. If you only need an aluminium block with threads or a blinky LED, you don’t need these software solutions.
The solutions I will describe in this project are not for Hello World. They are solutions used in large, multifaceted embedded projects that need to address quality and delivery timelines. They are solutions used by small and large teams. They are solutions employed in medical devices, industrial equipment, scientific sensors, modern high-tech movie sets, and deep inside CPU silicon.
Easy versus Simple
In 1990 I started working in the semiconductor manufacturing industry as an electrical engineer. The sophisticated systems inspected photomasks and included robotics, electro-mechanics, electro-optics, lasers, multiple Sun workstations, single-board computers, bit-slice processors, thousands of custom processing ASICs, and lots of custom analog and digital electronics. So much of what we were doing was on the bleeding edge. It is an exciting and tiring edge to live on and it made me aware that while the innovations were pushing boundaries, it was the systems engineering that allowed such an elaborate system to work at all. We weren’t building one-off scientific instruments, we were building precision, automated measurement equipment that needed to be repeatably manufactured.
Much later in life I learned that I was fighting Rich Hickey’s “complexity” and there was nothing in this job that was “easy”. If you haven’t seen Rich’s amazing 2011 Strange Loop keynote, “Simple Made Easy”, queue it up for watching. Share it with your team, your management, your friends and family.
Easy are the things we know, the techniques that are close-at-hand. Simple is from simplex, meaning things are not tangled up. We don’t need “easy” but we can’t build and maintain these large systems on-time, with quality, and on budget without simplicity.
The techniques I’ll be describing strive for simplicity. They will do this by embracing functional techniques while demonstrating that so much of the FUD in embedded firmware is not grounded in reality.
Some Goals
- Demonstrate composability techniques for building embedded systems
- Demonstrate handling of asynchronous events and concurrency
- Discuss abstractions: the good, the bad, the ugly
- Discuss what types of HALs (hardware abstraction layers) are useful
- Target a popular platform
- Do something fun with the project