Embedded Systems

Introduction

An embedded system is a computing system designed to perform one or a small set of functions as part of a larger product or technical process. Unlike a general-purpose personal computer, an embedded system is usually optimized for a defined combination of timing, cost, energy, physical size, reliability, safety, and maintainability. Embedded systems appear in vehicles, medical equipment, industrial controllers, household appliances, scientific instruments, communication devices, robots, and Internet of Things products.

At university level, studying embedded systems means learning to reason across the boundary between hardware and software. You must understand what the electronics can do, what the firmware must guarantee, what timing constraints exist, how peripherals communicate, how faults are detected, and how a design can be tested before it becomes part of a real product.

The image above shows several modern microcontroller boards. Development boards make laboratory work easier because they expose pins, power connections, debug interfaces, and often USB connectivity. A finished embedded product, however, normally integrates only the circuitry that the application actually needs.

This introductory Microchip video is useful for reviewing the basic idea of a microcontroller before moving to university-level design questions.

Learning Goals

After working through this aiMOOC, you should be able to explain the architecture of a microcontroller-based system, distinguish hard and soft real-time requirements, interpret a peripheral data sheet, select suitable interfaces, design interrupt-driven firmware, reason about concurrency, compare bare-metal software with an RTOS, estimate timing and energy budgets, use debugging instruments, and propose measures for reliability, safety, and security.

You should also be able to justify design trade-offs. In embedded engineering, a technically correct solution is not automatically a good solution: a faster processor may consume more energy, an RTOS may improve modularity but add complexity, a high-speed bus may use more pins, and a powerful software abstraction may make worst-case timing harder to predict.

Hardware Foundations

Microcontrollers, Microprocessors, and System Context

A Microcontroller typically integrates a processor core, program memory, data memory, clock and reset circuitry, and multiple peripherals on one integrated circuit. Common peripherals include GPIO, timers, PWM units, analog-to-digital converters, serial interfaces, watchdog timers, and direct memory access controllers. This high level of integration reduces component count and can lower cost and power consumption.

A Microprocessor is usually optimized for higher computing performance and often depends on external memory and more complex support circuitry. Systems based on application processors commonly run Embedded Linux or another rich operating system. The boundary is not absolute: modern system-on-chip devices combine many functions, and some embedded products contain both microcontrollers and application processors.

An Arduino Uno is an example of a microcontroller development platform. It is useful for learning digital I/O, timers, serial communication, and firmware structure, but professional embedded development normally requires deeper control over clocking, memory, interrupts, power modes, and debugging.

The Raspberry Pi Pico illustrates another microcontroller development approach. Boards in this class are useful for experimenting with deterministic I/O, timers, ADCs, and low-level peripheral access without the full software stack of a desktop-class computer.

Processor and Memory Architecture

Inside a microcontroller, the processor executes instructions stored in non-volatile memory such as Flash while working data is held in SRAM. Many microcontrollers use a modified Harvard architecture internally, with separate pathways or caches for instructions and data, even when software sees a unified address space.

Important memory regions include program Flash, SRAM, peripheral registers, boot memory, and sometimes EEPROM or other non-volatile storage. Firmware often divides SRAM into static data, stack, and heap. Stack usage matters because every function call, local variable, interrupt, and task context may consume stack space. Heap allocation offers flexibility but can create fragmentation or nondeterministic behavior if used carelessly.

In many microcontrollers, peripherals are memory mapped. Reading or writing a particular address accesses a hardware register rather than ordinary RAM. This mechanism allows C or C++ code to configure GPIO direction, timer prescalers, interrupt flags, ADC channels, and communication peripherals.

The keyword volatile tells a compiler that a value can change outside the normal flow of code, for example because of hardware or an interrupt. It does not make an operation atomic and does not by itself provide thread synchronization. Concurrency must still be designed explicitly.

Clocks, Reset, and Power-On Behavior

An embedded system begins with reset and clock configuration. A microcontroller may use an internal oscillator, an external crystal, a phase-locked loop, or several clock domains. Clock configuration affects CPU speed, timer resolution, serial baud rates, power consumption, and peripheral timing.

A robust startup sequence typically establishes a valid stack, initializes memory, configures clocks, sets safe default outputs, initializes peripherals, and then enters the application. Brownout detection can force reset when supply voltage becomes too low for reliable operation. A bootloader may verify or update the application before transferring control.

Inputs, Outputs, and Peripherals

GPIO and Digital Signals

GPIO pins can read digital input states or drive digital outputs. Although the software interface may look simple, correct hardware design requires attention to voltage levels, current limits, pull-up and pull-down resistors, switch bounce, electromagnetic interference, and safe startup states.

A button connected directly to a GPIO input can generate several fast transitions when pressed. Debouncing can be performed with hardware, software timing, or both. The correct method depends on how quickly the event must be recognized and whether false transitions are acceptable.

Timers, Capture, Compare, and PWM

Hardware timers are central to embedded systems. They can generate periodic interrupts, timestamp external events, measure pulse widths, count external signals, or trigger peripherals without constant CPU intervention.

Input capture stores a timer value when an edge arrives. It is useful for measuring frequency, period, or pulse width. Output compare changes an output or generates an event when a timer reaches a programmed value. PWM produces a periodic waveform whose duty cycle can control LED brightness, motor drivers, heaters, and power converters.

For a timer clock f and a desired period T, the product f × T tells you how many timer ticks are required before accounting for prescalers. You must also verify that the counter width can represent the needed range.

ADC, DAC, and Signal Quality

An ADC converts an analog voltage into a digital code. Resolution tells you how many discrete codes are available, but effective accuracy also depends on reference quality, noise, input impedance, sampling time, calibration, and board layout. A nominal 12-bit ADC does not guarantee 12 bits of noise-free measurement.

A DAC generates an analog level from a digital value. If the microcontroller has no DAC, filtered PWM is sometimes used as an approximation. For control and measurement tasks, always distinguish digital resolution from overall system accuracy.

Direct Memory Access

DMA allows a peripheral and memory to exchange data with limited CPU involvement. For example, an ADC can place samples into a buffer while the CPU performs calculations, or a UART can transmit a block while application code continues. DMA can improve throughput and reduce interrupt load, but it introduces synchronization questions: software must know when a buffer is valid, who owns it, and whether cache maintenance is required on more complex processors.

Firmware Execution Models

Super Loops and State Machines

A small embedded program can run as a super loop: initialize once, then repeatedly execute application logic. This model can be efficient and easy to inspect. Its main risk is accidental blocking. If one function waits too long, every other activity in the loop is delayed.

Finite state machines are a powerful way to structure event-driven firmware. A state represents the current mode of operation; events cause transitions; actions occur on entry, exit, or transition. State machines make behavior easier to review than deeply nested conditions and delays.

A good super-loop design frequently combines nonblocking state machines with hardware timers and interrupts. The goal is to keep response time predictable while keeping the software simple enough to verify.

Interrupts

An interrupt allows hardware to request immediate CPU attention. The processor saves enough context to suspend normal execution, runs an interrupt service routine, and then resumes the interrupted code.

An ISR should normally be short. It should acknowledge the hardware event, capture essential data, update a minimal amount of state, and defer expensive work. Long ISRs increase interrupt latency for other events and make timing harder to analyze.

Interrupt priorities determine which interrupt can preempt another on architectures that support nested interrupts. The exact priority rules are processor-specific, so firmware must be checked against the microcontroller reference manual rather than relying on intuition.

This DigiKey lesson demonstrates why hardware interrupts and deferred processing are important in RTOS-based embedded systems.

A shared variable accessed by both an ISR and normal code requires careful design. The firmware must consider atomicity, ordering, interrupt masking, and the compiler's optimization rules. Declaring the object volatile only solves one part of the problem.

Real-Time Operating Systems

A real-time operating system provides services such as task scheduling, timers, queues, semaphores, mutexes, and sometimes memory management. The word real-time refers to predictable timing relative to deadlines, not simply high speed.

A task-state diagram helps you distinguish running, ready, and blocked behavior. That distinction is central to understanding why a well-designed real-time task waits for an event instead of wasting CPU time in a polling loop.

FreeRTOS is a widely used open-source RTOS kernel for microcontrollers. It supports task priorities, queues, synchronization primitives, and software timers. An RTOS can improve modularity when several concurrent activities must be coordinated, but it adds scheduler behavior, task stacks, synchronization requirements, and failure modes such as deadlock.

This DigiKey introduction is useful for distinguishing an RTOS from a general-purpose operating system and for understanding why determinism matters.

Tasks, Synchronization, and Priority Inversion

A task can be running, ready, or blocked depending on scheduler state and event conditions. A high-priority task should normally block while waiting rather than continuously polling. Queues can transfer data between tasks, semaphores can signal events or count resources, and mutexes protect shared resources.

A mutex serializes access to a shared resource. The critical section should be as short as practical, and the design should avoid circular lock dependencies that can lead to deadlock.

A classic concurrency hazard is priority inversion. Suppose a low-priority task holds a mutex needed by a high-priority task. If a medium-priority task keeps preempting the low-priority task, the high-priority task can be delayed for an unexpectedly long time. Priority inheritance reduces this problem by temporarily raising the priority of the mutex holder.

Concurrency errors are often intermittent. They can disappear when a debugger changes timing, which is why systematic tracing and stress testing are important.

Real-Time Analysis

Deadlines, Latency, and Jitter

A deadline is the latest acceptable completion time for an operation. Latency is the delay between an event and a response. Jitter is variation in the timing of events that ideally occur at regular intervals.

A hard real-time system treats a missed deadline as a system failure. A soft real-time system can tolerate occasional lateness with reduced quality. Many practical systems contain several classes of timing requirements at once.

For a periodic task i with worst-case execution time C_i and period T_i, the utilization contribution is C_i / T_i. The sum of these contributions is a first check on CPU loading. Under ideal assumptions, earliest-deadline-first scheduling on one preemptive processor can schedule independent periodic tasks when total utilization does not exceed one. Real designs also include interrupt overhead, blocking, release jitter, communication delays, cache effects, and execution-time uncertainty.

Worst-Case Thinking

Average execution time is not sufficient for real-time engineering. You must reason about the longest credible path: maximum loop iterations, slow peripheral responses, interrupt interference, mutex blocking, memory wait states, and error handling.

Timing analysis should identify a measurable requirement such as “the control output is updated within 250 microseconds after the ADC sample becomes available.” A statement such as “the system is fast” cannot be verified.

Communication Interfaces

UART

UART is an asynchronous serial interface. Two endpoints agree on a baud rate and framing rules. Data is transmitted with start and stop information because no shared clock is carried with the data.

UART is simple and valuable for debug consoles, GPS receivers, radio modules, and point-to-point device communication. Logic-voltage UART is not the same electrical standard as RS-232 or RS-485, so interface circuitry may be required.

I2C

I²C uses a clock line and a bidirectional data line shared by multiple addressed devices. The lines are commonly open-drain or open-collector and require pull-up resistors. This wiring allows multiple participants to share the bus while avoiding direct contention from actively driven high levels.

I2C reduces pin count, but bus capacitance, pull-up values, clock rate, device addresses, clock stretching, and firmware error recovery all matter. A bus that works with short laboratory wires may fail on a poorly routed production board.

This Texas Instruments lesson explains I2C addressing, start and stop conditions, acknowledgements, and the open-drain electrical behavior of the bus.

SPI

SPI is a synchronous serial interface commonly using a clock, controller output data, peripheral output data, and one or more chip-select signals. It can provide high throughput with low protocol overhead, but additional peripherals often require additional select lines.

SPI devices must agree on clock polarity, clock phase, bit order, frame size, and chip-select behavior. A logic analyzer is often the quickest way to discover a mode mismatch because the bytes can look shifted even though all wires are connected correctly.

CAN

Controller Area Network is a robust message-oriented bus widely used in vehicles and industrial systems. CAN uses differential signaling at the physical layer and includes arbitration and error-detection mechanisms. Multiple nodes can share the network without a central host deciding every transmission.

CAN design requires correct termination, bit timing, identifiers, transceivers, and error handling. Higher-layer protocols such as CANopen and J1939 define additional conventions above the basic CAN data link.

Selecting an Interface

Interface	Typical strengths	Typical limitations	Suitable examples
UART	Simple, low protocol overhead, easy debug access	Usually point-to-point and requires matching baud settings	Console, GPS module, simple device link
I2C	Multiple addressed devices on two signal lines	Pull-ups and bus capacitance limit speed and distance	Sensors, EEPROMs, configuration devices
SPI	High throughput and full-duplex capability	More wires and chip-select management	Displays, fast ADCs, external Flash
CAN	Robust shared network with arbitration and error handling	More complex controller and transceiver requirements	Vehicles, machinery, distributed control

Interface selection is an engineering trade-off, not a popularity contest. Compare bandwidth, distance, wiring, electrical environment, number of nodes, deterministic behavior, software complexity, and fault tolerance.

Development Tools and Workflow

Development Boards and IDEs

Development boards give you access to a real processor, debug probe, pins, LEDs, and connectors before custom hardware exists.

STM32 Nucleo boards are one example. They can be used with vendor tools, open-source toolchains, and RTOS software.

This STMicroelectronics video introduces STM32CubeIDE and the process of creating a microcontroller application.

A professional workflow normally includes version control, reproducible builds, compiler warnings, static analysis, automated tests, code review, and documented tool versions. Firmware should be treated as an engineered product rather than a one-off sketch.

Debugging with JTAG, SWD, and Instrumentation

A debug interface such as JTAG or Serial Wire Debug can halt the CPU, single-step code, inspect memory, set breakpoints, and sometimes trace execution.

A software debugger cannot reveal every electrical problem. An oscilloscope shows analog voltage over time, while a logic analyzer records digital states and can decode buses such as UART, I2C, and SPI. Good diagnosis often combines source-level debugging with measurements at the pins.

Useful embedded debugging evidence includes timestamped logs, captured bus traces, measured interrupt latency, reset-cause registers, stack high-water marks, fault status registers, and reproducible test inputs.

From Requirements to Product

A disciplined lifecycle begins with measurable requirements. Architecture follows from those requirements: processor choice, memory size, interfaces, power supply, communication strategy, fault handling, and software structure. Prototypes test uncertain assumptions early. Verification then checks whether implementation behavior satisfies the requirements.

A useful sequence is requirements, architecture, prototype, implementation, integration, verification, production preparation, deployment, and maintenance. In long-lived systems, firmware update strategy and component obsolescence planning matter as much as the first release.

Power and Energy

Power is often a first-class embedded constraint. For CMOS logic, dynamic switching power is approximately proportional to capacitance multiplied by voltage squared and clock frequency. This explains why lower voltage and lower clock frequency can reduce active power, although actual energy depends on execution time and peripheral behavior.

Common techniques include sleep modes, clock gating, duty cycling, interrupt-driven wakeup, peripheral DMA, lower radio transmit duty, and turning sensors off when they are not needed. A battery-powered node should be evaluated using energy per operating cycle and sleep current, not only active current.

A power optimization must preserve timing and correctness. Slowing a clock may reduce instantaneous power but increase the time needed to finish a job. The most useful metric is often energy required to complete the required function.

Reliability, Safety, and Security

Reliability and Fault Handling

Embedded software should assume that faults can occur. Possible causes include supply disturbances, electromagnetic interference, communication errors, sensor failures, software defects, memory corruption, and unexpected user behavior.

A watchdog timer can reset a system if software stops making progress, but simply adding a watchdog is not enough. The firmware must service it only after proving that critical functions are healthy. Reset causes should be logged when possible so repeated failures can be diagnosed.

Other techniques include CRC checks, range checks, timeouts, plausibility checks, redundant sensing, safe-state outputs, brownout protection, and error counters. Fault injection can deliberately disconnect sensors, corrupt messages, or delay tasks to verify recovery behavior.

Functional Safety

Safety asks whether failures can create unacceptable risk to people, equipment, or the environment. Safety engineering is based on hazards, risk reduction, defined safe states, evidence, and process discipline. Standards such as IEC 61508 and domain-specific standards such as ISO 26262 can influence the required development process.

Safety is not the same as reliability. A system can be highly reliable yet unsafe if its rare failures have dangerous consequences. Conversely, a safe design may deliberately shut down when uncertainty becomes too high.

Security

Connected embedded systems must also consider adversarial behavior. Important protections include threat modeling, least-privilege design, secure boot, authenticated firmware updates, protected cryptographic keys, rollback protection, memory protection, debug-port control, and secure communication.

Secure boot verifies that software is authentic and acceptable before execution. It is different from encrypted storage: encryption protects confidentiality, while signatures or authenticated hashes protect authenticity and integrity.

Security and safety can interact. For example, locking debug access protects secrets but may complicate field diagnosis. A good architecture makes these trade-offs explicit rather than treating security as an afterthought.

A Worked Design Example

Consider a university design project for a battery-powered environmental monitoring node. The node samples temperature, humidity, and air pressure, stores readings, transmits summaries, detects sensor failures, and must run for months between battery charges.

A reasonable architecture might use a low-power microcontroller, I2C sensors, SPI Flash, a low-power radio, a watchdog, and a timer-driven sampling schedule. The firmware could spend most of its time in sleep mode, wake on a real-time clock event, start sensors, collect samples, validate them, store data, transmit when required, and return to sleep.

The design questions are cross-disciplinary. You must calculate the energy budget, verify sensor startup times, handle an I2C device that fails to acknowledge, prevent data corruption during brownout, choose buffer sizes, protect firmware updates, and decide whether a super loop or RTOS is justified.

A second design, such as an electric motor controller, has different priorities. It may require much tighter deadlines, synchronized ADC sampling, high-rate PWM, fast fault shutdown, and CAN communication. The best architecture depends on requirements, not on a preferred board or programming framework.

Engineering Decision Framework

When comparing embedded architectures, evaluate at least these dimensions: correctness, timing, memory, energy, electrical compatibility, interfaces, fault behavior, security, testability, maintainability, cost, and supply risk.

A useful design review asks: What can fail? How do we detect it? What happens next? How do we prove timing? How do we update safely? Which assumptions were measured rather than guessed? Which behavior is guaranteed by hardware, which by software, and which by an external component?

Embedded systems engineering becomes much more reliable when every important claim is connected to evidence: a data-sheet limit, a timing trace, a power measurement, a test result, a code review, or a requirement.

Interactive Tasks

Quiz: Test Your Knowledge

What most clearly distinguishes an embedded system from a general-purpose computer? (It is designed around defined application functions and constraints) (!It always uses an eight-bit processor) (!It never contains an operating system) (!It must be disconnected from networks)

What does memory-mapped I/O mean in a microcontroller? (Peripheral registers are accessed through addresses in the processor address space) (!All program instructions are stored in external RAM) (!Every input pin is automatically stored on a memory card) (!The CPU can access memory only through DMA)

What is the key meaning of real-time behavior in an RTOS? (Required actions can meet defined timing deadlines predictably) (!Every task executes at the maximum clock frequency) (!All tasks finish in the same amount of time) (!The system has no interrupts)

Why should an interrupt service routine normally be short? (It reduces latency and interference with other time-critical work) (!It makes the microcontroller use more Flash memory) (!It prevents all peripherals from generating interrupts) (!It removes the need for synchronization)

Which feature is characteristic of I2C? (It uses a shared clock and data pair with addressed devices) (!It requires a separate chip-select line for every device) (!It sends data without any clock or agreed timing) (!It is designed only for long-distance radio links)

What can happen if two SPI devices use different clock phase settings? (Data can be sampled on the wrong clock edge) (!The bus automatically changes into I2C mode) (!The processor permanently loses its program memory) (!The watchdog timer becomes a communication clock)

What is a common benefit of DMA? (It moves data between memory and peripherals with limited CPU intervention) (!It guarantees that every task meets its deadline) (!It replaces the need for non-volatile memory) (!It converts analog signals directly into radio packets)

What is the purpose of a watchdog timer? (It detects lack of software progress and can trigger recovery) (!It measures the resistance of a digital input) (!It increases the resolution of an ADC) (!It selects the baud rate of a UART)

What describes priority inversion? (A lower-priority task holds a resource needed by a higher-priority task) (!A higher-priority task always runs before an interrupt) (!Two processors execute the same instruction at once) (!A timer counts downward instead of upward)

What is the main purpose of secure boot? (It verifies acceptable software before the system executes it) (!It increases CPU clock frequency during startup) (!It converts encrypted data into an analog signal) (!It disables all firmware updates permanently)

Memory Game

Watchdog	Timer that detects missing software progress and can initiate recovery
DMA	Hardware engine that moves data between peripherals and memory
ISR	Routine executed in response to an interrupt event
Jitter	Variation of an event time around its expected timing
Bootloader	Startup software that can load verify or update an application
Mutex	Synchronization object used to protect a shared resource

Drag and Drop

Match the correct terms.	Topic
Priority inheritance	Temporarily raises the priority of a mutex holder
Input capture	Stores a timer value when a selected signal edge arrives
Serial Wire Debug	Two-wire debug interface commonly used with Arm microcontrollers
CRC	Detects many forms of accidental data corruption
Brownout reset	Forces a restart when supply voltage becomes unsafe

...

Crossword Puzzle

Firmware	What name is given to software stored for execution inside an embedded device?
Watchdog	Which timer can trigger recovery when software stops making progress?
Semaphore	Which synchronization object can signal an event or count available resources?
Latency	What word describes the delay between an event and the response to it?
Bootloader	Which startup program can verify or update an application image?
Determinism	What property means timing behavior is predictable enough to reason about deadlines?

LearningApps

Cloze Text

An embedded controller often combines a processor core with memory and peripherals in a

. Hardware events can request CPU attention through an

. A real-time design must reason about deadlines as well as average

. Peripherals may transfer blocks of data through

. I2C uses a clock line and a shared

line. SPI timing depends on clock polarity and clock

. An RTOS uses a

to decide which ready task executes. A watchdog helps recover when firmware stops making

. Secure boot checks software before

. Good validation connects requirements to measurable

.

Open-Ended Tasks

Easy

Pinout Audit: Choose a development board and annotate which pins provide GPIO, ADC, UART, I2C, SPI, power, reset, and debugging; explain which pins you would reserve for a simple sensor node.
Timing Diary: Observe a small embedded program and record every delay, timer, periodic action, and external event; identify which timing values are requirements and which are implementation choices.
Protocol Comparison: Create a one-page engineering comparison of UART, I2C, SPI, and CAN for connecting three different peripherals in a hypothetical product.
State Machine Sketch: Draw a state machine for a device with startup, idle, active, fault, and shutdown behavior, then explain every event that causes a transition.

Standard

Interrupt Lab: Configure a timer or GPIO interrupt, measure the response latency with an oscilloscope or logic analyzer, and explain the sources of variation you observe.
Sensor Driver: Implement a small driver for an I2C or SPI sensor, including initialization, data acquisition, timeout handling, and one deliberately injected error condition.
Power Profiling: Measure active and sleep current for a microcontroller application, estimate battery life from a duty cycle, and compare the estimate with a direct energy measurement.
Fault Injection: Disconnect or corrupt one peripheral while the system is running, document the observed failure mode, and redesign the firmware so the device reaches a defined safe or degraded state.

Advanced

RTOS Scheduler Study: Implement at least three periodic tasks with different priorities, measure scheduling behavior under load, and analyze whether the observed response times satisfy explicit deadlines.
Secure Boot Proposal: Design a secure firmware-update architecture that includes authenticity checks, rollback protection, key storage, recovery behavior, and a threat model.
Hardware-in-the-Loop Test: Build a test setup that stimulates sensor inputs and records outputs automatically, then use it to verify normal behavior, timing limits, and at least two fault cases.
Capstone Prototype: Build a working embedded prototype that integrates sensing, actuation or communication, documents quantitative constraints, and demonstrates verification evidence in a short technical video.

Learning Assessment

Architecture Justification: Given requirements for timing, energy, cost, and communication, propose an embedded architecture and defend the processor, memory, peripheral, and software choices with explicit trade-offs.
Timing Analysis: Analyze a set of periodic and event-driven tasks, identify possible blocking and interference, and decide whether the proposed schedule can satisfy its deadlines.
Concurrency Review: Inspect a firmware design that shares data between tasks and interrupts, identify race conditions or priority inversion risks, and propose a synchronization strategy.
Interface Diagnosis: Interpret captured UART, I2C, or SPI signals, identify the most plausible communication fault, and explain which measurement would confirm the diagnosis.
Fault Response Design: Design the behavior of a controller after sensor failure, brownout, corrupted storage, and watchdog reset, distinguishing detection, containment, recovery, and evidence logging.
Security Transfer: Apply secure-boot and update principles to a connected embedded product in a new domain and explain how safety, serviceability, and security requirements interact.

Evidence of Learning

Strong evidence of learning combines knowledge, skills, products, and transfer. Knowledge evidence includes accurate explanations of microcontroller architecture, peripherals, scheduling, communication, timing, power, reliability, safety, and security. Skill evidence includes reading data sheets, configuring peripherals, writing nonblocking firmware, using interrupts and RTOS services correctly, capturing electrical signals, debugging faults, and interpreting timing measurements.

Useful products include a reviewed schematic fragment, firmware repository, state-machine diagram, timing budget, power budget, protocol trace, test plan, fault-injection record, and working prototype. Transfer is demonstrated when you can apply the same reasoning to an unfamiliar board, processor family, communication interface, or application domain and still justify your design from measurable requirements.

The strongest portfolio evidence makes the relationship between requirement, implementation, measurement, and conclusion visible. A video of a blinking LED proves that something runs; a trace showing bounded interrupt latency, an automated fault test, or a documented energy budget proves much more.