Most embedded system developers don’t realize it, but they have three mindset problems that are preventing them from getting to market faster and decreasing their engineering costs. These problems can be found to have their roots all the way back in the 1970’s when embedded system development first began.

 The problems include:

• Customization
• Starting out too low-level
• Believing that all software should be free

Let’s examine each of these problems and see how they affect the way we design embedded systems. 

CUSTOMIZATION

First, embedded systems engineers want to customize everything. In this case, customization can be thought of as starting from scratch. A new project comes down the line and rather than leveraging existing software and hardware that can speed-up development, they decide that they can do it better and faster if they just do it from scratch. This is equivalent to needing new tires on your vehicle and rather than shopping around at the local tire shops for a new set of wheels, firing up CAD software and starting to design a new wheel and claiming that it will be faster and cheaper to redesign and manufacture them than just going down to the store. Obviously, starting from scratch is not going to be faster or cheaper but this is exactly what engineers do every time a new project starts because this is how we have always done it since the industry came into existence.

GROUND UP

Second, embedded systems developers start projects working from the ground up. They jump into the low-level details far too soon. Engineers start to get a few details about the project and usually jump right into trying to find the microcontroller that will best fit their application without giving any thought to whether a preconfigured hardware platform might exist that they can instead build upon. In many cases, this is due to embedded engineers being heavily focused on the bits and the bytes and listening a little bit too much to the chip vendors marketing. We are constantly bombarded with how this new chip available and will make our lives better as developers but the problem is that the chip is just stand-alone and there is so much other stuff that needs to be done before that chip is really useful for an application.

FREE SOFTWARE

Finally, software engineers have concluded that software should be free. The open source movement is pushed heavily on budding engineers at colleges when they have no funds to consider commercial software. By the time they leave the university and enter the workforce, they are convinced the only way to build an embedded system is to use free software (and educational, non-commercial platforms). They aren’t taught or even consider the possibilities that free software has deficiencies such as:

• Code base quality
• Learning curve
• No access to technical support
• Software security management
• Legal issues associated with licensing

This has entrenched the idea that “we don’t need to buy software” which leaves teams with poorly supported code bases and scrambling with business issues that far outweigh the cost of a commercial code base. A simple engineering cost analysis should reveal this deficiency, but they are rarely performed and even when they do, engineers trust their “gut” that the free software will cost less.

3 PRACTICAL RECOMMENDATIONS

There are several ways a developer and team can get away from these problems. First, a developer needs to identify how entrenched these issues are in their own thought processes and open their minds to new and innovative ways to build embedded systems. Second, developers need to stop thinking that free, open source software is the cheapest and fastest route to production. Third, developers need to move away from the low-level, chip vendor thinking and start looking at platforms and solutions that already exist that can be easily modified to meet the requirements. This could be done by using something like the SCM318 which already meets industrial hardware specifications, is built with commercial software and can be easily modified to include the high-level end application.

The mindset changes won’t necessarily be easy and undoubtedly there will be resistance, but the results will undoubtedly result in more robust systems and faster time to revenue. In the next post, we will discuss several ways to create architectural scalability in embedded designs.

A SERIOUS TIP FOR THE THOUGHTFUL ENGINEER

Take a few moments and carefully think through these three problems; customization, starting too low-level and using free software. Are these problems holding you back from being more successful? If so, what steps are you going to take today to remove these barriers?