Processors
MCU
Microcontrollers are the workhorses of most embedded systems. All microcontrollers have some form of a general purpose computing core and memory. From there there’s a wide array of peripherals, which handle specific tasks at the hardware level. Nearly ubiquitous peripherals include things like general purpose I/O, timers, communications (serial, I2C, SPI, etc.), and interrupts. Some microcontrollers also have hardware random number generators, support for more complex communications protocols (CAN, USB, ethernet), analog electronics components (such as op-amps or instrumentation amplifiers), or additional ways to offload computational work from the main compute core (for example hash/cryptography units or direct memory access).
While the datasheets for many microcontrollers look daunting, once you get the hang of it you learn how to find and digest the small number of pages you have to, instead of getting lost in the 1000s of others. And programming MCUs is usually done in C/C++ (nowadays you can even use Python on some, at the cost of a lot of program memory for the interpreter, and a big hit in performance). So they are among the easiest to use of the embedded devices described on this page.
A look inside an XMEGA
Some of CBA’s favorite MCUs include:
- 8-bit AVR MCUs: ATtiny, AVR-DB series
- ATXMEGA series
- ATSAMD11/SAMD21
- ATSAMD51
- NRF52
- STM32
- ESP32
These MCUs support primary clock speeds ranging from a few megahertz to a few hundred megahertz. Main clock speed doesn’t necessarily tell you how fast an MCU will be in sensing and responding to its environment, however, since that involves the speed of the relevant peripherals as well. Measuring ring oscillation rates is a good way to quantify an MCU’s maximum performance when going from bits to atoms and back.
One advantage of the 8-bit AVRs over the powerful 32-bit SAMD family is the simplicity of the peripheral interfacing, with the ability to perform advanced tasks in a single instruction cycle.
A recent development in the peripheral world is the inclusion of some FPGA-like features. Atmel calls this configurable custom logic (see e.g. the ATTINY214). Rasperry Pi calls it programmable I/O (see e.g. the Pico).
Additional resources:
DSP/CODEC
DSPs are specialized microcontrollers for signal processing; they come with the appropriate ADC/DAC and a special set of instructions to handle data transforms with a high vectorization and/or bitrate.
CODECs are essentially just the peripherals from a DSP, tailored for a particular task. For example, the TI PCM2906C can sample a stereo audio signal at 48kHz, and send the data to your computer over USB and play another stereo channel of output. This all happens in hardware; there’s very little coding involved.
MPU
A microprocessor is typically a compute-only IC – most I/O peripherals not included. Since they lack peripherals, they require additional chips to provide a clock signal, memory, and I/O (at least). However chips marketed as MPUs tend to have more powerful processors than MCUs. They’re also usually intended to run an operating system, unlike most MCUs. The CPU in your computer is a microprocessor, though it probably wasn’t marketed as an “MPU” since that acronym is more commonly used in the embedded systems world.
Modular Systems
In the real world, when you want to run a real OS™ (e.g. Linux) in an embedded system and have needs that demand a custom PCB, it is very rare to use a bare MPU and do all the bringup yourself. This is globally-repetitious work — unless you’re very space-, power-, or otherwise-constrained, it’s unlikely that you need to build the canonical application circuit, power regulation, RAM and peripheral integration, etc. yourself.
In most cases, a vendor will sell you a partially-integrated system that solves most of these problems for you. There are various ways of achieving this at different modularity levels, technologies, and interfaces for different reasons, discussed in the following sections.
SoC
A System-on-Chip (SoC) is a single IC that integrates all of the components required for a complete “system”, according to the designer’s conceptualization. This always includes a processor in some form, and frequently includes RAM, storage, some power regulation, and any I/O peripherals not included in the processor (anything in the “MPU” section listed as additional supporting chips).
Apple Silicon is a prominent example of adoption of the SoC design philosophy. RAM, GPU cores, and additional coprocessors are all on-die, where in a traditional consumer computer these components would be separated out into individual packages interconnected by traces on the motherboard. This approach affords Apple certain benefits in the silicon design — interconnects on-chip are very high-bandwidth and low-latency, meaning that it can be dynamically-allocated and simultaneously used by both the GPU and CPU.
Credit: AnandTech
Most smartphone processors use SoCs, e.g. the Qualcomm Snapdragon series are all SoCs.
The Allwinner SoC series is a set of very popular, low-cost, Linux-capable Arm SoCs. The H- and A-series are in particular worth looking at.
SiP
Credit: Wikimedia User Verdel
Systems-in-Package are externally identical to SoCs — the difference is that SiPs are single IC packages rather than unitary silicon dies. Internally, they contain multiple components to produce the same end result.
SoM
Credit: Raspberry Pi Website
Systems-on-Module (SoMs) are board-based, rather than chip-based. They tend to omit user-interfacable ports in favor of connectors, pins, or castellated board edges that can be integrated instead through carrier boards.
Paradigmatic examples include the Raspberry Pi compute module series, which can be paired with the Compute Module IO Board for development.
Generic Modules
It’s worth mentioning that this concept of the “module” exists independently of the specific SoM concept (which implies a “full system”). You can frequently find modules that integrate some specific functionality between a few chips, without representing a complete environment suitable for bringup of a general-purpose OS.
A couple of examples:
SBCs
Single board computers are complete computer systems built on a single board. This is in contrast to:
- Traditional PCs and smartphones
- Motherboard with socketed, interchangeable components
- Often interconnected with additional daughterboards
- Large, single intended application (desktop, laptop, phone)
- Arduino boards (not general-purpose computers – MCU-based, no general-purpose OS)
SBC examples:
- Raspberry Pi
- BeagleBone
- PCDuino
Phones and recent laptops are closer to the SBC paradigm than desktop computers, as they often solder almost all components (including RAM and flash memory) in-place. This can save cost and potentially produce a more-performant system (since the manufacturer knows exactly what RAM will be used and can tune the whole system together), but limits modularity — you can’t slot in an additional stick if you decide you want more memory later, or one of your current chips goes bad.