This page gives a brief introduction to embedded systems, what they are and why the software is so different from desktop computer software.
What is an embedded system?
When we think about computers and software we normally think of a desktop, a laptop or maybe a smart phone. You tell it which application to run and it goes away and does it. Most of the interaction comes from you, pressing buttons, clicking a mouse, using a touchscreen. You ask for information, the program fetches it and presents it to you when it’s ready.
But there are other much smaller computers all around us. They are part of a larger machine and they interact not with a screen but with the mechanics of that machine. Think of a washing machine, a television, the ABS on your car. Each of these will have a microcontroller running its own small program, doing the same job day in, day out. That device is embedded within the product, and its software, premanently stored within the device itself, is referred to as embedded software.
Such software must run, sometimes for years, without any human intervention. If your computer suffers a fatal application error you just restart the program. If a washing machine leaves the heater on continuously and the water boils, it is not just an inconvenience; your entire wash is ruined. With automotive engine and braking systems the consequence of failure may be severe, even fatal. If there is a problem, the embedded system must deal with it in a sensible manner without relying on user intervention. This is why reliability is so important in embedded systems.
What does real-time mean?
When you request a web page on your computer, the result may come back instantly or it may take a few seconds, or it may never return. It takes as long as it takes.
Real-time software must respond to events as they happen regardless of whatever else is going on, and that response must occur within a short time window – a hard deadline. For example an inkjet printer must release ink droplets at precisely the right moment as the print head travels across the page. If it misses its deadline, the ink drop lands in the wrong spot and the image becomes corrupted. Such precision requires that the system respond within a tiny fraction of a second.
Real-time software presents a much greater challenge and often requires a deeper understanding of the underlying hardware. In a microcontroller such events are often handled using interrupts, where the program jumps automatically to a special section of the software as soon as an event occurs. These interrupts may occur thousands of times per second, and there may be several different events generating interrupts. What happens when two of them happen at once? what happens if the interrupt changes something that you are already working on in a different part of the program? These are issues which the embedded software engineer must consider from the outset in order to make the design work reliably and efficiently.
Before starting to design a circuit we have to consider what it must do, how it interacts with the world around it, what protection mechanisms must be built in to minimise the damage in the event of a fault. Then the designer must consider what sort of circuit can best solve the problem in hand. Sometimes the choice is obvious, but often there are many alternatives and the design choices may involve a tradeoff of cost versus features, reliability, lifetime or some other parameter.
Many designs will include a microcontroller in some form. The reasons for this are obvious in some cases, but in others it might seem like an unnecessary complication and cost. In fact it is very often easier and more cost effective to implement even simple functions in a small microcontroller than it is to use discrete circuitry, with the added bonus of providing greater design flexibility.
The next stage is to draw up the circuit or schematic diagram as they are often known. This is done using a computer CAD package known as a schematic capture program. The resulting design can be printed out or viewed on screen, and there is a set of files which define exactly which pins should be connected together (the netlist) and a list of components used (the Bill of Materials or BOM).
The schematic must then be converted into a printed circuit board (PCB) layout which is used to manufacture the circuit board. This process requires choosing the correct set of connection pads (footprint) for every component and connecting them together using tracks on the PCB. Tracks which carry higher current need to be thicker to avoid power loss. Sensitive tracks such as audio or high speed data need to be routed carefully to avoid picking up electronic noise from other components nearby. And the correct gaps between tracks must be maintained to avoid manufacturing problems.
This is where the integrated CAD package helps out, with built-in error checking to make sure that all connections on the circuit board match up with those on the netlist, and gaps between tracks check against the design rules.
The final step is to generate the manufacturing files: the photoplotter files used to generate the copper layers of the circuit board, the drill file used to generate mounting holes and the vias which connect different layers of the board together, and the board outline file which guides the router as it cuts the final PCB shape out of a larger panel.