Hardware-Less Embedded Software: Embracing Application-Centric Development
Taking a hardware-less embedded software approach allows you to start developing, testing, and even validating software without a single chip in hand.
November 20, 2024
At a Glance
- Start with the application and work your way back down to the hardware.
- Define key features and begin modeling and simulating your application.
- Test your application on a development machine, simulate hardware responses, and only then move on to hardware.
Back when I first started in embedded systems, everything was about hardware. You had to get that board running, flash some LEDs, write a few drivers, and then pray everything played nicely together. It was gritty, challenging work—but we loved it because it was hands-on. Fast forward to today, though, and we’re finding new ways to tackle embedded software that make things faster, smoother, and honestly a lot more effective. Enter the “hardware-less” approach.
Hardware-less embedded software isn’t just a fancy new trend. It’s actually a different way of thinking, one that shifts the focus off the hardware and squarely onto the application itself. Think about it: in the hardware-less world, we can start developing, testing, and even validating software without a single chip in our hands. In today’s post, we’ll explore how to embrace a hardware-less approach, how it works and why it’s changing embedded development as we know it.
Starting with the application: The hardware comes later
In a hardware-less approach, it’s all about being application-centric. Instead of starting by setting up low-level hardware drivers and writing peripheral routines, we start with the features—the stuff users will interact with.
Imagine building a house. Do you start with the wiring and plumbing, or do you start by deciding what kind of house you want to build? Hardware-less development is like designing the house first. We focus on what the software will do, break it down into features, and only integrate hardware once everything else is solid. This way, developers can spend their time building and testing real functionality, rather than getting bogged down in hardware setup.
When I first started to develop embedded systems, we’d spend the first 3 – 6 months just digging through microcontroller datasheets and writing drivers. As far as we were concerned, there was no customer or real application that had to be delivered. At least, not until we had the foundation for making the microcontroller work. Can you imagine all the issues you eventually encounter when you work that way?
It was extremely common to tightly couple your code to the hardware. Since all you thought about was the hardware, you’d optimize the heck out of the code. Don’t get me wrong, you’d write some fast and elegant code, but did the application really need it? Who knows, we didn’t know anything about the application because you can’t think about that until you have the hardware up and running.
What happens though if you flip the script? What if you start from the top, the application, and work your way back down to the hardware?
Flipping the script: The top-down approach
So, how do you go hardware-less? It’s a top-down process, almost like taking the “map view” of your application rather than zooming in on the “streets.” There are five key points that we should consider on how going hardware-less plays out.
First, you begin by defining the key features of the application. Break it into bite-sized pieces that can be developed and tested independently. I personally like to do this by identifying all the data assets in the system and then tracing how that data will flow through my application.
Second, with an understanding of the data and how your system might be broken up into components, you can begin modeling and simulating your application. You model the application, test how features interact, and refine the design—all before touching any actual hardware.
Third, you build and test your application on a development machine (like your PC) instead of on the embedded target. This lets you code with a much more powerful debugging environment than you’d have on a microcontroller. You can easily adopt modern practices like Test-Driven Development (TDD) and CI/CD to help you write your application fast without the hardware getting in the way.
Fourth, you adopt a test harness so that you can simulate hardware responses. If you did your job right in the previous steps, your hardware interacts exist behind abstractions that know nothing about the hardware. You can test application logic as if it were running on the final product with being coupled to the final hardware!
Finally, you can integrate with the hardware. Once your application is running and stable in simulation, you integrate it with the actual hardware, where only the hardware-specific aspects need real-time testing.
Things won’t be perfect the first go around, but you’ll find that you are able to work much faster and test far more of your code than if you just relied on developing it on target.
Taking the next steps toward a hardware-less approach
Going hardware-less may feel like a radical shift, but it’s a natural evolution in a field where we’re expected to deliver faster, more-reliable results on tighter deadlines. By focusing on the application itself, using abstractions, leveraging automation, and testing off-target, we can develop highly modular, testable code. When the time comes to integrate with real hardware, it’s not a painful guessing game—it’s just the final step in a well-rehearsed process.
So, what next steps should you take to start to adopt a hardware-less approach to embedded software development? Here are three simple steps:
Start with designing a data-driven software architecture. Analyze your systems inputs, outputs, transfers, storage, and conversion mechanisms. The result will help you understand how data flows through your system and help you identify a flexible and scalable architecture.
Focus on writing application features first, not low-level driver code. If you write application features, you’ll quickly encounter where your code wants to tightly couple to hardware. Resist the urge and design abstractions that break the dependency of your application code the hardware.
Use a simulation or test harness to validate your application code without hardware. Only if you can show your boss or customer a completed feature without hardware have you truly started to develop hardware-less embedded software.
Once you able to complete these three steps, you’ll find that you can easily scale and adapt your software architecture. You won’t be dependent on the hardware team to provide you hardware, which means you can start implementing features early, increasing the likelihood that you’ll deliver on-time and budget. A hardware-less approach makes that possible, and it’s a shift well worth considering.
About the Author
You May Also Like