Bridging the Human-Hardware Divide: Insights From an Embedded Developer

Introduction 

Embedded systems are fascinating – but trying to explain them to a non-engineer is quite a challenge. They power everything from your smartwatch to your car, yet describing what they do can feel like explaining quantum mechanics to your dog. Embedded development is filled with complexity, low-level details, and often, as you surely know, a lot of frustration. Imagine assembling a piece of IKEA furniture, only to realize near the end that you missed a step, and now your bathroom cabinet looks like a stylish coffin. That’s what our work with hardware can feel like – following every instruction, only to have some unexpected quirk throw off your entire plan. 

Getting a microcontroller to do something simple like reading a sensor can in some cases end up as a maze of datasheets, register settings, and unexpected hardware behavior. Been there with, say, ultrasonic sensors. And that’s just the basics. Real embedded challenges will begin when you are enabling a poorly documented MMU in Linux kernel for a custom silicone, and it has the potential of turning into a horror show. It's the 21st century – shouldn't embedded development be more intuitive and efficient by now? 

The complexity of embedded development

Embedded development means dealing with quirks of different silicone implementations, real-time constraints, and low-level details. For experienced engineers, register manipulation can be fun (and the secret sauce of job security). But for many – including juniors or those coming from application-level programming – it can feel like falling into a rabbit hole of documentation and tricky interactions. 

Chip manufacturers provide their own libraries and tools, creating vendor-specific environments. These tools can simplify hardware access but also create proprietary solutions that vary greatly, tying customers to their products. In hobby projects, like Arduino, existing frameworks usually do the job, and you are happy to use them. But in production code, safety and security mean vendor code must at least be adapted to project needs and carefully reviewed for safety and security, adding complexity that diverts attention from core engineering. 

Tools that (try to) abstract complexity 

Can we simplify the process without losing control? Here are some emerging tools and technologies:

–Domain-Specific Languages (DSLs) let developers express what they want without worrying about low-level details. Unfortunately, in the embedded world, such tools are still quite rare and often tightly coupled with specific vendors, making them difficult to generalize. An example of a DSL is Chisel, which is used for designing hardware in a more abstract and high-level way compared to traditional HDLs. 

–Embedded development tools like PlatformIO are designed to make embedded development easier. They automate peripheral setup and provide abstraction layers for microcontroller platforms, helping developers get started faster. However, these tools can only take you so far. They, for instance, focus on C/C++, leaving Rust developers in the cold, and depend heavily on vendor-specific toolchains. This ties you to their environment and tools, limiting flexibility and binding whole projects to certain ecosystems.

–AI-augmented IDEs use AI to assist in development. Tools like GitHub Copilot can suggest code snippets, but they don’t (yet?) handle low-level tasks well. AI can provide coding assistance, but it doesn't replace the detailed knowledge needed for specific hardware interaction. 

–Hardware abstraction frameworks like mbed (RIP, unfortunately) standardize peripheral interfaces across platforms, shielding developers from low-level details while allowing deeper dives when needed. However, these frameworks also have those expected limitations, such as supporting only specific architectures like ARM, with limited compatibility for others like RISC-V, and again focusing on C/C++. 

The future of embedded IDEs 

Let’s speculate for a moment. Could we create an IDE that understands datasheets for MCUs, sensors, and memory, and automatically generates working code? Imagine asking it, as a stretch: "Create a function that reads the aux temperature sensor (you know, the one on GPIO12) every 10 seconds and triggers an alert if it exceeds 30°C." Could it handle the rest? 

If we could make this work, the benefits would be huge. Developers would save countless hours currently spent on manual configurations and digging through datasheets. Such a solution could also truly make embedded development vendor-agnostic. Instead of getting stuck in low-level hardware setup, developers could focus on high-level system design and more creative problem-solving. It could also reduce human error, leading to better safety, reliability, and fewer sleepless nights. 

But to get there, we’d need more than just advanced AI models. We’d need Domain-Specific AIs, specifically trained to understand datasheets and schematics. Beyond that, frameworks would be necessary to connect AI with hardware simulation tools and datasets of real-world examples. So, where are we lacking? Is it better AI models, or the comprehensive datasets and frameworks needed to train them and tie everything together? Maybe the solution lies in a cross-vendor initiative for standardization, or a brave startup ready to tackle this ambitious challenge? 

In my view, technology already exists – it’s just a matter of time. Automating configuration and creating intuitive hardware integration will revolutionize embedded development. We just need the pieces to come together. 

For a practical example, take the pin configuration tools provided by NXP for their CPUs. These tools are vital for configuring complex SoCs, and they don’t introduce anything new. They simply streamline the vast amounts of data from datasheets, helping developers manage the mind-boggling complexity of pin options and register configurations. Could an AI replicate this level of assistance? Maybe, but it wouldn’t be easy. It would need a subsystem capable of loading all pin options, register configurations, and other technical data from a database directly linked to the datasheets. Such a database would be key to helping developers configure the system according to the hardware design. 

The challenge grows when you consider hardware schematics. For an AI to assist fully with pin configuration, it would need to interpret schematics, align them with the hardware layout, and match them to the correct CPU pin functions. This isn’t science fiction, it’s within reach – but it would require sophisticated AI, robust databases, and seamless integration between software and hardware design tools.

Most importantly, it would require a level of confidence in the AI’s output that many embedded engineers just don’t have right now. We might end up with another fancy tool to admire while we continue manually configuring pins like it’s 1995. Who knows? 

Concluding thoughts 

In embedded development, many of us spend hours dealing with hardware quirks, wondering if there’s a better way. Every day, we see new AI tools creating websites and applications, showcasing impressive automation. Meanwhile, embedded development feels stagnant, stuck in vendor-specific environments that tie developers to proprietary tools and make cross-platform work harder. The future – more intuitive tools and smarter abstractions – suggests a path where embedded developers can focus on creative solutions, not low-level configurations. 

We’re not there yet, but the emerging tech shows promise. In my view, the goal is to make embedded development about solving engineering challenges, not just debugging platform-specific code tangled in vendor-specific tools. While every innovation edges us closer, the embedded community still needs a significant push forward to really get there. And, of course, all the old-school embedded engineers will still be configuring registers by hand – because why let AI take away the fun of meticulously setting every bit manually? 

Have questions or insights to share? feel free to contact us for expert help. You can also visit here to learn more about us! 🙂