How-to Articles

Understanding software and hardware bugs in other embedded systems can help you identify, diagnose, and fix bugs in your own.

The placement of knobs, buttons, and switches is as essential as the firmware to making a usable embedded system.

Designing firmware-accessible debugging resources into embedded systems provides a valuable supplement to hardware test and analysis tools.

These built-in troubleshooting resources for direct memory access (DMA) controllers can pave the way for smoother embedded software integration.

State machines are perhaps the most effective method for developing robust event-driven code for embedded systems.

If you looked closely at just about any computer system around you, you'd probably find out that at any given time it is doing... nothing useful. That is, most of the time the CPU is either hibernating in one of its power-saving modes or busily "twiddling its thumbs" by executing an idle loop. (Modern PCs are particularly good at the latter form of doing nothing—they can "twiddle their thumbs" a billion times per second all while driving a screen saver.)

In State Machines for Event-Driven Systems, I touched on the benefits of using state machines in programming reactive (event-driven) systems. However, while the traditional Finite State Machines (FSMs) are an excellent tool for tackling smaller problems, it's also generally known that they tend to become unmanageable even for moderately involved systems.

What is the Design by Contract programming philosophy, what can it do for you, and why should all embedded software developers care?

Metaphors and analogies can be valuable tools for learning new software concepts and tapping subject matter expertise during embedded software development.

A state machine is any object that behaves different based on its history and current inputs.  Many embedded systems consist of a collection of state machines at various levels of the electronics or software.

This article provides an introduction to state machines fundamentals plus practical advice for implementing them in C or C++. I hope that these simple techniques can become more common, so that we can more often easily see the state-machine structure right from the source code.

SAE J1939 is the standard communications network for sharing control and diagnostic information between electronic control units (ECUs) which reside on heavy duty and commercial vehicles. Examples of such vehicles are school busses, cement mixers, military vehicles, and semi-tractors.