hardware//embedded system

An embedded system is a computer built into a larger machine to do a fixed job under constraints of time, energy, size, cost and certification, and it is where every algorithm of a closed loop actually runs: the flight controller of a drone, the PLC of a press, the drive of a pump, the vision board of a robot. On a whiteboard computation is free, clocks agree and nothing is late; on the metal there are 2 ms to do everything. So the useful question is which is the best algorithm that fits the budget.

An embedded system is a computer built into a larger machine to do a fixed job under constraints of time, energy, size, cost and certification, and it is where every algorithm of a closed loop actually runs: the flight controller of a drone, the PLC of a press, the drive of a pump, the vision board of a robot. On a whiteboard computation is free, clocks agree and nothing is late; on the metal there are 2 ms to do everything. So the useful question is which is the best algorithm that fits the budget.

That budget is paid in several currencies at once (the computing platform as budget). Cycles and worst-case time; memory; energy and weight, since on a 1.5 kg quadcopter hovering on about 200 W a 15 W companion computer takes some 7 % of the flight time before its own weight is counted; cost per unit; and certification, because some software cannot go on an aircraft when nobody can demonstrate what it does.

The embedded computing platforms come in six families, each good at one thing. The MCU (a Cortex-M at 100 to 600 MHz) is the workhorse of deterministic loops at 1 to 10 kHz. The FPGA gives massive parallelism at fixed nanosecond latency, for current loops and radar. The PLC runs the plant, robust and maintainable. The industrial PC with real-time Linux coordinates axes and runs rich software. The embedded GPU (a Jetson) perceives. The server or cloud learns, analyses the fleet and simulates in bulk.

The platform decides what is possible, and the decision cascades down to stability: the hardware fixes the sampling rate, the sampling rate fixes the delay, and the delay fixes the phase margin. An MPC is bounded by its solver, a network by its accelerator and quantization, consensus by the radio, and everything by the worst case of real-time computing.

The platform selection order follows from that cascade. First the latency and determinism of the most demanding loop; then the kind of computation (branches and I/O, or massive linear algebra); then energy, cost and certification; last, what your team can maintain. A drone stacks the families: each ESC's microcontroller commutates at tens of kHz, the autopilot estimates and controls at 250 Hz to 1 kHz, a companion computer runs vision and planning at 1 to 30 Hz, the cloud does analytics (autopilot, edge computing). A robot cell repeats the pattern: current loops in the drive, trajectories at 1 to 4 kHz over EtherCAT, sequencing in the PLC every few milliseconds, production planning in minutes.

Every added processor is power, heat, software and one more failure mode, so if the job fits on the chip already there, it stays there.

What surrounds the chip completes the system: an RTOS (real-time operating system), its firmware and the watchdog timer that resets it if it hangs, middleware to its neighbours (ROS 2) and the questions of distributed systems once several boards must agree, the MLOps that keeps its models alive, and the systems engineering that proves it all meets the requirement.