The Top 3 Problems Holding Back Embedded Systems Engineering

The Top 3 Problems Holding Back Embedded Systems Engineering

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. 


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.


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.


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.


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.


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?


How to Scope Your First HMI Project

How to Scope Your First HMI Project

Many embedded systems today use a human machine interface (HMI) to interact with the users and world around them. HMI’s are so common that a first time HMI developer often under estimates the total extent of what is necessary to successfully pull off the project. In this post, we will examine what is necessary to scope your first HMI project and make it a success.

Usually the first instinct a developer has when working on an HMI project is to build the solution from scratch. I often see developers start by searching the internet for cheap LCD’s, video graphic chips, single board computers and even start to generate block diagrams for building their own custom display module. There are several major issues with going down this path such as:

  • Significant time investment
  • Substantial monetary investment
  • Scalability issues as hardware such as the LCD changes over time
  • Creating and maintaining the software that drives the LCD

Rather than starting at the implementation level, first time HMI project developers should take a 30,000-foot view and think through the entire HMI process to fully understand everything that will need to go into the project.

There are four major areas that a developer needs to consider in order to make their HMI successful that covers far more than just driving a LCD. These include:

  • User Interface (UI) / Graphical User Interface (GUI)
  • Communications
  • Firmware and Infrastructure
  • Hardware

Developers should start their scoping process in the same order that these major areas are listed.

The UI/GUI can make or break a product. A user isn’t going to care about the underlying hardware or what it is does. Their main care is whether the UI is intuitive, fast and easy to use. In order to achieve these factors, a developer needs to make time to map out the menu’s and functions within their UI and also follow a creative process  to provide the UI with a good look and feel. The more options available in the user interface, the more time that will need to be allocated for creating graphics, reviews and testing.

Many first time HMI developers overlook how important communications can be in their project and often create extremely complex solutions to have their HMI communicate with the external world. This often stems from starting with a hardware focus and working up into the higher-level requirements. Leveraging existing communication modules such as the SCM208 or the SCM318 can simplify the need for complex hardware designs and decrease development time by avoiding the typical design cycle issues.

If developers spend most of their time focusing on their HMI and how that HMI will communicate with the external world, essentially focusing on their products value add for their clients, they can then minimize the time spent developing firmware, infrastructure and hardware by looking at their HMI and communication requirements and finding existing solutions that support their HMI needs. They can then completely eliminate the need to develop hardware and instead can focus on the HMI design which will prevent them from reinventing the wheel. Most of an HMI project should be spend on the HMI and not on developing the components that support the HMI like the hardware, software and infrastructure.

In the next post, we will start to explore how developers can simplify device communications in the IoT age using existing communication devices.


Creating an HMI for the first-time developer can be a bit overwhelming. Please check-out two resources for ideas on how to develop and design an HMI:


The Siren’s Call of the Pseudo Platform

The Siren’s Call of the Pseudo Platform

Technology companies are in a hurry. In many development environments, product is needed ASAP or yesterday and engineers are scrambling to deliver as quickly as humanly possible. In order to help their clients meet these grueling demands and schedules, microcontroller suppliers and even niche product companies have started to pave the path by providing developers with building blocks to get up and running more quickly. The problem with this approach is that in many cases these building blocks are being pitched as platforms and developers are buying into a pitch believing that they are getting more when they are getting less. So, what exactly is a platform?

A platform is a complete package that a developer can build upon to add their unique value so that they can achieve their end desired result. In a perfect world, a platform is something a developer can leverage that has everything – hardwaresoftwarecommunicationsproduction support, etc., — that they need to just add that smallest bit of extra hardware or code to make their product amazing, unique, cost effective, scalable, manufacturable, sustainable, and evolvable.

Using a display module as an example, we would expect a display module platform to include all the hardware and software necessary to boot and execute an HMI. A developer would only need to customize the highest-level software to get the look and feel they want and interact with their surrounding environment. The platform would also include that customization software, SHIPTide being the equivalent in this example.

To phrase it another way, imagine a platform as a completely constructed home that only requires the finishing touches and decorations to meet its owner’s needs. Unfortunately, embedded engineers are often pitched so-called platforms, implying fully built, integrated and tested hardware, software and app-ready infrastructure, but instead they get disjointed basic building blocks that in some cases haven’t even been production tested. It’s the equivalent to buying a home and arriving with the moving truck only to discover a construction site with 2×4’s and drywall stacked neatly and ready for you to build the house yourself. The tools (and even the blueprints of the finished house!) of course you need to provide yourself and suddenly your stuck asking yourself what you’ve just gotten yourself into.

There are several key features that a developer should be looking for in order to successfully identify a platform. These include:

  • Fully packaged and tested hardware ready to go out-of-the-box
  • Tested and integrated software drivers and stacks
  • A cohesive toolchain designed to put the finishing touches on the application

The above list are just the tangible engineering related topics that should be considered. When thinking about a platform from a much broader and strategic standpoint, teams should also be considering characteristics beyond the hardware and software capabilities such as whether the platform is:

  • Purchasable
  • Sustainable
  • Affordable
  • Scalable
  • Maintainable
  • Evolvable
  • Upgradable
  • Differentiable

When trying to identify a platform, a developer should be asking themselves, “If the platform provider went any further, would they be selling product to my clients?” If the answer is yes, then you’ve successfully found a true platform and not just software building blocks. If the platform you’re looking at doesn’t have these features, cover your ears and eyes to avoid the Siren’s call.

A Serious Tip for the Thoughtful Engineer

Have you been bitten by a vendor pitch that they have provided you everything you need only discover that you have the building blocks? If so, don’t worry, we’ve all been there. The trick is to learn our lesson and put the right plan in place to recover. You can do this by using the platform features we’ve discussed today to test your vendors and by using Serious Integrated Modules (SIMs) as an example of a real developer platform.