Embedded Software & Tools glossary

Embedded software and tools terms cover the code that runs on and around a chip: boot loaders, firmware, drivers, real-time operating systems, debuggers, compilers and the update and security mechanisms that keep devices current in the field.

Firmware engineers, system integrators and security teams use them to bring up new silicon, describe how software controls the hardware, and plan updates and software bills of materials across a product's life.

237 terms in 19 groups, 65 with a full explanation and examples. Each term has its own page.

AI enablement

BLAS: Basic Linear Algebra Subprograms: The long-standing API specification for vector, matrix-vector and matrix-matrix operations, organised into three levels.
CUDA: Compute Unified Device ArchitectureIn depth: NVIDIA's parallel computing platform and programming model, comprising a C++ language extension, compiler, driver and a deep library ecosystem for running general-purpose workloads on its GPUs.
Graph compilerIn depth: A compiler that takes a trained neural network as a dataflow graph and lowers it to code for a target accelerator, applying operator fusion, layout selection, memory planning and scheduling rather...
Kernel libraryIn depth: A collection of hand-optimised compute routines for a specific processor or accelerator, covering convolutions, matrix multiplies, activations and reductions.
Model zooIn depth: A curated repository of pre-trained and pre-optimised neural network models published by a silicon or framework vendor, often with accuracy figures and, in vendor zoos, performance figures measured...
oneAPI: An open, cross-vendor programming model led by Intel that combines SYCL-based DPC++ with a set of performance libraries for maths, deep learning, threading and video, targeting CPUs, GPUs, FPGAs an...
ONNX: Open Neural Network ExchangeIn depth: An open format for representing trained machine learning models, defining a graph structure, a versioned operator set and tensor type system so that a model trained in one framework can be run by a...
OpenCL: Open Computing Language: A Khronos standard for writing portable parallel programs across CPUs, GPUs, DSPs and FPGAs, defining a C-based kernel language plus host APIs for device discovery, memory objects and command queues.
Quantisation toolkit: The tooling a vendor ships to convert a floating-point trained model to lower-precision integer or narrow float formats, covering calibration data handling, per-channel scaling, accuracy comparison...
ROCmIn depth: AMD's open-source GPU compute software stack, providing drivers, the HIP programming model, compilers and maths and communication libraries for running machine learning and HPC workloads on Instinc...
Runtime delegate: A plug-in mechanism by which an inference runtime hands part of a model's graph to a hardware-specific back end such as an NPU, GPU or DSP, while executing unsupported operators itself on the CPU.
SYCL: A Khronos standard for single-source heterogeneous programming in modern C++, where host and device code live in the same file and a compiler splits them.
TensorFlow LiteIn depth: Google's inference runtime and flat-buffer model format for mobile and embedded targets, renamed LiteRT in September 2024, supporting quantised integer models and hardware delegates.
TensorRTIn depth: NVIDIA's inference optimiser and runtime, which takes a trained model and produces a hardware-specific engine using layer fusion, precision calibration to FP8 or INT8, kernel auto-tuning and memory...
TVM: Sometimes expanded as Tensor Virtual Machine, though the Apache TVM project does not expand the name itselfIn depth: An open-source deep learning compiler stack that imports models from common frameworks, optimises them through a tensor-level intermediate representation and generates code for CPUs, GPUs and custo...

Automotive software

A2L: ASAM MCD-2 MC description file: The description file that tells a calibration tool where each measurement and characteristic lives in ECU memory, its data type, conversion formula and limits.
ara::com: AUTOSAR Runtime for Adaptive communication: The AUTOSAR Adaptive Platform's C++ communication API, offering service-oriented proxies and skeletons for publishing and consuming services.
ARXML: AUTOSAR XML: The XML exchange format carrying AUTOSAR system, component, interface and configuration descriptions between OEM and supplier tools.
AUTOSAR Adaptive Platform: The AUTOSAR stack for high-performance automotive computers, based on POSIX operating systems, C++ APIs, dynamic service discovery and applications that can be deployed and updated after production.
AUTOSAR Classic Platform: The statically configured AUTOSAR stack for deeply embedded microcontroller ECUs, built from a layered basic software set, an OSEK-derived real-time OS and a generated runtime environment.
BSW: Basic SoftwareIn depth: The layered AUTOSAR Classic stack beneath the runtime environment, comprising services, ECU abstraction, communication, memory and the microcontroller abstraction layer.
CANoeIn depth: Vector's development and test environment for automotive networks, able to simulate missing ECUs, stimulate buses, run test sequences in CAPL and analyse traffic across CAN, LIN, FlexRay and Ethernet.
CCP: CAN Calibration Protocol: The older ASAM calibration and measurement protocol carried only over CAN, superseded by XCP but still present in legacy powertrain projects.
DoIP: Diagnostics over Internet Protocol: The ISO 13400 transport that carries UDS diagnostic messages over automotive Ethernet, with vehicle announcement, routing activation and a logical addressing scheme.
DTC: Diagnostic Trouble Code: A coded fault record stored by an ECU, with status bits for confirmed, pending and test-failed conditions, plus freeze-frame data captured when it was set.
EOL programming: End-Of-Line programming: The final assembly-line step that flashes production software, writes calibration and coding data, and injects identifiers and keys into each ECU.
J1939: SAE J1939: The CAN-based higher-layer protocol used in heavy trucks, buses and off-highway equipment, defining parameter groups, suspect parameter numbers and a transport protocol for long messages.
MCAL: Microcontroller Abstraction LayerIn depth: The lowest AUTOSAR basic software layer, containing the drivers that touch microcontroller registers directly for ADC, PWM, SPI, CAN, watchdog and flash.
OBD-II: On-Board Diagnostics generation 2: The legally mandated emissions diagnostic interface, defining a standard connector, a set of parameter IDs and standardised trouble codes accessible to any scan tool.
ODX: Open Diagnostic data eXchange: The ASAM XML format describing an ECU's diagnostic capabilities, including services, data identifiers, DTCs and flash programming sequences.
OTA campaign management: The back-end process of deciding which vehicles or devices receive an update, in what order and under what preconditions, then tracking acceptance, success and rollback across the fleet.
RTE: Runtime Environment: The generated glue layer in AUTOSAR Classic that connects software components to each other and to the basic software, implementing the configured port and interface communication regardless of whe...
SBC: System Basis Chip: An automotive companion IC combining a CAN or LIN transceiver, voltage regulators, a windowed watchdog and often a safety state machine that can force the system into a safe state.
Seed and key: The UDS security access exchange in which a tester requests a seed, computes a key with a secret algorithm and sends it back to unlock protected services such as reprogramming.
SOME/IP: Scalable service-Oriented MiddlewarE over IP: The AUTOSAR automotive Ethernet middleware providing remote procedure calls, event notification and a service discovery protocol over UDP and TCP.
SOVD: Service-Oriented Vehicle Diagnostics: An ASAM standard defining a RESTful, HTTP and JSON based diagnostic interface for high-performance computers and software-defined vehicles, usable both in the workshop and remotely.
SWC: Software Component: The AUTOSAR unit of application software, defined by ports and interfaces and deliberately decoupled from which ECU it runs on.
UDS: Unified Diagnostic Services: The ISO 14229 request and response protocol used to read fault memory, run routines, read and write data identifiers and reprogram ECUs.
Variant coding: The configuration of an installed ECU to match a specific vehicle's options, market and equipment, by writing coding data into its non-volatile memory.
Vehicle Signal Specification: COVESA's open, hierarchical catalogue of standardised vehicle signal names and types, such as Vehicle.Speed, intended as a common vocabulary above proprietary bus definitions.
XCP: Universal Measurement and Calibration Protocol: The ASAM protocol for reading and writing ECU memory while the ECU runs, used to log signals and tune calibration parameters over CAN, Ethernet, FlexRay or SPI.

Build and toolchain

CMakeIn depth: A cross-platform build system generator that turns declarative project files into Ninja or Make builds, with toolchain files describing the cross-compiler and target flags.
Dead code elimination: The removal of functions and data that no reachable code references, usually achieved by compiling with per-function sections and asking the linker to garbage-collect unused ones.
Kconfig: Kernel ConfigurationIn depth: The configuration language and menu system from the Linux kernel, used to express build options, their types and their dependencies.
LTO: Link-Time Optimisation: Compiling to an intermediate representation and deferring optimisation until link time, so the compiler can inline and eliminate across translation units.
Map file: The linker-generated report listing every symbol's final address and size, the contents of each section and why each object was pulled in.
Reproducible build: A build that produces a bit-identical binary from the same source and toolchain regardless of when, where or by whom it is run.
west: Zephyr's meta-tool that manages the multi-repository manifest, fetches modules at pinned revisions and wraps build, flash and debug commands.

Coding standards

MISRA: Motor Industry Software Reliability AssociationIn depth: MISRA: the guidelines for safer use of the C and C++ languages in critical embedded systems, first written for the motor industry and now used widely in automotive, industrial, medical and aerospac...

Debug and trace

CoreSightIn depth: Arm's on-chip debug and trace architecture, defining the access ports, cross-trigger network, trace sources, funnels and sinks that let tools observe cores, buses and system events with minimal int...
Debug probeIn depth: The hardware adapter between a host PC and a target's debug port, converting USB or Ethernet commands into JTAG or SWD transactions and often capturing trace.
ETB: Embedded Trace Buffer: An on-chip SRAM buffer that captures instruction or system trace when no wide off-chip trace port is available, read out over the normal debug connection.
ETM: Embedded Trace Macrocell: A CoreSight trace source that records a compressed stream of the instructions a core executed, and optionally data accesses, without halting it.
Flash programming algorithm: A small routine downloaded into target RAM by a debug probe that performs erase and program operations on that device's flash at full speed.
GDB: GNU DebuggerIn depth: The source-level debugger used across embedded development, connecting to a target through a gdbserver or a probe daemon to set breakpoints, inspect memory and unwind stacks.
ITM: Instrumentation Trace Macrocell: A CoreSight block that lets software emit timestamped trace packets by writing to stimulus port registers, giving low-overhead logging, event markers and printf redirection over a single trace pin.
JTAG chain: Several JTAG-capable devices wired in series on one debug connector, each with its own instruction register length, so tools must know the chain order and lengths to address a specific device.
OpenOCD: Open On-Chip DebuggerIn depth: Open-source software that drives JTAG and SWD adapters, exposing a GDB server and a Tcl command interface for halting cores, programming flash and scripting bring-up.
RTT: Real-Time Transfer: SEGGER's technique for bidirectional host communication through a ring buffer in target RAM that the probe reads over the normal debug interface while the core runs.
Semihosting: A mechanism by which target code executes a special instruction that a connected debugger intercepts to perform host file and console operations.
SWD: Serial Wire DebugIn depth: Arm's two-pin debug interface, using a clock and a bidirectional data line to replace the JTAG port on pin-constrained devices.
SWO: Serial Wire Output: A single-pin asynchronous trace output on ARM Cortex-M devices that carries ITM and DWT packets, giving printf-style messages and lightweight event trace without halting the core.

Embedded Linux and drivers

ALSA: Advanced Linux Sound Architecture: The Linux audio subsystem providing kernel drivers and a user-space API for PCM streams, mixers and controls.
Character device: A Linux device class accessed as an unbuffered stream through a node in /dev, with behaviour defined by a file operations table of open, read, write and ioctl.
Common Clock Framework: The Linux subsystem that models an SoC's clock tree as gates, dividers and multiplexers with reference counting, so drivers request rates rather than poke registers.
Device passthrough: Assigning a physical peripheral directly to one virtual machine or partition, which drives it with its native driver at full performance.
DRM/KMS: Direct Rendering Manager / Kernel Mode Setting: The Linux graphics stack layer that owns display controllers, planes, connectors and GPU buffer management, and performs mode setting in the kernel.
IIO: Industrial I/O: The Linux subsystem for sensors and converters, covering ADCs, DACs, accelerometers, gyroscopes and light sensors, with buffered capture, triggers and a standard sysfs and character device interface.
Kernel module: A Linux driver or subsystem built separately from the kernel image and loaded at runtime, linking against the exact kernel version's symbols.
MSI-X: Message Signalled Interrupts eXtended: A PCIe interrupt mechanism in which a device raises an interrupt by writing to a host address, supporting up to 2048 independently targeted vectors per function.
OCI image: Open Container Initiative image: The standardised layered container image format and its accompanying runtime specification, now used on embedded Linux to ship and update applications independently of the base system.
OverlayFS: Overlay File System: A Linux union file system that presents a writable upper layer over a read-only lower one, with copy-on-write on first modification.
PCIe enumeration: The boot-time process of scanning PCIe buses, reading configuration space, assigning bus numbers and allocating BAR address windows and interrupts to each function.
Platform driver: A Linux driver for a device that is not on a discoverable bus, bound instead by matching a compatible string in the device tree.
PREEMPT_RT: Preemptible Real-Time patch set: The Linux configuration that makes nearly all kernel code preemptible by converting spinlocks to sleeping locks and forcing interrupt handlers into threads.
Read-only root filesystem: A design in which the root file system is mounted read-only, with writable state confined to separate partitions or overlays.
Regulator framework: The Linux subsystem that abstracts voltage regulators and power switches, letting drivers enable supplies and request voltages with reference counting across consumers.
systemd: The init system and service manager used by most Linux distributions, handling dependency-ordered start-up, socket activation, watchdog supervision and journald logging.
V4L2: Video for Linux version 2: The Linux API and subsystem for video capture, output and memory-to-memory devices, including camera sensors, ISPs and hardware codecs.
virtio: A standardised family of paravirtualised device interfaces, including network, block, console and GPU, that guests drive through shared-memory virtqueues.

Enablement and developer tools

Clock configuration tool: A graphical or scripted utility that lets a developer choose PLL, divider and source settings for an SoC's clock tree and emits the corresponding initialisation code.
CoreMark: An EEMBC benchmark for embedded processor cores built from list, matrix, state machine and CRC workloads, designed to resist compiler elimination and to be quoted with its build flags.
Design validation test: The build of a hardware system made with the frozen design and production-intent parts and tooling, used to prove the design meets its requirements through functional, environmental, reliability an...
Developer portal: The vendor website through which engineers obtain SDKs, documentation, errata, licence keys and support tickets.
EEMBC: Embedded Microprocessor Benchmark Consortium: The industry body that defines and certifies embedded benchmarks, including CoreMark, ULPMark for low-power operation, SecureMark and MLMark.
Engineering validation test: The first build of a hardware system's engineering prototypes, used to check that the boards, chips, firmware and software work together end to end and to find the design changes needed before the...
Errata workaround: A documented software change that avoids or compensates for a known silicon defect, such as an extra read after a register write or an avoided peripheral mode.
Hardware and software partitioning: Deciding which functions of a system are built into custom silicon, which into programmable logic, and which run as firmware or software, weighing speed, power, cost, flexibility and schedule, and...
ISS: Instruction Set SimulatorIn depth: A software model that executes target machine code on a host, faithfully at the instruction level but usually not cycle accurate.
LTS branch: Long-Term Support branch: A release line that receives bug and security fixes for an extended period without new features, so products can stay patchable without re-qualifying a whole platform.
MLPerf Tiny: An MLCommons benchmark suite for microcontroller-class machine learning inference, covering keyword spotting, visual wake words, image classification and anomaly detection with latency, accuracy an...
Pinmux: Pin multiplexing: The configuration that selects which internal peripheral function is routed to each physical pin, since packages expose far fewer pins than the SoC has functions.
Sample application: A small, buildable program shipped with an SDK that demonstrates one peripheral or feature end to end on a named board.
SVD: System View Description: A CMSIS XML format describing a device's peripherals, registers and bit fields, from which vendors generate header files and debuggers build register views.
Virtual prototype: A full-system simulation model of an SoC, including processors, memories and peripherals, fast enough to boot real firmware and an operating system.

Firmware and boot

A/B partition: An update scheme that keeps two complete copies of the bootable image, writing the new version to the inactive slot while the active one keeps running, then switching slots at the next boot.
ACPI: Advanced Configuration and Power InterfaceIn depth: Advanced Configuration and Power Interface (ACPI): an open specification through which firmware describes a platform's devices and power controls to the operating system, so it can manage sleep sta...
Boot ROMIn depth: Immutable code masked into the silicon at manufacture that executes on the very first instruction fetch after reset.
BootloaderIn depth: The small program that runs first after reset, initialises clocks, DRAM and essential peripherals, then locates, validates and transfers control to the operating system or application image.
BSP: Board Support PackageIn depth: The collection of bootloader, kernel patches, device drivers, device tree and build configuration that makes an operating system run on a specific board or SoC.
Device treeIn depth: A data structure, written in DTS source and compiled to a binary DTB, that describes a board's hardware to the kernel: memory ranges, buses, peripherals, interrupts, clocks and pin settings.
FirmwareIn depth: Software held in non-volatile memory on a device and executed directly by its processor or microcontroller, providing the lowest layer of control over the hardware.
OTA: Over-the-Air updateIn depth: Delivery of new firmware or software to a deployed device over a wireless or network link, including download, verification, installation and reporting.
Secure bootIn depth: A boot policy in which each stage cryptographically verifies the signature of the next before executing it, anchored in an immutable root of trust such as a fused public key hash.
TF-A: Trusted Firmware-A: An open-source reference implementation of secure world firmware for Arm application processors, covering the secure monitor, boot stages, PSCI power management and interfaces to a trusted OS.
U-Boot: Universal Boot LoaderIn depth: A widely used open-source bootloader for embedded Linux systems, supporting Arm, RISC-V, PowerPC and MIPS targets.
UEFI: Unified Extensible Firmware InterfaceIn depth: A specification for platform firmware that defines boot services, runtime services, driver model and a standard interface to the operating system loader, replacing legacy PC BIOS.

Firmware security and updates

Anti-rollback counter: A monotonic counter, held in fuses or protected flash, that records the minimum acceptable firmware version so a signed but vulnerable older image cannot be reinstalled.
Bootloader fallback: The logic that returns a device to a previous or recovery image when a newly flashed one fails to boot or fails to confirm itself within a watchdog window.
Chain of trust: The sequence in which each boot stage verifies the signature of the next before transferring control, anchored in an immutable root such as boot ROM and a fused public key hash.
Debug authentication: A challenge-response scheme that re-enables a locked debug port only for a party holding the right credential, usually a certificate chain rooted in a device secret.
Debug lock: The permanent or authenticated disabling of JTAG and SWD access on a production part, so an attacker cannot halt the core and read out keys or firmware.
Delta update: A field update that ships only the binary difference between the installed and target images, reconstructing the new image on the device.
Golden image: A known-good, factory-validated firmware image kept in protected storage as a fallback when an update fails or a running image is judged corrupt.
OP-TEE: Open Portable Trusted Execution EnvironmentIn depth: An open-source trusted execution environment for Arm TrustZone, providing a secure-world OS that runs trusted applications alongside a normal-world Linux.
PSA Certified: Platform Security Architecture CertifiedIn depth: An Arm-originated security certification scheme for IoT chips, firmware and devices, run by GlobalPlatform since September 2025, with graded assurance levels and a defined set of trusted firmware A...
RAUC: Robust Auto-Update Controller: An open-source update framework for embedded Linux that installs signed bundles into redundant slots and coordinates with the bootloader over boot state variables.
Remote attestation: A protocol in which a device produces a signed report of its firmware measurements and identity so a remote party can decide whether to trust it.
SPDM: Security Protocol and Data Model: A DMTF specification for authenticating hardware components and measuring their firmware over an existing transport such as MCTP or PCIe.
SWUpdate: Software Update for embedded systems: An open-source update agent for embedded Linux that applies signed images described by a sw-description recipe, supporting single-copy, dual-copy and streaming installs.

Memory and execution

Bit-banding: An ARM Cortex-M feature that maps each bit of a peripheral or SRAM region to its own word address, so a single store performs an atomic read-modify-write of one bit.
BSS: Block Started by Symbol: The linker section holding statically allocated variables that are zero-initialised, which therefore occupy RAM but no space in the image.
Cache maintenance: The explicit clean and invalidate operations software must perform so that a cached view of memory agrees with what another master, such as a DMA engine, sees.
crt0: C Runtime Zero: The small start-up object that prepares the C execution environment: copying initialised data from flash to RAM, zeroing BSS, running static constructors and calling main.
DMA coherency: The problem of keeping processor caches and DMA-visible memory consistent when a peripheral writes or reads buffers directly.
Dual-bank flash: An embedded flash architecture split into two independently erasable and readable banks, so firmware can execute from one while programming the other.
EEPROM emulationIn depth: A firmware layer that provides byte-addressable, frequently rewritable non-volatile storage on top of page-erased flash, by journaling records across two or more sectors and compacting when full.
Flash wear levelling: A firmware technique that spreads erase and program cycles across physical blocks so no single block reaches its endurance limit first.
Heap fragmentation: The gradual break-up of free heap memory into blocks too small to satisfy a request, even though the total free space is sufficient.
Memory pool: A pre-allocated array of fixed-size blocks handed out and returned in constant time, giving dynamic-like behaviour without fragmentation or unbounded latency.
MMIO: Memory-Mapped I/O: The scheme in which peripheral registers appear at addresses in the processor's normal address space, so ordinary load and store instructions configure hardware.
MPU: Memory Protection Unit: A hardware block that enforces access permissions on a small number of address regions without providing virtual addressing.
NVM driver: Non-Volatile Memory driver: The software layer that abstracts flash or EEPROM access into read, write and erase jobs with status reporting, hiding block geometry and timing from upper layers.
Position-independent code: Code compiled so that it executes correctly regardless of the address it is loaded at, using program-counter-relative addressing and an offset table for globals.
Reset handler: The first function executed after reset, which sets the stack pointer, initialises RAM sections and the clock tree, then calls the C runtime start-up and main.
Scatter file: The ARM toolchain's description of how code and data regions are placed into a device's memory map, naming load and execution addresses for each region.
Stack canary: A known value placed at the end of a stack region or beside a return address, checked periodically or on function exit to detect an overflow.
Static allocation: A policy of reserving all memory for tasks, stacks, queues and buffers at compile or initialisation time, so nothing can fail or fragment later.
XIP: eXecute In Place: Running code directly from non-volatile memory, typically NOR or octal SPI flash, instead of copying it into RAM first.

Middleware and stacks

CAN stack: Controller Area Network stack: The layered software above a CAN controller, handling frame transmission and reception, transport protocol segmentation, network management and diagnostic services.
CMSIS: Common Microcontroller Software Interface Standard: Arm's vendor-independent abstraction layer for Cortex-M devices, defining core register access, startup code, DSP and neural network kernel libraries, an RTOS API and machine-readable device descri...
DDS: Data Distribution Service: An OMG standard for data-centric publish/subscribe middleware, with typed topics, discovery and a rich set of quality-of-service policies covering reliability, durability and deadlines.
Device driverIn depth: Software that manages a specific hardware block, translating generic operating system or framework calls into register writes, DMA setup and interrupt handling.
HAL: Hardware Abstraction LayerIn depth: A thin software layer that presents hardware functions through a stable API so that upper layers do not touch registers directly.
MQTT: Message Queuing Telemetry Transport: A lightweight publish/subscribe messaging protocol over TCP in which clients exchange messages through a broker using hierarchical topics and three quality-of-service levels.
SDK: Software Development KitIn depth: A packaged set of libraries, headers, drivers, examples, build scripts and documentation that lets a customer write software for a chip or platform.
TCP/IP stack: Transmission Control Protocol/Internet Protocol stack: The layered networking software that implements IP, TCP, UDP, ICMP and supporting protocols on a device, handing packets between applications and the MAC driver.
USB stack: Universal Serial Bus stack: The host or device software that manages USB enumeration, descriptors, endpoints, transfer scheduling and class drivers such as mass storage, CDC serial or HID.

Operating systems

Android Automotive OS: Google's automotive variant of Android that runs directly on head unit hardware as the in-vehicle infotainment operating system, with vehicle-specific HALs for climate, HVAC and vehicle properties.
BuildrootIn depth: A simpler alternative to Yocto that generates a complete embedded Linux root filesystem, kernel and bootloader from a single Kconfig-driven make invocation.
Embedded LinuxIn depth: The use of the Linux kernel and a trimmed user space on a resource-constrained product rather than a general-purpose computer, typically built from a cross-compiled image with only the packages the...
FreeRTOSIn depth: A widely deployed open-source real-time kernel for microcontrollers, offering tasks, queues, semaphores and timers in a few kilobytes of code.
QNXIn depth: A commercial microkernel real-time operating system from BlackBerry, in which drivers and services run as isolated user-space processes.
RTOS: Real-Time Operating SystemIn depth: A small kernel that schedules tasks so that timing deadlines are met deterministically, typically with priority-based pre-emption, bounded interrupt latency and predictable synchronisation primitives.
VxWorks: Wind River's long-established commercial RTOS for high-reliability embedded systems, offering deterministic scheduling, POSIX interfaces and certification evidence for avionics, rail, defence and i...
Yocto ProjectIn depth: A build framework that produces custom embedded Linux distributions from recipes and layers, using the BitBake engine to cross-compile a reproducible image, SDK and licence manifest for a given board.
ZephyrIn depth: A permissively licensed, vendor-neutral RTOS hosted by the Linux Foundation, with a Linux-style build system, device tree based configuration, an extensive driver model and integrated networking an...

RTOS and scheduling

Activation jitter: The variation in the actual start time of a periodic task relative to its ideal release instant, caused by interrupts, higher priority work and tick granularity.
ARINC 653: Aeronautical Radio Incorporated specification 653: The avionics standard defining a partitioned real-time operating system interface, with fixed cyclic time windows, isolated memory partitions and defined inter-partition ports.
Bare-metalIn depth: Firmware that runs directly on the processor with no operating system, managing interrupts, timing and peripherals itself.
Context switch: The act of saving one task's processor register state and restoring another's so that execution can resume where it left off.
Cooperative scheduling: A scheduling policy in which a task runs until it voluntarily yields or blocks, so switches happen only at known points.
Critical section: A region of code that must not be interrupted or concurrently entered, typically protected by disabling interrupts, taking a lock or suspending the scheduler.
Deadline miss: An occurrence of a task completing after the time by which its result was required.
Event flag: A bit within a kernel-managed group that tasks can set and wait on, with the option to wait for any or all of a mask of bits.
Hard real-time: A class of system in which missing a timing deadline is a functional failure, so worst-case rather than average behaviour governs the design.
Interrupt latency: The time from an interrupt being asserted to the first instruction of its handler executing, including any period in which interrupts were disabled.
ISR: Interrupt Service Routine: The function a processor jumps to when a peripheral or timer raises an interrupt, executed with normal task scheduling suspended.
Message queue: A kernel object that passes fixed-size items between tasks in FIFO order, blocking the sender when full and the receiver when empty.
Mutex: Mutual exclusion object: A kernel object that grants exclusive access to a shared resource, with ownership so that only the locking task may unlock it.
Nested interrupts: The ability of a higher priority interrupt to preempt a handler already running at a lower priority.
NVIC: Nested Vectored Interrupt Controller: The interrupt controller integrated into ARM Cortex-M cores, which holds per-interrupt enable and priority settings and dispatches directly to a handler address from the vector table.
Preemptive scheduling: A scheduling policy in which the kernel can suspend a running task at any point to run a higher priority one that has become ready.
Priority inheritance: A mutex protocol in which a task holding a lock temporarily inherits the priority of the highest priority task waiting on it, so it cannot be preempted by unrelated medium priority work.
Priority inversion: The situation where a high priority task is blocked waiting on a resource held by a low priority task, which is itself preempted by unrelated medium priority work.
Rate-monotonic scheduling: A fixed-priority policy in which the shortest-period task gets the highest priority, proven optimal among fixed-priority schemes for independent periodic tasks.
Semaphore: A counting kernel object used to signal events or to manage a pool of identical resources, where tasks take and give units and block when none remain.
Spinlock: A lock that busy-waits in a tight loop until it is free, rather than blocking and yielding the processor.
Stack high-water mark: The deepest point a task's stack has reached since it started, measured by pre-filling the stack with a known pattern and finding the last untouched word.
Superloop: The bare-metal structure of an infinite main loop that polls and services each subsystem in turn, with interrupts handling anything urgent.
SysTick: System Tick Timer: The small 24-bit down-counting timer defined in the ARM Cortex-M architecture and reserved for operating system use.
Task control block: The kernel data structure holding everything the scheduler needs about a task: its saved stack pointer, priority, state, and queue links.
Tickless idle: A kernel mode that stops the periodic scheduler tick when no task is runnable and reprograms a timer for the next known deadline, letting the core stay in a deep sleep state for longer.
Time partitioning: The allocation of guaranteed, enforced windows of processor time to separate software partitions, so that overrun in one cannot steal time from another.
Vector table: The array of handler addresses, placed at a known location in memory, that the processor indexes when an exception or interrupt fires.
Watchdog kick: The periodic write that refreshes a watchdog timer to prove software is still alive; if it stops, the watchdog resets the device.
WCET: Worst-Case Execution Time: The maximum time a piece of code can take to run on given hardware, over all inputs and states.

Silicon enablement

Application noteIn depth: A short vendor document explaining how to use a device for a specific purpose, covering circuit configuration, register settings, example code and measured results.
Board bring-upIn depth: The first phase after a new board arrives, in which power rails, clocks, reset, debug access, memory and each peripheral are proven in sequence until an operating system or application boots reliably.
Development kit: A packaged bundle of board, debug interface, cables, software tools and getting-started material that lets an engineer run code on a new device within an hour.
Ecosystem partner programme: A structured scheme by which a silicon vendor recruits, qualifies and promotes third parties, such as module makers, design houses, tool suppliers and software companies, that build products on its...
Evaluation boardIn depth: A vendor-built circuit board that exposes a chip's interfaces, power rails and test points so that a customer can measure its behaviour and run demonstration software before committing to a design.
Register mapIn depth: The documented list of a device's programmable registers with addresses, bit fields, reset values and access rights.
Silicon errata: The vendor's published list of ways a manufactured device deviates from its specification, each with conditions, impact and a recommended software or hardware workaround.

Simulation and validation

FMI: Functional Mock-up Interface: An open standard for exchanging and co-simulating dynamic system models between tools, defining a C API, an XML model description and a packaging format.
FMU: Functional Mock-up Unit: The deliverable artefact of the FMI standard: a zip archive containing a model description file plus compiled binaries or source, which any FMI-compatible simulator can import and step.
HIL: Hardware-in-the-Loop: A test method in which the real controller hardware runs its production software while a real-time simulator emulates the plant, sensors and network around it.
MIL: Model-in-the-LoopIn depth: The earliest simulation stage, where the control algorithm exists only as an executable model, typically in Simulink or a similar environment, and is validated against a plant model before any code...
QEMU: Quick EMUlatorIn depth: An open-source machine emulator and virtualiser that can run full system images for a foreign architecture on a host, modelling CPU, memory and common peripherals.
SIL: Software-in-the-Loop: Testing in which the production source code is compiled for the host PC and run against a simulated plant model, with no target hardware present.
Virtual ECU: Virtual Electronic Control Unit: A software model of a controller that runs its real application and basic software on a host or in a virtual machine, with simulated peripherals and bus interfaces.

Software process

ASPICE: Automotive Software Process Improvement and Capability dEtermination: A process assessment model, derived from ISO/IEC 330xx, used by carmakers to rate a supplier's software engineering processes from requirements through design, implementation, test and support on a...
CERT C: CERT C Coding Standard: A secure coding standard from the CERT division at Carnegie Mellon that lists rules and recommendations for avoiding exploitable defects in C, such as buffer overflows, integer overflow and misuse...
Continuous integration: The practice of merging changes into a shared code base often and building and testing each change automatically, so that problems are found within hours rather than at a late integration.
MC/DC: Modified Condition/Decision Coverage: A structural test coverage criterion requiring that each boolean condition in a decision be shown to independently affect the outcome.
MISRA C: Motor Industry Software Reliability Association C guidelinesIn depth: A set of coding rules and directives that restrict C to a safer subset, limiting constructs with undefined, unspecified or implementation-defined behaviour.
Release notes: The document issued with a release of software, firmware, IP or a design kit that states what it contains, what changed since the previous version, known issues and limits, and any action users mus...
Static analysisIn depth: Automated inspection of source or binary code without executing it, to find defects such as null dereferences, overflows, data races and coding-standard violations.
Version control: Systems and practices that record every change to files such as source code, RTL, scripts and documents, with who made it and why, so that any earlier version can be recovered and parallel work mer...

Software quality and safety

CVE: Common Vulnerabilities and ExposuresIn depth: The public identifier scheme for disclosed software vulnerabilities, each entry naming affected versions and carrying a severity score.
Device farm: A rack of real target boards wired to power control, programmers and instrumentation, driven by continuous integration so that every commit is flashed and tested on hardware.
DO-178C: Software Considerations in Airborne Systems and Equipment CertificationIn depth: The airborne software assurance standard defining objectives by design assurance level from A to E, covering planning, development, verification, configuration management and quality assurance.
Fault injection testingIn depth: Deliberately introducing errors, such as corrupted memory, stuck sensor values, bus failures or flipped bits, to verify that detection and safe-state mechanisms work.
Freedom from interference: The demonstrated absence of a cascading failure from a lower-criticality software element into a higher-criticality one, covering memory, timing and execution, and information exchange.
Host test: Compiling embedded source for the development machine and running its unit tests there, with hardware access replaced by test doubles.
IEC 62304: Medical device software life cycle processes: The standard governing medical device software, classifying it as safety class A, B or C by the severity of harm a failure could cause and setting required life-cycle activities for each.
ISO 26262-6: ISO 26262 Part 6: Product development at the software level: The part of the automotive functional safety standard covering software architecture, unit design, coding guidelines, verification and testing, with method tables recommended by ASIL.
On-target test: Executing tests on the real device with its real peripherals and timing, rather than on a host or simulator.
Qualified compiler: A compiler supplied with evidence, test suites and known-defect reporting sufficient to use its output in a certified product without separately verifying every translation.
Requirements traceabilityIn depth: The maintained bidirectional links from each requirement to its design, code and tests, so it can be shown that everything required is implemented and everything implemented is required.
SBOM: Software Bill Of MaterialsIn depth: A machine-readable inventory of every component, version and licence in a shipped software image, expressed in formats such as SPDX or CycloneDX.
Secure development lifecycle: A development process that builds in threat modelling, secure coding standards, code review, security testing and an incident response path, rather than auditing security at the end.
SOUP: Software Of Unknown Provenance: Software already developed and generally available that was not produced for the current device, including commercial libraries and open source.
TCL: Tool Confidence LevelIn depth: The ISO 26262 classification of how much a development tool must be qualified, derived from the impact of a tool error and the likelihood of detecting it.

Toolchain

ABI: Application Binary Interface: The binary-level contract between separately compiled components: register use and calling convention, stack alignment, argument and return passing, data layout, name mangling and system call conve...
Cross-compiler: A compiler that runs on one architecture, the host, and emits code for a different one, the target.
ELF: Executable and Linkable Format: The standard container for object files, executables, shared libraries and core dumps on Unix-like and most embedded systems.
GCC: GNU Compiler CollectionIn depth: The long-established free software compiler suite supporting C, C++, Ada, Fortran and more, with back ends for nearly every embedded architecture.
Linker script: A file that tells the linker how to map code and data sections onto the target's memory regions, setting load and run addresses, stack and heap placement and symbol values.
LLVMIn depth: A modular compiler infrastructure built around a typed intermediate representation, with reusable optimisation passes and code generators.
ProfilerIn depth: A tool that measures where a program spends time, memory or energy, by sampling the program counter, instrumenting functions or reading performance counters and trace.
ToolchainIn depth: The coordinated set of programs that turns source code into a runnable image: compiler, assembler, linker, C library, and the binary utilities that inspect and convert the result.

Virtualisation

HypervisorIn depth: A software layer that partitions one physical processor and its memory and peripherals into several virtual machines, each running its own operating system.
Mixed criticality: A system design in which software of different safety or security assurance levels shares one processor, for example an ASIL D control task alongside a QM infotainment stack.
PartitioningIn depth: Dividing a shared processor's resources so that software in one partition cannot corrupt another's memory (spatial partitioning) or steal its execution time and bandwidth (temporal partitioning).
Type 1 hypervisor: A hypervisor that runs directly on the hardware with no host operating system beneath it, owning the CPU scheduling and memory partitioning itself.
Type 2 hypervisor: A hypervisor that runs as a process on top of a conventional host operating system, relying on the host for scheduling, drivers and memory management.

Missing a term? Search the full glossary for Embedded Software & Tools and suggest it there.