Development Techniques for Using Simulation to Remove Risk in Software/Hardware Integration

Requirements of Embedded Systems

There is a continuing explosive growth in the embedded systems market, particularly 32-bit MCUs. For desktop systems, functionality is probably the single most important driving force in the market. But for embedded systems, functionality has less significance, because it cannot be at any cost.

Embedded developers often have a requirement for volume production, where even the smallest cost increases can make a large difference to end-user price tags. The consequence of slow code is the need for a faster, and hence more expensive processor, which in turn may cause battery life to be reduced. Similarly, higher ROM/RAM usage means the inclusion of larger, more expensive, memory chips. The consequence in the embedded marketplace is that software functionality is often intentionally limited to reduce these costs.

But why should embedded systems have such restrictions on their functionality? The problem is that modern software may provide more functionality than that actually required by the developer. Instead, a lot of extra code and support is also pulled in, under the auspices of providing generic support for situations that the embedded developers are not concerned with, and won't encounter in their systems. This also makes software unnecessarily complex - the more code that is present, the more chance there is of something going wrong.

For example, if you write a simple "Hello world" program with most modern RTOS's, you may still get full support for mutexes, threads, task switching, C++ constructors, clocks, timers, and so on. This is because it is impossible for RTOS authors to predict what type of application the embedded developer will be writing, and so they have to cater for many differing requirements.

A "one size fits all" approach is fairly acceptable for the desktop, but causes problems for the embedded world.