embedded systems is dedicated computing systems built into larger products to perform bounded functions under power, cost, timing, safety, and lifecycle constraints. They place semiconductor intelligence inside vehicles, medical devices, industrial machines, appliances, communications equipment, and consumer electronics.
Architecture and principles. An embedded platform combines MCU, MPU, DSP, FPGA, or custom SoC with flash, RAM, clocks, power, sensors, actuators, analog interfaces, and communications. Cortex-M and RISC-V MCUs emphasize low power and deterministic peripherals; Cortex-A-class MPUs run rich Linux systems; Cortex-R and safety MCUs emphasize real-time reliability; DSPs accelerate signal chains; FPGAs implement custom timing and interfaces.
Execution and system behavior. Bare-metal firmware offers minimal overhead for small fixed systems. RTOS kernels provide tasks, priorities, timers, queues, synchronization, memory policy, and drivers. Embedded Linux provides processes, networking, filesystems, containers, and large ecosystems at greater memory and startup cost. Bootloaders, device trees, BSPs, HALs, watchdogs, OTA update, diagnostics, and manufacturing provisioning complete the product.
Applications and semiconductor impact. Applications include automotive ECUs, battery management, motor control, infusion pumps, imaging, PLCs, robots, meters, routers, storage, wearables, and appliances. Edge AI adds vision, speech, anomaly, and sensor fusion on NPUs or DSPs. Long-lived products need component availability, stable toolchains, field service, regulatory evidence, and compatibility across hardware revisions.
Trade-offs and current engineering. Resource limits force explicit budgeting of worst-case execution, stack, heap, flash, bandwidth, energy, heat, interrupt load, and startup. Concurrency bugs, priority inversion, memory corruption, EMI, brownout, clock failure, peripheral faults, and unsafe update can dominate. Safety and security require isolation, MPU/MMU, secure boot, signed firmware, watchdog independence, fault injection, coding standards, and traceable requirements.
Verification and lifecycle. A production implementation begins with explicit terminal conditions, operating ranges, loading, accuracy, noise, latency, efficiency, area, cost, lifetime, and fault behavior. Schematic or architectural models establish feasibility; extracted, package, board, thermal, and control-loop models then reveal interactions hidden by ideal sources and loads. Verification spans process, voltage, temperature, mismatch, aging, startup, shutdown, overload, brownout, and recovery. Teams should define measurement bandwidth, observation point, stimulus, pass limit, guard band, and statistical confidence before simulation. Layout review covers current return, thermal gradients, matching, parasitic coupling, electromigration, voltage stress, latch-up, ESD paths, and test access. Correlation retains netlists, models, scripts, tool versions, raw results, lab conditions, calibration status, and explanations for outliers. This evidence turns a nominal design into a reproducible component that can be signed off across device, circuit, package, firmware, and system teams. Corner selection should follow sensitivity rather than blindly combining labels. Deterministic sweeps expose monotonic trends, targeted Monte Carlo analysis estimates distribution tails, and importance sampling can explore rare failures. Reviewers should distinguish model uncertainty from manufacturing variation and avoid claiming yield from too few samples. The interface contract must state what happens outside normal operation. Open and short terminals, reverse polarity, hot plug, disabled bias, floating control pins, clock loss, thermal shutdown, current limiting, and repeated fault cycling often determine field reliability even though they are absent from the nominal transfer function. Dynamic behavior deserves the same attention as steady state. Settling, overshoot, ringing, slew, recovery from saturation, mode transitions, and interaction with external poles can violate a system limit long before a DC endpoint does. Time-domain tests should include realistic edge rates and source impedance. Noise should be referred to the signal or supply point that matters to the application and integrated only over a stated bandwidth. Thermal, flicker, quantization, switching, reference, substrate, and electromagnetic contributions may combine differently across modes, so a single spot-noise number rarely completes the specification. Power and thermal claims should include quiescent, active, transient, and fault states. Average efficiency can hide localized current density or hot spots; electrothermal simulation and temperature-aware device models connect electrical stress to lifetime, drift, and protection thresholds. Physical design must preserve the assumptions behind the schematic. Symmetry, common-centroid placement, dummies, shielding, guard rings, Kelvin sensing, wide current paths, via arrays, controlled coupling, and quiet reference routing are selected according to the dominant error rather than applied as decoration. Production test strategy is part of design. Trim range, observability, loopback modes, built-in self-test, boundary conditions, test time, and instrument uncertainty determine which specifications can be guaranteed economically. Characterization across wafers and lots should feed model and guard-band updates. System telemetry can extend laboratory correlation into deployed products. Error counters, calibration codes, temperatures, supply monitors, fault flags, margin measurements, and performance events help distinguish random failures from systematic drift without exposing sensitive implementation details. A useful comparison normalizes alternatives at equal output requirement and environment. Peak headline values can be misleading when bandwidth, drive, voltage, area, cooling, external components, calibration, or reliability differs; the decision record should name the workload and weighting used. Cross-functional review should trace each requirement from physical mechanism through circuit behavior to application impact. That trace prevents duplicated margin, exposes assumptions that span ownership boundaries, and makes later process or package substitutions safer. Corner selection should follow sensitivity rather than blindly combining labels. Deterministic sweeps expose monotonic trends, targeted Monte Carlo analysis estimates distribution tails, and importance sampling can explore rare failures. Reviewers should distinguish model uncertainty from manufacturing variation and avoid claiming yield from too few samples. The interface contract must state what happens outside normal operation. Open and short terminals, reverse polarity, hot plug, disabled bias, floating control pins, clock loss, thermal shutdown, current limiting, and repeated fault cycling often determine field reliability even though they are absent from the nominal transfer function.
| Processor | Compute character | OS style | Power class | Use |
|---|---|---|---|---|
| Cortex-M MCU | Deterministic scalar + peripherals | Bare metal / RTOS | µW to low W | Sensors and control |
| Cortex-A MPU | Application CPU with MMU | Embedded Linux | W class | Rich gateway and HMI |
| RISC-V MCU | Configurable open ISA microcontroller | Bare metal / RTOS | µW to low W | Custom embedded SoC |
| DSP | MAC and signal-flow optimized | RTOS / specialized runtime | Low to moderate | Audio, radar, motor control |
| FPGA SoC | Custom parallel datapath + CPU | RTOS / Linux | Moderate | Industrial and deterministic acceleration |
<svg viewBox="0 0 760 470" xmlns="http://www.w3.org/2000/svg" font-family="-apple-system,Segoe UI,Roboto,sans-serif">
<rect width="760" height="470" fill="#0d1117"/>
<defs>
<marker id="esBlueArrow" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto">
<path d="M0 0L10 5L0 10Z" fill="#60a5fa"/>
</marker>
<marker id="esGreenArrow" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto">
<path d="M0 0L10 5L0 10Z" fill="#34d399"/>
</marker>
<marker id="esGoldArrow" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto">
<path d="M0 0L10 5L0 10Z" fill="#f59e0b"/>
</marker>
<filter id="esMotorGlow" x="-50%" y="-50%" width="200%" height="200%">
<feGaussianBlur stdDeviation="4" result="blur"/>
<feMerge><feMergeNode in="blur"/><feMergeNode in="SourceGraphic"/></feMerge>
</filter>
</defs>
<text x="380" y="31" fill="#e6edf3" font-size="21" font-weight="700" text-anchor="middle">Embedded System — Software Controls a Physical Machine</text>
<text x="380" y="53" fill="#8b98a5" font-size="12.5" text-anchor="middle">a sensor-triggered computation must update the actuator before its real-time deadline</text>
<!-- Setpoint comes from the product/user, not from the processor itself -->
<g transform="translate(26 104)">
<text x="71" y="-10" fill="#c4b5fd" font-size="10.5" font-weight="700" text-anchor="middle">COMMAND</text>
<rect width="142" height="85" rx="11" fill="#171426" stroke="#a78bfa" stroke-width="1.7"/>
<circle cx="38" cy="43" r="22" fill="#211936" stroke="#a78bfa" stroke-width="2"/>
<path d="M38 43l12-13" stroke="#e9d5ff" stroke-width="3" stroke-linecap="round"/>
<circle cx="38" cy="43" r="4" fill="#e9d5ff"/>
<text x="79" y="35" fill="#c4b5fd" font-size="9">target speed</text>
<text x="79" y="55" fill="#e6edf3" font-size="14" font-weight="700">1800 rpm</text>
</g>
<path d="M168 147H205" stroke="#a78bfa" stroke-width="2.5" marker-end="url(#esBlueArrow)"/>
<!-- MCU is drawn as a real mixed hardware/software control device -->
<g transform="translate(211 78)">
<text x="166" y="-8" fill="#93c5fd" font-size="10.5" font-weight="700" text-anchor="middle">MICROCONTROLLER · HARDWARE + FIRMWARE</text>
<rect width="332" height="215" rx="13" fill="#0b1726" stroke="#60a5fa" stroke-width="1.8"/>
<!-- Package pins -->
<g stroke="#64748b" stroke-width="2">
<path d="M-8 29H0M-8 52H0M-8 75H0M-8 98H0M-8 121H0M-8 144H0M-8 167H0M-8 190H0"/>
<path d="M332 29h8M332 52h8M332 75h8M332 98h8M332 121h8M332 144h8M332 167h8M332 190h8"/>
</g>
<!-- Peripherals capture the physical event -->
<g transform="translate(15 19)">
<rect width="83" height="57" rx="7" fill="#142b44" stroke="#60a5fa"/>
<text x="41.5" y="18" fill="#93c5fd" font-size="9" font-weight="700" text-anchor="middle">TIMER CAPTURE</text>
<path d="M10 39h12V28h14v11h14V28h14v11h10" fill="none" stroke="#38bdf8" stroke-width="2"/>
<text x="41.5" y="51" fill="#8b98a5" font-size="7.5" text-anchor="middle">encoder period</text>
</g>
<!-- Interrupt controller turns an edge into scheduled work -->
<path d="M98 47H120" stroke="#60a5fa" stroke-width="2" marker-end="url(#esBlueArrow)"/>
<g transform="translate(124 19)">
<rect width="83" height="57" rx="7" fill="#211936" stroke="#a78bfa"/>
<path d="M16 43l12-30 8 21 8-12 8 21h16" fill="none" stroke="#c4b5fd" stroke-width="2"/>
<text x="41.5" y="51" fill="#c4b5fd" font-size="7.8" text-anchor="middle">INTERRUPT</text>
</g>
<!-- CPU executes the bounded controller -->
<path d="M207 47H229" stroke="#a78bfa" stroke-width="2" marker-end="url(#esBlueArrow)"/>
<g transform="translate(233 19)">
<rect width="84" height="57" rx="7" fill="#172a24" stroke="#34d399"/>
<text x="42" y="18" fill="#6ee7b7" font-size="9" font-weight="700" text-anchor="middle">CONTROL TASK</text>
<text x="42" y="35" fill="#e6edf3" font-size="10.5" text-anchor="middle">e = ω* − ω</text>
<text x="42" y="49" fill="#8b98a5" font-size="7.5" text-anchor="middle">PID / state feedback</text>
</g>
<!-- State and code live in different memories -->
<g transform="translate(15 97)">
<rect width="84" height="49" rx="7" fill="#161a20" stroke="#52647b"/>
<g fill="#8b98a5" font-size="8.2" text-anchor="middle">
<text x="42" y="18">FLASH · code</text><text x="42" y="35">SRAM · state</text>
</g>
</g>
<path d="M99 121H122" stroke="#52647b" stroke-width="1.7"/>
<!-- Shared bus -->
<path d="M57 166H275M57 146v20M166 76v90M275 76v90" fill="none" stroke="#3a4453" stroke-width="3"/>
<text x="166" y="181" fill="#6b7684" font-size="7.8" text-anchor="middle">memory-mapped peripheral bus</text>
<!-- PWM timer converts software output into precisely timed edges -->
<g transform="translate(124 97)">
<rect width="83" height="49" rx="7" fill="#211b0d" stroke="#f59e0b"/>
<path d="M10 33h15V15h24v18h15V15h10" fill="none" stroke="#fbbf24" stroke-width="2"/>
<text x="41.5" y="44" fill="#fbbf24" font-size="7.5" text-anchor="middle">PWM TIMER</text>
</g>
<!-- Watchdog catches missed progress -->
<g transform="translate(233 97)">
<rect width="84" height="49" rx="7" fill="#23171b" stroke="#f87171"/>
<circle cx="25" cy="24" r="12" fill="none" stroke="#f87171"/>
<path d="M25 24v-8M25 24l7 4" stroke="#fca5a5" stroke-width="1.7"/>
<text x="59" y="21" fill="#fca5a5" font-size="8" text-anchor="middle">WATCH</text>
<text x="59" y="34" fill="#8b98a5" font-size="7.5" text-anchor="middle">reset on stall</text>
</g>
<text x="166" y="203" fill="#93c5fd" font-size="8.5" text-anchor="middle">deterministic peripherals reduce software timing uncertainty</text>
</g>
<!-- PWM drives power electronics, not the motor directly -->
<path d="M543 202H573" stroke="#f59e0b" stroke-width="2.7" marker-end="url(#esGoldArrow)"/>
<g transform="translate(580 166)">
<text x="65" y="-10" fill="#fbbf24" font-size="10.5" font-weight="700" text-anchor="middle">POWER STAGE</text>
<rect width="130" height="75" rx="10" fill="#211b0d" stroke="#f59e0b" stroke-width="1.7"/>
<!-- H-bridge -->
<g stroke="#fbbf24" stroke-width="2" fill="none">
<path d="M24 18v39M106 18v39M24 28h24M82 28h24M24 48h24M82 48h24M48 28v20M82 28v20M48 38h34"/>
</g>
<circle cx="65" cy="38" r="12" fill="#32270f" stroke="#f59e0b"/>
<text x="65" y="41" fill="#fbbf24" font-size="8" text-anchor="middle">H</text>
<text x="65" y="68" fill="#8b98a5" font-size="7.8" text-anchor="middle">switches motor current</text>
</g>
<path d="M710 203H725Q738 203 738 190V158Q738 145 725 145H679" fill="none" stroke="#f59e0b" stroke-width="2.5" marker-end="url(#esGoldArrow)"/>
<!-- Physical plant: motor/shaft/encoder -->
<g transform="translate(595 83)">
<text x="53" y="-8" fill="#6ee7b7" font-size="10.5" font-weight="700" text-anchor="middle">PHYSICAL PLANT</text>
<circle cx="53" cy="43" r="31" fill="#10251f" stroke="#34d399" stroke-width="2" filter="url(#esMotorGlow)"/>
<text x="53" y="49" fill="#6ee7b7" font-size="18" font-weight="700" text-anchor="middle">M</text>
<path d="M84 43h42" stroke="#94a3b8" stroke-width="7"/>
<circle cx="126" cy="43" r="17" fill="#15202c" stroke="#93c5fd" stroke-width="2"/>
<g stroke="#93c5fd" stroke-width="2">
<path d="M126 27v9M126 50v9M110 43h9M133 43h9M115 32l6 6M131 48l6 6M115 54l6-6M131 38l6-6"/>
</g>
<text x="126" y="72" fill="#93c5fd" font-size="8" text-anchor="middle">encoder</text>
<path d="M37 19A30 30 0 0 1 77 24" fill="none" stroke="#34d399" stroke-width="2" marker-end="url(#esGreenArrow)"/>
<text x="53" y="90" fill="#8b98a5" font-size="8.5" text-anchor="middle">speed ω + load</text>
</g>
<!-- Encoder feedback closes the physical control loop -->
<path d="M721 126H738Q744 126 744 139V318Q744 332 730 332H78Q63 332 63 317V273Q63 258 78 258H199" fill="none" stroke="#38bdf8" stroke-width="2.7" marker-end="url(#esBlueArrow)"/>
<text x="470" y="325" fill="#7dd3fc" font-size="9.5" text-anchor="middle">encoder edges report actual motion → next interrupt corrects the error</text>
<!-- Timing strip makes real-time correctness visible -->
<g transform="translate(28 362)">
<text x="352" y="-10" fill="#e6edf3" font-size="10.5" font-weight="700" text-anchor="middle">ONE CONTROL PERIOD · THE RIGHT ANSWER MUST ARRIVE ON TIME</text>
<path d="M0 62V0M0 62H704" stroke="#3a4453"/>
<g stroke="#3a4453" stroke-dasharray="3 3">
<path d="M86 0v62M185 0v62M426 0v62M602 0v62M704 0v62"/>
</g>
<!-- Encoder sample -->
<path d="M5 47h62V15h19v32h99" fill="none" stroke="#38bdf8" stroke-width="2"/>
<text x="43" y="12" fill="#7dd3fc" font-size="8.5">encoder edge</text>
<!-- ISR -->
<rect x="86" y="23" width="99" height="22" rx="4" fill="#211936" stroke="#a78bfa"/>
<text x="135" y="37" fill="#c4b5fd" font-size="8.5" text-anchor="middle">ISR · capture</text>
<!-- Control compute -->
<rect x="185" y="23" width="241" height="22" rx="4" fill="#142b44" stroke="#60a5fa"/>
<text x="305" y="37" fill="#93c5fd" font-size="8.5" text-anchor="middle">read state · compute control · safety checks</text>
<!-- PWM register update -->
<rect x="426" y="23" width="176" height="22" rx="4" fill="#211b0d" stroke="#f59e0b"/>
<text x="514" y="37" fill="#fbbf24" font-size="8.5" text-anchor="middle">write next PWM duty</text>
<!-- Slack -->
<rect x="602" y="23" width="102" height="22" rx="4" fill="#10251f" stroke="#34d399"/>
<text x="653" y="37" fill="#6ee7b7" font-size="8.5" text-anchor="middle">timing margin</text>
<path d="M704 5v55" stroke="#f87171" stroke-width="2.5"/>
<text x="700" y="12" fill="#fca5a5" font-size="8.5" text-anchor="end">deadline</text>
</g>
<text x="380" y="455" fill="#6b7684" font-size="11" text-anchor="middle">Embedded correctness combines logic, timing, electrical limits, fault response, and physical behavior.</text>
</svg>
Connection to CFS platform. Use CFS architecture, accelerator, memory, cloud, edge, security, networking, power, and system simulators with linked glossary topics to connect foundational concepts to measurable semiconductor and deployment choices.
Explore 500+ Semiconductor & AI Topics
From EUV lithography to CUDA optimization — search the full knowledge base or chat with our AI assistant.