Perfect software
Surge protectors will most often save our systems from an imperfection introduced by us. A self-healing system that captures that one nasty bug that escaped our PDP tests might save the system.
And so, I've long wondered why MPUs are so uncommon in the embedded space. Intel's 386 processor brought memory management to the desktop a quarter century ago; who hasn't used Task Manager to kill off an errant app? The operating system and other programs generally run on benignly despite the crash.
An MPU segments the address space into a number of smaller areas, each usually owned by a task or application. The MPU defines access rules: Task A cannot write in this area and can only execute from another region. Essentially each activity operates in its own sandbox. Bad code might foul its own sandbox but can't reach out nastily to the rest of the system.
Hardware in the memory manager watches every transaction and immediately interrupts code that tries to break the rules. Developers can write a handler to shut the task down, restart it, or take some other action to bring the system to a safe and known state.
When the 386 came out developers reacted with a storm of protests. Many complained that writing protected mode code was too hard. I haven't heard that complaint in a long time, as the tools improved and now hide the MPU meddling behind a curtain of abstractions. Some RTOSes also provide insulation from the grittiness of handling memory management. Some, like the new version of µC/OS-II, even use the hardware resource to guarantee that activities get a chance to run. Real-time does mean managing time, and so this is an important feature.
MMUs are testosterone-enhanced MPUs. They include the MPU's protection scheme but add virtual memory. Logical memory gets mapped under software control into the physical address space.
In the many years I've been writing about embedded systems the industry has grown and the applications we develop have gone from tiny things, really, to hugely complex multi-million lines of code monsters. The good news is that we've gotten better: I really don't think the approaches used decades ago would have scaled to the problems we solve today.
This is an exciting time to be in the field. There is no stasis here, not in the processors and I/O we use, nor in the tools that are available. Static analysis, virtualization, MMU/MPUs and a host of other resources are ours for the buying.
But first, above all, we must approach our projects with an intolerance for bugs. The code might not all be perfect, but PDP is a pretty good goal, too.
Jack Ganssle (jack@ganssle.com) is a lecturer and consultant specializing in embedded systems' development issues. For more information about Jack click here .
Loading comments... Write a comment