What you’ll learn:
- What are the main issues behind the “painful” process of embedded-systems design?
- Shortages of resources, components, and talent plague the design process.
- How the instability of toolsets and driver sets add to the difficulty.
Having been involved with the development of products with sophisticated requirements for diverse capabilities, no part of the process is more challenging than development of the embedded software. To the observer in the physical world, embedded software is invisible, but this low-level code is the backbone of electronic systems. Developing embedded-systems software is usually quite difficult and often involves the most experienced members of a product development team.
The natural question is “What makes embedded-systems design so painful?” The answers are many. Here are a few:
1. Timing issues
Debugging timing-related issues, especially when working with application processors, is a severe pain point. The challenge here is understanding how to “peel the onion” and remove the layers of abstraction from application layer, to OS layer, down to bare metal/driver layers, to hardware.
Embedded-systems engineers often have to develop unique ways to debug these systems to isolate the failures. These problems are most noticeable on hardware bootup, when sequencing the timing of all the code execution. It takes a cross-disciplinary team to debug and “get it right” because the issues can be related to hardware, embedded software, or both.
2. Limited resources
When developing IoT devices with low-end processors, there’s always a challenge to use the available resources (memory, I/O, bandwidth, etc.) to do what you want in an energy-efficient way (especially in battery-powered devices).
3. Component shortages
This is one of the biggest challenges today and it affects both the hardware and requisite embedded software. Material shortages are driving companies to reevaluate architectures and implementation strategies based on component availability. This would be difficult enough if not for the fact that the availability of supply isn’t static but in constant flux. It’s causing many hardware and firmware developers to iterate in ways that are painful, time-consuming, and costly.
4. Unstable driver sets
Engineers pick a hardware set, and the vendor offers a generic driver set for development purposes. Unless the hardware is very mature, the drivers aren’t always stable or well tested. Likewise, these sets can be bloated or sluggish as the chip vendor tries to create a “one-size-fits-all” into the driver. Even drivers for dev platforms like Arduino are limited in functionality and aren’t bulletproof.
Unstable drivers from manufacturers have always been an issue. To some degree it’s understandable, as many small changes to debug the chip hardware will result in problems with drivers not performing well.
5. Dealing with firmware updates
Especially when working with the latest and greatest radio technology, the firmware seems to need daily updating to address bugs and features. Dealing with a stream of firmware updates from the chip manufacturers in parallel with product hardware development is a challenge.
For engineers involved with early-stage chipsets, to stay ahead of the hardware and firmware while concurrently developing circuitry and embedded process code isn’t easy. OTS generic drivers are designed for general cases but may not have stable, well-documented source code. Also, the code may not be very streamlined; it can be inefficient and become a resource hog.
6. Development toolsets can be unstable/incompatible
Toolsets are updated frequently, but you must lock down on a version if you’re ever to be finished. Free tools aren’t always stable, resulting in code that doesn’t compile. Oftentimes, a new release of a toolset renders old source/SDKs incompatible with the new toolset. The problems in debugging can sometimes be traced to code coming out of the toolset that’s not well documented, is resource inefficient, and/or difficult to trace. Some provided HAL layer code just isn’t optimized enough for hard real-time scenarios.
7. Processor upgrade issues
Jumping from micro to micro often isn’t as easy as claimed. Even when vendors claim full compatibility between hardware revisions, the claims must be tested. Many times, subtle (or not- so-subtle) changes to hardware and firmware are required to move to a newer hardware version, even within the same processor family or series.
8. The talent challenges
Good embedded-systems engineers are in short supply. This has been the case for years. Today, despite COVID effects on the overall labor market, the talent you need is very hard to come by. As a result, engineers in embedded systems are challenged to keep up with little relief in sight.
Problems in embedded software require a multidisciplinary expertise in both software and electrical engineering. Because the challenges are so difficult to resolve, it takes years of experience to be able to perform efficient design and debugging.
Overall, drivers and tools have improved over the years, but with every “new and improved” chipset comes a new set of embedded-software challenges. While new toolsets have tried to abstract hardware and make it easier/faster to bring product functionality to life, when it comes to real-time and production-ready robust designs, discipline and diligence are still always required. Nothing comes for free.
The adage “nobody said this would be easy” is nowhere more appropriate than in embedded-system development. The job remains challenging and, dare I say, interesting. Embedded-systems engineers are deploying design skills and are hence creating new products that were unimaginable just a few years ago.