Embedded & cyber-physical systems

Observe the world. Act before the deadline.

Co-design electronics, firmware, real-time behavior, sensing, control, power, communications, safety, and verification around the physics of a product.

Trace the control loop Practice an interview → Choose another track

7thinking steps
6verification levels
1worked interview

control.loop

# Correct value, correct time, safe outcome
sample   = sensor.read(timestamped)
state    = estimate(sample, uncertainty)
command  = controller(state, deadline)
actuator.write(command)

if health.invalid() or deadline.missed():
    enter(defined safe state)

verify(model → software → processor → plant)

01 · Cyber-physical thinking flow

Trace information and energy around the loop

Correct computation delivered too late can be incorrect system behavior. Design timing, uncertainty, and failure into the main path.

01Define mission + environment
Users, operating modes, physical range, hazards, lifetime, maintenance, and misuse.
Output: scenarios + boundaries
02Set timing + quality
Sample rate, deadline, jitter, accuracy, response, availability, and safe state.
Output: measurable requirements
03Model the plant
Dynamics, disturbances, sensor/actuator limits, latency, uncertainty, and observability.
Output: control assumptions
04Partition functions
Allocate sensing, control, acceleration, communications, safety, and UI to hardware or software.
Output: HW/SW boundary
05Schedule + communicate
Tasks, interrupts, DMA, buffers, buses, priorities, clocks, and synchronization.
Output: timing architecture
06Design modes + faults
Startup, active, sleep, update, degraded, emergency, recovery, and shutdown.
Output: state machines
07Verify across levels
Models, code, processor timing, electrical interfaces, plant behavior, corners, and field evidence.
Output: traced proof

Memory hookMission → deadline → plant → partition → schedule → modes/faults → evidence.

Setpointdesired state + limits

Estimator + controllerfilter, fuse, decide, bound output

Actuator + plantphysical response + disturbances

Sensorsample, condition, convert, timestamp

↖ Feedback closes the loopsensor value + timestamp + health + uncertainty return to the estimator

SamplingFast enough, not merely frequent

Choose rate and anti-alias filtering from plant dynamics; define clock accuracy and timestamp location.

Delay + jitterBound end-to-end age

Sensor integration, bus transfer, scheduling, compute, output update, and actuator response all consume the deadline.

Range + uncertaintyRepresent what is not known

Resolution, noise, bias, drift, calibration, saturation, missing data, and cross-sensor disagreement.

Stability + safetyControl the corners

Analyze worst delays, gain changes, actuator limits, recovery transitions, and what happens when confidence is low.

02 · Hardware / software partition

Allocate by deadline, data rate, change, and assurance

Hardware is not automatically faster and software is not automatically flexible once interfaces, copies, validation, and updates are counted.

Start with one functionWhat makes this function difficult?Profile the complete path, including conversion and movement.

Hard deadline?Bounded response dominates

Use timers, capture/compare, DMA, FPGA/fixed logic, dedicated cores, or a verified high-priority software path.

Prove worst-case timing

High regular data rate?Work is repeated and parallel

Use DSP, SIMD, GPU/NPU, FPGA pipelines, or fixed function when transfer and launch overhead still fit.

Count bytes between engines

Likely to change?Policy or algorithm evolves

Prefer software, tables, microcode, or programmable acceleration with a stable hardware abstraction.

Preserve update and rollback

Independent safety boundary?Failure must be contained

Separate power, clock, reset, memory protection, supervisor, or simple monitor when common-cause failure matters.

Independence must be real

Hardware usually ownsPrecise edges + bulk movement

Clocking, ADC/PWM, safety cutoff, packet framing, DMA, encryption primitives, and stable high-rate transforms.

Software usually ownsPolicy + evolution

State machines, orchestration, calibration logic, diagnostics, product behavior, networking policy, UI, and update.

Contract between themMake timing and failure explicit

Registers, queues, ownership, units, ranges, timestamps, interrupts, errors, reset, versioning, and observability.

03 · Real-time scheduling selector

Choose a policy you can analyze

Real time means meeting deadlines predictably. High average CPU performance does not guarantee that.

Simple + static periodsCyclic executive

A repeating table is easy to inspect and deterministic when activities are few, known, and fit cleanly.

Watch: poor flexibility + long task blocking

Periodic / sporadic critical tasksFixed-priority preemptive

Assign priorities from criticality and analyzed relative deadlines. The classic rate-monotonic optimality and utilization guarantees apply only under their independent, periodic, preemptive, deadline-equals-period assumptions; period-based priorities can still be used outside that model when an applicable response-time analysis proves schedulability. Include blocking, ISR interference, release jitter, and overload.

Watch: priority inversion + starvation

Dynamic deadlinesEarliest Deadline First

Schedule the ready job with the nearest deadline when the platform and certification approach support dynamic priority.

Watch: overload behavior + implementation cost

Soft background workBest effort below the critical lane

Run logging, uploads, UI, and maintenance at bounded lower priority or under a server/budget.

Watch: background backpressure + memory growth

For each critical taskresponse=execution + blocking + interference(response)≤deadline

Practical anchor: FreeRTOS documents fixed-priority preemptive scheduling as its default policy, with time slicing among equal priorities. A policy name is only the start; the application still needs measured execution times and schedulability analysis.

04 · Interrupts, DMA, and ownership

Capture quickly. Move efficiently. Process outside the ISR.

The interrupt path protects timing; the task path owns complex work. In a pre-armed streaming path, the peripheral request—not an initial ISR—drives DMA. Avoiding a copy still requires compatible shared buffers, explicit ownership, mappings, synchronization, and any required cache maintenance.

Own + preparereserve buffer · map/sync · set descriptor
Arm pathconfigure DMA + peripheral before data arrives
Peripheral requesthardware moves data without per-item CPU work
Completion / error IRQDMA reports terminal count or fault
ISR publishesack · timestamp · status · wake task
Task + recyclesync · validate · process · unmap/return/rearm

CPU-driven path

Good for tiny, infrequent register transfers. Cost grows with interrupt rate, copies, and per-item overhead.

DMA-driven path

Good for blocks and streams. Needs descriptors, alignment, direction, ownership, cache maintenance, error handling, and completion.

Bound

Keep ISR work short and non-blocking. Define a maximum arrival rate and nesting policy.

Defer

Signal a task with a queue, notification, or event; do parsing, allocation, and logging later.

Own

Use explicit buffer states such as free, DMA-owned, ready, processing, and returning.

Recover

Handle overrun, missed completion, bus error, corrupt descriptor, timeout, and peripheral reset.

05 · State and power modes

Transitions are first-class behavior

Most bugs and energy surprises live between steady states: boot, wake, update, brownout, reset, degraded operation, and recovery.

OFF / SHIPPINGEnergy isolatedwake: charger, button, install event
BOOTTrust + initializeverify image, rails, clocks, memory, self-test
ACTIVEMission workfull sensing, compute, communication, actuation
IDLE / SLEEPRetain useful contextgate clocks, park buses, arm wake sources
DEEP SLEEPMinimum leakagelose most context; longer wake and restore

Entry guard

No transfer in flight; output safe; queues persisted or discarded intentionally.

Wake source

Timer, GPIO, comparator, radio, sensor, watchdog, charger—qualified against false wakes.

Example restore order

One common dependency chain is rails → clocks → retained memory → buses → devices → tasks → external outputs. Derive the actual sequence from the selected silicon and system hazards.

Fault escape

Every state has timeout, reset, rollback, or safe-state behavior if entry/exit fails.

Daily load energyΣ(load-side state power × residency)+Σ(load-side transition energy × transition count)

Keep one energy boundary: if powers are measured load-side, convert each state and transition with efficiency at its actual battery voltage, load, and converter mode, and include converter quiescent loss exactly once. A single η is acceptable only when it is a declared load-profile-weighted effective value. Alternatively, integrate energy at the battery terminal directly. Derate usable battery capacity separately for temperature, aging, self-discharge, depth-of-discharge limits, cell variation, and a named product reserve.

06 · Protocol selector

Choose the link from the physical context

Nominal bitrate alone ignores distance, wiring, topology, determinism, noise, power, software ecosystem, and failure handling.

Common starting points. Final electrical limits and timing come from the selected controller, transceiver, board, cable, and current specification.
Protocol	Best fit	Strength	Watch closely
I²C	Short board-level control and low-rate sensors.	Few wires, static addressing, broad device ecosystem.	Passive pull-ups, capacitance, clock stretching, stuck bus, and static-address conflicts.
I3C	Board-level sensors needing higher rates, a low-pin-count bus, and richer bus management.	Dynamic address assignment, in-band interrupts, and push-pull phases; selected legacy I²C targets may coexist when they satisfy the specified electrical/protocol restrictions.	Controller/target feature levels, legacy-target compatibility, mixed open-drain/push-pull timing, hot-join roles, and error recovery.
SPI	Short board-level sensors, converters, displays, and flash.	Simple, full-duplex, low protocol overhead, higher rates.	Chip-select count, no universal framing/error recovery, signal integrity.
UART	Point-to-point debug, modules, bootloaders, simple links.	Minimal hardware and easy observability.	Clock mismatch, framing, flow control, no native multi-drop contract.
CAN / CAN FD	Robust multi-node control networks in noisy environments.	Nondestructive arbitration, error detection, fault confinement, and identifier-based priority; lower numeric identifiers win arbitration.	Worst-case bus load, identifier design, bit timing, termination, error states, and latency under contention.
Ethernet	High-rate, longer-reach, routable or switched systems.	Large ecosystem, diagnostics, scale, power/data options.	Stack complexity, queues, switch delay, synchronization, security.
USB	Host-controlled peripherals, cameras, storage, service ports.	Standard classes, power, high bandwidth, broad hosts.	Host/device roles, enumeration, cabling, suspend, certification.
Bluetooth LE	Low-power personal-area links and phone-connected products.	Phone ecosystem, profiles, discovery, low-duty-cycle operation.	Connection interval, radio coexistence, pairing, privacy, variable latency.

Payloadbytes + rate

Deadlinelatency + jitter

Topologypoint · bus · switched

Physicalreach · noise · wires

Energyactive + idle + wake

Failuredetect · retry · isolate

07 · Safety, watchdogs, and recovery

Detect, contain, and reach a defined outcome

A watchdog is not a safety argument by itself. State what it observes, which failures it can detect, what remains independent, and what reset or safe action accomplishes.

InputSense + validaterange · plausibility · redundancy · freshness

DecisionControl + boundsstate validity · command limits · deadline

OutputDrive + observecommand versus feedback · open/short · saturation

OutcomeNormal or safe statestop · hold · isolate · degrade · alert

Supervisor lane with justified independenceWindowed watchdog, clock/power monitors, memory protection, heartbeat, external cutoff, and fault latch can force the defined outcome only when power, clock, software, sensing, and actuation common-cause dependencies are analyzed and verified.

Sensor stuckDetect

Freshness, rate-of-change, cross-sensor comparison, stimulus/self-test.

Task hangsContain

Deadline monitor, watchdog window, task/partition restart, bounded queue.

Output wrongObserve

Independent feedback, command envelope, actuator current/position sensing.

Recovery failsEscalate

Retry budget, subsystem reset, full reset, hardware cutoff, latched service state.

FMEA memory hook: failure mode → local effect → system effect → detection → control → residual risk → verification evidence.

08 · Verification-in-the-loop ladder

Add realism without losing observability

Move from fast models to the real plant in stages. Keep requirement IDs, acceptance limits, seeds, inputs, traces, and versions so failures are reproducible.

MILModel-in-the-loop
Controller and plant are models.
Catches: algorithm, stability, scenario logic
SILSoftware-in-the-loop
Production-like code against a simulated plant.
Catches: numeric, generated code, state logic
PILProcessor-in-the-loop
Code executes on target processor or representative core.
Catches: precision, timing, compiler, memory
HILHardware-in-the-loop
Target electronics interact with real-time plant and I/O simulation.
Catches: modeled buses, clocks, timing, and injected electrical faults
SystemPhysical integration
Real sensors, actuators, mechanics, environment, and users.
Catches: interfaces + emergent behavior
FieldOperational evidence
Controlled rollout, telemetry, service diagnostics, and feedback.
Catches: diversity, aging, misuse, rare combinations

Nominal

Typical mission sequence at expected loads and environments.

Boundary

Min/max voltage, temperature, rate, timing, range, storage, and network.

Fault

Open/short, corrupt data, stale sample, bus timeout, clock drift, brownout, reset.

Transition

Boot, wake, sleep, update, rollback, degraded entry/exit, and repeated recovery.

Verification asksDid we build it to the requirements?→Validation asksDoes it solve the real operational need?

09 · Timing and reliability workbench

Prove value, time, ownership, and recovery

Averages are useful for sizing, but real-time correctness depends on worst credible interference, blocking, transitions, and fault behavior. Keep the task model and hardware assumptions beside every schedulability claim.

Worked example · single-core control lane

Build the task model before choosing priorities

Illustrative conservative execution-time bounds under declared measurement corners: sensor capture 80 μs every 1 ms, estimator 350 μs every 5 ms, control update 250 μs every 5 ms, and communications service 800 μs every 20 ms. Treat observed maxima as provisional—not automatic WCET—until analysis and corner evidence justify each bound.

Compute a screening loadUtilizations are 0.08 + 0.07 + 0.05 + 0.04 = 0.24. That is encouraging capacity evidence, but not a schedulability proof.
Add missing interferenceMeasure ISR execution and arrival bursts; include critical sections, DMA completion work, cache or flash stalls, release jitter, context switches, bus arbitration, and non-preemptive regions.
Analyze each deadlineAssign priorities from the chosen policy, iterate fixed-priority response time under its assumptions, and check every task—not only total utilization—against its relative deadline.
Size ownership queuesBound the backlog accumulated while a consumer is unavailable; define free, DMA-owned, ready, processing, and returning states so timeout/reset cannot create aliasing or reuse a live buffer.
Measure on the targetTrace release-to-completion latency and jitter at voltage, temperature, clock, memory, and bus corners. Inject overrun and missed-completion faults; confirm the stated degraded or safe behavior.

Analysis anchors

Use the formula that matches the model

Periodic utilization screenU = Σ(Cᵢ ÷ Tᵢ)Useful for first-pass capacity. It does not by itself include deadlines, priorities, blocking, jitter, ISR work, or multiprocessor effects.

Jitter-aware fixed-priority responsewᵢ⁽ᵏ⁺¹⁾ = Cᵢ + Bᵢ + Σⱼ∈hp(i) ceil((wᵢ⁽ᵏ⁾ + Jⱼ) ÷ Tⱼ) CⱼA common single-core fixed-priority model in which higher-priority release jitter enters interference. Add the task’s own jitter only when the measured boundary begins at arrival rather than release, and extend the model to match shared resources, scheduler policy, sporadic interference, and implementation overhead.

Buffer backlog estimatearrivals during worst consumer gap + burst/retry marginValidate with arrival and service traces. A large buffer delays overflow; it does not repair an unstable average producer/consumer rate.

Battery-terminal energyE_battery ≈ Σ(E_load,s ÷ η_s(V_bat, I_s, mode)) + E_quiescent,not-yet-countedUse state- and transition-specific converter behavior; add quiescent loss only if the efficiency/input-power measurement does not already include it. Or integrate at the battery terminal. Then derate usable capacity separately for temperature, aging, self-discharge, depth of discharge, cell variation, and product reserve.

A response-time claim is only as good as its task model. Record the assumptions beside the result so a later software or hardware change can invalidate it visibly.
Model field	What to record	Common miss	Evidence
Release	Periodic/sporadic source, minimum inter-arrival time, burst limit, phase, release jitter, and mode.	Using average sensor or network rate when arrivals can burst.	Timestamped arrival traces plus a justified bound for unobserved corners.
Execution	WCET or conservative bound by path, cache/flash state, voltage/frequency, compiler, inputs, and instrumentation overhead.	Treating a benchmark mean or isolated hot-cache run as WCET.	Static analysis where applicable, target measurements at corners, and code/configuration identity.
Interference	Higher-priority tasks, ISRs, non-preemptive sections, DMA completion work, bus/memory contention, and multicore effects.	Counting only RTOS tasks while drivers and shared hardware steal service.	Response-time analysis matched to the scheduler and measured contention tests.
Blocking	Mutex/resource protocol, maximum critical section, priority inversion control, and lower-priority non-preemptive work.	Assuming high priority means “never waits.”	Lock/critical-section traces, ceiling/inheritance configuration, and worst-holder injection.
Acceptance	Relative deadline, end-to-end chain deadline, allowed misses, safe/degraded response, and measurement points.	Proving each task separately while the sensor-to-actuator chain still misses.	Target trace from physical event through actuation and recovery at operating corners.

Transitions deserve the same rigor as steady states. Define entry guard, authority, timeout, cleanup, output validity, and proof for every edge.
Transition fault	Required behavior	What can remain ambiguous	Test
DMA timeout during capture	Stop or drain the peripheral, invalidate the buffer, revoke ownership, clear status in the documented order, and rearm or reset the smallest safe scope.	A late write or completion can corrupt a buffer already recycled to another task.	Delay/drop completion and inject bus faults at every descriptor boundary.
Brownout during flash write	Hold outputs safe, protect boot metadata, detect incomplete records, and recover the last committed state.	Torn data may look structurally valid without CRC/version/commit markers.	Sweep power removal across each program/erase and metadata update phase.
Wake dependency fails	Bound each rail/clock/device wait, clean up partially enabled domains, log the failing dependency, and enter a defined low-power or service state.	One powered device may back-power another or leave the bus stuck.	Stuck-ready, missing clock, false wake, repeated wake, and power-sequence injection.
Watchdog reset loop	Persist bounded reset history, prevent unsafe output replay, escalate after the retry budget, and expose a diagnosable latched state.	A reset can repeatedly recreate the hazardous condition before monitoring is ready.	Hang each supervised layer, corrupt progress signals, and fail the recovery itself.
Update interrupted or incompatible	Authenticate, enforce version policy, select a bootable compatible image, confirm health before commitment, and retain recovery access.	Firmware, configuration, calibration, secure storage, and rollback counters can disagree.	Power-cut matrix across download/install/boot/confirm plus forward/backward compatibility tests.

Sampling

Protect the signal contract

State bandwidth, sample rate, aperture/jitter, synchronization, anti-alias filtering, quantization, calibration, stale-data timeout, timestamp source, and what the controller does when confidence is lost.

Concurrency

Make ownership explicit

Use bounded queues and immutable descriptors; define who may read, write, cancel, recycle, or reset a buffer. Pair data publication with the memory ordering required by the CPU and device.

Recovery

Layer watchdogs deliberately

Monitor progress, not merely task liveness. Use an independent clock or external supervisor when the hazard requires it; log reset cause and prevent reset loops from repeatedly driving unsafe outputs.

Evidence

Test timing faults in context

Combine MIL/SIL/PIL/HIL with bus delay, clock drift, corrupt samples, brownout, partial update, stuck actuator, thermal throttling, and repeated recovery. Preserve seeds, traces, versions, and acceptance limits.

Primary trailLiu–Layland scheduling ↗Joseph–Pandya response time ↗Jitter-aware response time ↗Zephyr scheduling ↗Zephyr power management ↗FreeRTOS scheduling ↗Linux DMA ownership ↗TI pulsed-load battery budgeting ↗MIPI I3C integration ↗MCUboot image + recovery design ↗Linux watchdog contract ↗

10 · Embedded interview practice

Design a battery smart camera

Commit to requirements, an energy budget, task timing, states, and failure behavior before revealing the coaching notes.

45-minute prompt

Design a six-month battery smart camera

A weather-resistant camera wakes on motion, classifies locally, stores an encrypted clip, and uploads confirmed events. It must remain useful when Wi-Fi is unavailable.

8 Wh battery
180 days
20 wakes/day
2 confirmed/day
wake < 500 ms
−10–50 °C
secure update

PIR / wake sensoralways-on µW lane
Power managersequence rails + clocks
Image sensorcapture + timestamp
ISP + NPUscreen motion locally
MCU policyclassify event + mode
Flashencrypted ring buffer
Wi-Fi / BLEupload + setup + health

00–07 minClarify mission and privacy
Ask about detection classes, missed/false event cost, clip length, image quality, night operation, connectivity, local retention, response, tamper, and user controls.
Reveal coaching notes
Define “six months” with event and temperature assumptions. Separate wake detection from confirmed event recording. Ask what images may leave the device and what the product does when storage, battery, or connectivity is constrained.
07–15 minCreate the energy budget
Convert 8 Wh over 180 days into a daily and average-power envelope. Budget load-side sleep, wakes, confirmed captures, and uploads; translate each state and transition to the battery boundary with its applicable converter behavior, then derate usable capacity for temperature and aging.
Reveal coaching notes
The nameplate envelope is about 44.4 mWh/day, or 1.85 mW average before conversion and capacity derating. Keep the always-on lane far below that. Use efficiency and quiescent current at each state’s battery voltage, load, and converter mode—or integrate battery-terminal energy directly—because a radio burst and a microamp sleep state do not share one nominal efficiency. Budget energy per wake and per upload, not just active watts; reduce false wakes because their count multiplies every active cost.
15–25 minPartition hardware and tasks
Choose wake sensing, MCU/RTOS, image/ISP path, accelerator, memory, storage, radios, security element, and power domains.
Reveal coaching notes
Keep a tiny always-on controller or wake sensor. Power the main image/AI/radio islands only when needed. Use DMA for frames, fixed function for ISP, an accelerator for supported inference, and software for policy and recovery. Avoid waking Wi-Fi for rejected events.
25–33 minSchedule the event path
Trace wake interrupt, rail/clock sequencing, sensor readiness, capture DMA, inference deadline, storage, radio association, upload, and return to sleep.
Reveal coaching notes
Assign deadlines to stages and reserve buffers before enabling capture. Keep ISR work to acknowledge/timestamp/defer. Bound every wait with a timeout and make cancellation safe if battery, thermal, or privacy policy changes mid-event.
33–40 minDesign modes and failures
Cover shipping, setup, armed, capture, upload, offline, low battery, update, degraded, over-temperature, tamper, and recovery.
Reveal coaching notes
Store clips locally with a retention and wear policy when offline; upload later under an energy/data budget. Use signed A/B images with anti-rollback policy, old/new schema and bootloader compatibility, post-boot confirmation, bounded retry, a recovery image/path, unique device identity, encrypted storage, protected keys, and explicit factory reset.
40–45 minVerify and close
Name tests for energy, timing, accuracy, transitions, radio loss, corrupt storage, brownout, temperature, update interruption, and privacy behavior.
Reveal coaching notes
Automate event-cycle energy integration across temperature and battery state. Replay labeled scenes for detection quality, inject failures during every transition, HIL-test the power and sensor interfaces, then run accelerated long-duration and controlled field trials.

200 wakes/day

Protect the battery with sensor tuning, cooldown, local low-cost screening, rate budgets, and abuse detection.

Wi-Fi offline for 7 days

Size encrypted storage, choose eviction priority, batch retry with backoff, and preserve battery.

Update loses power

Boot verified previous image, leave recoverable metadata, and never brick the secure update path.

Sensor gives stale frames

Use frame counters/timestamps, freshness deadline, pipeline reset, user-visible health, and degraded state.

Strong closeShow the event timeline, daily energy equation, state machine, safe/degraded behavior, and the staged test evidence that makes the design credible.

11 · Primary references

Ground the design in implementation contracts

Read the exact silicon, RTOS, protocol, and safety requirements for the product. These references provide durable starting points.

SchedulingFreeRTOS task scheduling

Official description of fixed-priority preemption, equal-priority time slicing, AMP, and SMP policies.

FreeRTOS documentation ↗

InterruptsLinux generic IRQ handling

Reference implementation documentation for interrupt descriptors, flow handlers, affinity, and threaded interrupts.

Kernel documentation ↗

DMALinux DMA Mapping Guide

Addresses, IOMMU mapping, coherent and streaming buffers, directions, lifecycle, and failure checks.

Kernel documentation ↗

MCU interfacesArm CMSIS 6

Common processor, driver, RTOS, DSP, and neural-network software interfaces for Cortex-based systems.

CMSIS documentation ↗

Product realizationNASA Systems Engineering Handbook

Verification methods, validation, integration, transition, evidence, and requirement closure in complete systems.

NASA product realization ↗

Power managementZephyr power management

System and device power states, policies, residency, wake latency, and runtime device power concepts.

Zephyr documentation ↗

Foundational schedulingLiu and Layland

The classic single-processor periodic-task model, rate-monotonic priority assignment, utilization bound, and earliest-deadline-first result—with assumptions that must be stated.

Read via ACM DOI ↗

RTOS behaviorZephyr Scheduling

Official details for cooperative and preemptive threads, static priorities, time slicing, scheduler locks, deadlines, and power-management interaction.

Zephyr documentation ↗

Sensor busMIPI I3C System Integrator Guide

Dynamic address assignment, in-band interrupts, mixed I²C/I3C operation, arbitration, roles, and integration responsibilities.

MIPI application note ↗

RecoveryLinux Watchdog API

A concrete reference for timeouts, pretimeouts, boot status, nowayout behavior, and the limits of assuming every watchdog implementation behaves identically.

Kernel documentation ↗

BackendDistributed softwareAPIs, data, caching, queues, reliability. Systems engineeringWhole lifecycleNeeds, requirements, interfaces, risk, V&V. HardwareComputer systemsCompute, memory, fabric, PPA, thermal, reliability. NPU + ACiMHardware/software co-designCompiler, mapper, runtime, calibration. AtlasChoose by system boundaryReturn to the visual track selector. DSA AtlasAlgorithms and data structuresReturn to the original visual learning map.