Dotshock | Dreamstime.com
Embedded Dev Team Promo 60b10c9f17e0e

Pain Points for Embedded Software Design

June 2, 2021
Developing embedded-systems software is extremely challenging and often the domain of the most experienced members of a product development team. So, what makes embedded-systems design so painful?

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.

About the Author

Mitch Maiman | President and Cofounder, Intelligent Product Solutions

Mitch Maiman is the President and Cofounder of Intelligent Product Solutions (IPS), a leading product design and development firm. He honed his deep knowledge of product design on the strength of a 30-year career with companies that manufacture commercially successful products for the consumer, industrial, and DoD markets. Prior to launching IPS, Mitch was VP of Engineering at Symbol Technologies.

Always espousing a hands-on approach to design, he holds a portfolio of numerous United States and international patents. Mitch holds a Bachelor of Science from Hofstra University, a Master of Science in Mechanical Engineering from Columbia University, and an MBA from Fairleigh Dickinson University.

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!