Developing software for embedded systems is different and arguably more complex than software intended to be used in an Information Technology-focused PC environment. For thirty years the paradigm for Personal Computers followed the progression of mainframe and mini-computer models for computing. These models have evolved to rely heavily on abstracting the operating environment into a common programming interface in which applications are separated fully from essential underlying hardware.   Where PC software is most often completely divorced from the environment, embedded systems are intimately involved with their environment.


Commercial software development tools have benefited from decades of tool development and millions of man-years of usage by professional programmers. These general purpose software development tools have a wide range of little-used capabilities that can empower embedded software developers. Single processor/single core CPUs are straightforward platforms for development and software debug and lack some of the complicating aspects of multi-core systems.

Uniprocessors (CPUs with only one processor) can support multiple threads but only one thread actually executes at a time. Still, having tools to trace the operation of threaded software can aid both the understanding of how threads work in practice and debugging code that has been written to use threading. Green Hills Software®, Inc (1) offers MULTI EventAnalyzer as part of their Multi Integrated Development Environment (IDE). Part of the Time Machine Suite, the EventAnalyzer centers on a graphical display of operating system events.  These events include essential information such as kernel service calls, interrupts, exceptions, and context switches. This information is often viewed primarily as an optimization tool – operations that take the most time are obvious meaning that developers can spend time on optimization efforts that will have the best payback. But the EventAnalyzer can be a good learning tool for new members of a development team.




Being able to capture operating systems events are a “nice to have” feature for uniprocessors, but when development moves to multi-processors or multi-core processors the feature goes from a nice feature to a “must have” capability.


When developing with a threading environment all drivers and libraries must be “thread safe.” But adding multiple processors adds an additional requirement on software: everything must be priority inversion safe as well. Priority inversion can happen when software executes on more than one processor. Priority inversion is a problem of scheduling in which a higher priority task is indirectly preempted by a lower priority task. This effectively inverts the relative priorities of the two tasks. Such situations apparently violate the priority model - high priority tasks can only be prevented from running by higher priority.

By way of illustrating the problem we’ll use a task called L, with low priority. This task uses a resource called R. Assume that L is executing and it gains control of resource R. The problem comes in when  there is another high priority task H that also requires resource R. If H starts after L has acquired resource R, H has to wait until L relinquishes resource R. Everything works as expected up to this point, but problems arise when a new task M starts with medium priority during this time. Since R is still in use (by L), H cannot run. Since M is the highest priority unblocked task, it will be scheduled before L. Since L has been preempted by M, L cannot relinquish R. So M will run till it is finished, then L will run - at least up to a point where it can relinquish R - and then H will run. Thus, in above scenario, a task with medium priority ran before a task with high priority, effectively giving us a priority inversion.


Green Hills’ Event Analyzer shows developers the operating systems calls graphically. It’s straightforward to detect this situation by looking just at the task statuses. Wind River Systems® (2) adds another capability to their tool chain called Simics.




Wind River Simics simulates everything from a single processor, system-on-chip (SoC), or board to the most complex system conceivable. Simics can simulate an entire system including racks of platforms, with each running different operating systems on different processor architectures. One of the goals of Simics is to allow all developers, testers, and integrators to debug/test and integrate the system as a single unit rather than working with individual system pieces as has been the case. Lest you think that these facilities are more than required for developing embedded systems, consider large scale embedded systems like telecom central office functions implemented by racks of dedicated embedded systems. Or, think of alternative systems hardware portioning such as might be found in Digital Signage in which displays are remote but the embedded computing could be performed in a physically localized fashion.

Experts at Green Hills, Wind River, and Intel® offer these tips for multi-core development:


  • Consolidate the hardware as much as possible.
  • Employ virtualization.
  • Choose Symmetrical Multi Processor Operating System if building on a  homogeneous processor base, or an Asymmetrical Multi Processor Operating System if using some specialty processors like Digital Signal Processors.
  • Select libraries that have been optimized for multi-core use – when operating on fewer cores the code will still operate.
  • Adopt driver software and OSes that are both thread and priority inversion safe.
  • Develop software that makes maximum use of threading since it can simplify software development and also adapts to a new platform embodying more cores with little effort.
  • Enforce coding standards that minimize the ability to violate priority models while encouraging maximum architectural parallelism consistent with the selected processor family.


Chances are that your company has already standardized on a specific tool chain. Regardless of the vendor, most tool chains support the Eclipse standard. Green Hills tools embrace Eclipse as part of the framework. Eclipse is recommended by the company to extend the range of capabilities provided in the EventAnayzer tool to meet unique requirements. Wind River’s tool chain also uses Eclipse as part of their framework. Wind River has been a strong supporter of the Eclipse efforts -contributing software to the industry wide effort.


Embedded systems are gaining in complexity at a rate faster than implied just by the growth of Integrated Circuit complexity. Developing embedded systems is a challenging undertaking that demands a series of development techniques that are new to the embedded community.

How will you adapt your tool chain to fit evolving embedded requirements?




  1. Green Hills Software, Inc  is an Affiliate member of the Intel Embedded Alliance
  2. Wind River Systems is an Associate member of the Intel Embedded Alliance


Henry Davis
Roving Reporter (Intel Contractor)
Intel® Embedded Alliance