Embedded architectures

Embedded design is fundamentally different because each of those characteristics inverts an assumption that general-purpose programming takes for granted, and together they demand a different way of thinking. Dedicated: an embedded system does one specific job forever, so you design the whole system, hardware and software, around that single function, rather than writing general software to run on someone else's general machine; the program, the chip, and the I/O are co-designed for the task. ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Resource-constrained: where a PC programmer assumes effectively unlimited memory and processing, an embedded developer works with kilobytes of RAM, limited Flash, a slow clock, and a tight power budget, so efficiency isn't a nice-to-have but a hard requirement: every byte and cycle counts, data structures and algorithms are chosen for smallness, and wasteful abstractions are unaffordable. Real-time: many embedded systems must respond within strict deadlines (a motor control loop, a safety cutoff), so correctness includes timing (being right too late is wrong) which forces attention to determinism, interrupt latency, and worst-case timing that general programming rarely considers. Hardware-interfacing: the program directly manipulates physical hardware through registers, GPIO, and peripherals, reading sensors and driving actuators, so the developer must understand the electronics and the chip's registers, not just abstract data. Software and hardware are inseparable. Framing embedded work by these traits matters because it sets the defaults and priorities of every design decision: you assume scarcity and design for efficiency, you assume deadlines and design for determinism, you assume direct hardware control and design around registers and peripherals, and you assume a single dedicated purpose and co-design the whole system for it. A developer who approaches an embedded system as 'a small PC' brings the wrong assumptions (expecting abundant resources, ignoring timing, abstracting away the hardware) and produces software that doesn't fit, misses deadlines, or can't talk to the hardware. So the mindset isn't a label; it's the lens that makes you design appropriately for what an embedded system actually is, which is exactly why understanding it first frames the entire topic.

The MCU-vs-MPU distinction is foundational because it's one of the first and most consequential decisions in an embedded design: it determines the system's capability, cost, power, complexity, real-time behaviour, and software model, and it follows directly from the structural difference between the two. A ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍microcontroller integrates the CPU, memory (RAM and Flash), and peripherals onto a single chip, making it self-contained: it needs little external support, boots and runs its one program immediately (bare-metal or under an RTOS), draws little power, costs little, and behaves deterministically. Ideal for dedicated, real-time control where the job is specific and the constraints are tight. A microprocessor is essentially just the CPU; it requires external RAM, external storage, and supporting circuitry, and it runs a full operating system (typically Linux): making it far more powerful and capable of complex software (vision, networking, multitasking, rich libraries) but also bigger, more power-hungry, more expensive, more complex to design around, and less inherently real-time. So the structural difference (everything-on-one-chip versus a-CPU-that-needs-a-computer-built-around-it) maps onto exactly the trade-offs that decide the fit. If the job is dedicated control with hard real-time needs, low power, low cost, and modest computation (a robot's motor/sensor controller, an appliance, a sensor node) the MCU's self-containment, determinism, and efficiency make it the right choice; an MPU would be overkill, power-hungry, and harder to make real-time. If the job demands heavy computation, complex software, networking, or a rich OS (computer vision, a high-level robot brain, connectivity-heavy applications) the MPU's power and OS support are necessary, and the MCU couldn't do it. Real systems often use ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍both: an MPU for the complex high-level work and one or more MCUs for the dedicated real-time control, each playing to its strength. Recognizing that the choice flows from this self-contained-vs-needs-support structure (and the capability/power/cost/real-time trade-offs it implies) is what lets you pick the right processor for the job: a decision that shapes the entire rest of the design, which is why it's foundational.

An embedded system is best understood as a single-purpose appliance-brain rather than a general computer. Think of the brain inside a thermostat, a washing machine, or a robot's motor controller: it's dedicated to one job, it lives with tight limits (a little memory, a little power), it often has to react right on time (meet deadlines), and it's directly wired to the physical world (reading sensors, driving motors). That's completely different from a PC, which is a general machine with loads of memory and power for running anything, so you design an embedded brain for its constraints and its one job, not like a desktop. Now, there are two flavours of brain. A microcontroller (MCU) is a whole tiny self-contained brain on one chip: it has the thinking part (CPU), its memory, and its connections to the outside world (the I/O) all built in, ready to do its dedicated job straight away, sipping little power. It's like the complete little brain inside an appliance. A ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍microprocessor (MPU) is more like a bare computer CPU, just the powerful thinking part, that needs external memory and storage bolted on to become a small general computer (like a Raspberry Pi running Linux). So you pick each for different jobs: the self-contained appliance-brain (MCU) for dedicated, real-time control that must be cheap, low-power, and reliable (the robot's motor and sensor controller); the small computer (MPU) for heavy, complex work like vision or networking (the robot's high-level brain). Often a robot has both. A powerful small computer for thinking and several tiny self-contained brains for the real-time muscle-and-sense control. A dedicated, constrained brain for one job, in two flavours (self-contained appliance-brain or bare-CPU-needing-support) chosen for the kind of work: that's the big picture of embedded systems.

Architecture decision (MCU + MPU: use both):

Embedded characteristics driving the choice: - The control job is dedicated, real-time, resource-constrained, and hardware-interfacing: exactly the MCU's strengths (self-contained CPU+memory+peripherals, deterministic timing, low power). - The vision job is complex, computation-heavy. Needing the MPU's power and OS (an MCU couldn't do it). - So the robot uses both: the MPU thinks (vision/planning), the MCUs do the real-time muscle-and-sense control, communicating between them, each playing to its strength.

Memory-model considerations: - On the MCU: distinguish Flash (holds the program/constants, non-volatile) from RAM (working data, volatile), both tightly limited, so design efficiently (small data structures, often static allocation, no reliance on a big heap), mindful of stack and code size (and the ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Harvard model for speed). - On the MPU: external RAM/storage and an OS give far more memory, but it's not inherently real-time.

How this framing shapes the design: recognizing the robot has two kinds of job (dedicated real-time control vs complex computing) leads to the MCU+MPU split, which is how real robots are built; the embedded constraints (real-time, limited memory/power, hardware interfacing) dictate how you program the MCUs (efficiently, for determinism, around registers/peripherals); and the memory model (Flash vs RAM, tight limits) governs what fits and how you allocate. The big-picture framing (what an embedded system is, MCU vs MPU, the memory model) shapes every subsequent decision (peripherals, RTOS, memory management, low power), which is why it comes first.