| Episodes | 104 |
| Mentions | 159 |
| Cited here | 37 |
| First — last | #1 — #722 |
| Top guests | Elecia White, Jack Ganssle, Todd Bailey |
| Related | fpga · linux · arduino · internet of things · microcontroller |
An embedded system is a complete computing system built into a larger product: firmware runs across processors, memories and interfaces and controls hardware directly at the register level.[479][131] The usual boundary between an embedded target and a general-purpose Linux machine is the memory management unit, while task scheduling and interrupt-driven response are the same ideas at both scales.[589] The subject matters at industrial scale because small microcontrollers sell in the billions each year and because a code-size or component choice repeated in every unit can become a multi-million-dollar decision.[54][634]
Definition and scope
Embedded work is characterised by direct access to hardware: the registers are visible, the layers above them are under the developer’s control, and faults can be reasoned about from first principles rather than through other people’s abstractions.[131] Abstraction remains the standard way to manage complexity in general computing, but in embedded systems the details underneath keep surfacing and affecting behaviour that has to be accounted for.[634]
The practical scale is often small: a working embedded practice can sit entirely at 60 MHz and below, where half a megabyte of RAM exceeds what the application needs and a few hundred kilobytes of flash is a large program.[187] At the other extreme, a Linux-class single-board computer is a poor default for many embedded jobs on power grounds alone, since it can demand five volts at a couple of amps where the task does not justify it.[428]
A recurring external misconception is that software which runs in a browser should also run on an embedded target, and comparisons to old game consoles ignore how tightly that code had to be written for its hardware.[187] Bit-banged timing that barely worked from the general-purpose pins of an earlier Linux board can fail on newer boards because the path to the pins is slower and far more variable once other bus traffic contends with it; dedicated programmable I/O is the usual fix.[648]
History and market structure
The field dates from the first microprocessor in 1971 and the first eight-bit part a year later; engineers entering then learned digital design and software on the job because their employers did not yet have that knowledge in-house.[54] Trade-press framing that treats anything below a fast 32-bit part as obsolete misrepresents the market.[54]
Small parts sell in the billions per year into applications whose entire program occupies hundreds of words of memory, which is why the predicted disappearance of the eight-bit microcontroller has failed to happen for two decades.[54] A large share of microcontroller customers are domain experts rather than software engineers, writing a few hundred words of program around expertise in a field such as motor control and wanting something simple, while cheap small processors keep opening applications nobody had imagined.[489]
Large processor vendors have entered and left the embedded market repeatedly, including discontinuing lines of connected development boards, so vendor commitment is a factor when choosing a platform.[351] In memory supply, large customers return failing modules as entire batches rather than as individual units because one fault is treated as a threat to fleet reliability, putting millions of dollars of leading-edge product at stake in a single incident.[474]
Hardware and runtime environment
Operating systems and concurrency
Some robotics work runs without a real-time operating system because the RTOS latency is not worth paying for, while audio and visual-effects work requires at least knowing what the operating system is doing underneath the application.[187] Zephyr brings Linux-style configuration and a large body of pre-written components to real-time embedded work, at the cost of pulling down every vendor SDK it supports, which runs to tens of gigabytes.[509]
The actor model maps naturally onto embedded work because each unit is isolated and communicates by message rather than shared state, removing much of the usual difficulty of getting concurrent processes to talk.[295]
Languages and managed runtimes
Firmware remains C with some assembly and C++, and where cost is not the binding constraint an inexpensive 32-bit ARM part is hard to argue against unless the design specifically needs programmable logic.[492] In a memory-safe language targeting hardware, even writing to a peripheral register counts as unsafe under the memory model, so unsafe blocks are unavoidable rather than a sign of bad code, and the skill lies in the practices that make them correct.[590]
A full standard library ported to a small wireless part provides threads and mutexes rather than a stripped-down environment, enough to write a stable power-monitoring watchdog for a main processor in a couple of hundred lines.[614] Deferred logging avoids the classic cost of print debugging: format strings are never compiled into the binary, only symbols, so the device transmits a few bytes of pointer instead of spending flash space and serial time on text.[614]
Managed runtimes carry fixed overhead: one managed-runtime embedded platform had a smallest achievable footprint of 64 kilobytes of RAM regardless of what the program did, almost entirely runtime overhead.[12] A high-level language runtime is nonetheless a reasonable entry point when its layers can be peeled back as needed, since the implementation underneath is open C that can be optimised by anyone with the skills.[383]
System architecture
Distributed and connected products
On a launch vehicle, a single compute node with every sensor and actuator wired to it is not a viable architecture, so the design starts by classifying which kinds of problem exist before choosing hardware.[584] Even a simple vehicle accessory becomes a distributed system, with nodes scattered through the vehicle each running their own logic while reporting state back to a controller that verifies all of them for safety.[645]
Connected products are systems of systems demanding embedded, security, RF, protocol, cloud and mobile expertise at once; even a fully staffed team has nobody who is expert at the joins, and writing a backend update service requires understanding how the device performs its own firmware handshake.[526] Putting perception into a genuinely embedded device means running the vision workload on a dedicated chip and emitting only metadata, such as an object’s coordinates in metres, over a simple serial link to a small microcontroller.[517]
Programmable logic and heterogeneous integration
Small programmable-logic parts occupy the niche that complex programmable logic once filled, offering lookup-table fabric and distributed RAM without signal-processing blocks, which suits connecting assorted interfaces in an embedded design.[395] On a combined processor-and-fabric device, a safety path running from a custom peripheral through bare-metal code into Linux and back carries real timing cost, and the design questions are buffer depth, how often the operating system services the interface, and what happens to accumulated data when the call does not come.[466] The compensating advantage of that integration is that the link between the programmable fabric and the processor cores is never the bottleneck, unlike a design that has to serialise data between two separate chips.[466]
Developing against a soft processor is faster on the host first: the same scripts that read and write peripheral registers over a bridge can later run unchanged on the core itself, so the debugging conveniences of a full workstation remain available until the code is right.[375]
Constraints, cost and manufacture
Code produced by following a convention without examining it has been found to run four or five times the size of the application itself, which translates into a larger microcontroller in every unit and becomes a multi-million-dollar decision at automotive volumes.[634] The organisational problem behind that outcome is that engineering decisions rarely carry a visible cost because purchasing and engineering sit in separate parts of the company.[634]
Customers who insist that a few dozen bytes per message is too small are usually sending text-encoded structures; packing the same information as bits removes the constraint entirely.[427] Recognisable sentinel values are useful when scanning memory during troubleshooting, but on a very small system they consume bytes that the application needs.[16]
A measurement instrument that replaced a rack of bench equipment was built on a processor module with external SRAM rather than a microcontroller, chosen for deterministic timing across many serial ports and interrupt sources, and the entire development ended in a production run of ten units, a common shape for instrumentation work worth knowing before committing to a custom design.[419] A prototype-level board cannot simply be handed to a high-volume line: reaching volume means design optimisation for power and cost plus building test automation, which are prerequisites rather than afterthoughts.[661]
Rolling a custom development board is no longer a business in itself because equivalents already exist far more cheaply; the workable model is building hardware in support of teaching material and selling the content rather than the board.[675] A project with no hard price target and no hard specification accumulated features, never got certified and never shipped, which is the argument for imposing constraints on one’s own designs.[675]
Development, debugging and verification
Debugging is hard because the object under test is a complete system rather than a circuit or a desktop program: firmware is now large, it runs across several parts, and pieces can be broken through no fault of the developer, down to a mislabelled component.[479] As a system grows, the temptation is to change variables and re-run to see whether it works; deliberately slowing down and recording what was tried both forces thought beforehand and leaves a log of the attempts.[170] One practical habit is to use whatever output the product already has as the instrument, displaying variables on the product’s own screen or indicator rather than reaching for external equipment.[170]
Newcomers from software connect a logic analyser to a running board, see an idle bus and conclude that nothing is happening, when the traffic they wanted occurred during boot; pressing reset makes it appear.[318]
Verification in embedded work is still often subjective bench observation rather than automated testing, and practices such as continuous integration arrived late because the field is old enough to have settled habits.[537] Hardware deliverables are governed by long-established quality processes while firmware quality is the weaker side of the same consultancy work, and the framing that helps is treating firmware as professional work with the same delivery expectations.[492]
Security
Every industry that makes a physical good is somewhere along the curve of putting microcontrollers into it, which means the security surface now follows the embedded system wherever it goes, consumer or industrial.[265] Hardware security work uses the instruments engineers already own — oscilloscopes, logic analysers, supplies, programmers and debug interfaces — so the shift required is one of perspective rather than equipment: asking how the interfaces that help the developer can be used against the product.[575]
Education and entry
The recommended route into the field for an engineer from another discipline is to buy a development board and build a robot with it.[187] Beginner platforms present a false appearance of simplicity by concealing complexity, which is acceptable for starting out but leaves the learner with nowhere to stand the moment something needs fixing.[356] Learning embedded work bottom up, starting from how registers behave, is separate from learning to program, and it is what makes it possible to reason about a system that is not doing what was expected.[356]
Industrial control taught through programmable logic controllers can make no sense as classroom logic and only become clear on a factory floor, where the physical motion and audible feedback supply the meaning the diagrams lacked.[620]