Embedded Systems & RTOS

An operating system designed to guarantee response to events within a defined deadline (hard or soft real-time). Provides deterministic task scheduling, inter-task communication primitives, and minimal interrupt latency.

"We chose FreeRTOS for the motor control unit — it provides deterministic task scheduling with a worst-case interrupt latency of 3 microseconds. A general-purpose Linux kernel's non-deterministic scheduling made it unsuitable for hard real-time control loops."

The basic unit of execution in an RTOS — an independent thread with its own stack, priority level, and state (running, ready, blocked, suspended). The RTOS scheduler decides which task runs at any moment based on priority and availability.

"The system has 5 tasks: motor control (priority 5, 1ms period), sensor reading (priority 4, 10ms), CAN communication (priority 3, event-driven), UI update (priority 2, 100ms), and data logging (priority 1, background). Higher-priority tasks preempt lower-priority ones."

An RTOS scheduling strategy where the scheduler can suspend a currently running task and switch to a higher-priority ready task immediately, without waiting for the running task to yield. Required for hard real-time systems.

"Preemptive scheduling is essential for our safety system: the watchdog alert task at priority 10 can interrupt the data logging task at priority 2 within one scheduler tick (1ms), guaranteeing the alert is processed within deadline."

A hardware-triggered function that runs immediately when a peripheral or timer interrupt fires, suspending the current execution context. ISRs must be short, non-blocking, and must not use RTOS APIs that could cause blocking.

"The UART receive ISR copies the incoming byte to a circular buffer and sets a flag. It does not process the data — that happens in the communication task, which is unblocked by the flag. Keeping ISRs minimal is a fundamental embedded engineering practice."

A software layer that provides a standardised API for accessing hardware peripherals (GPIO, SPI, I2C, UART), abstracting hardware-specific register access behind portable function calls.

"The temperature sensor driver calls HAL_SPI_Transmit() rather than writing directly to the SPI data register. This means the same driver code runs on STM32F4 and STM32H7 targets — only the HAL implementation changes when we move to new silicon."

A collection of hardware-specific initialisation code, peripheral drivers, memory map definitions, and linker scripts for a specific PCB (board) design — the lowest software layer between the hardware and the OS or application.

"The BSP for our custom PCB configures the clock tree, initialises DDR memory, sets up GPIO multiplexing for our peripheral layout, and provides the hardware-specific printf redirect to the debug UART. Without the BSP, FreeRTOS wouldn't know how to initialise the hardware."

A set of C language coding guidelines originally developed for automotive safety-critical software. Used in medical devices, aerospace, and industrial control systems. Restricts or prohibits language features that are prone to undefined behaviour.

"MISRA C 2012 compliance is required by our automotive customer's safety manager. Rule 15.5 prohibits multiple return statements in a function, Rule 10.1 prohibits implicit type conversions — the static analysis gate rejects any MISRA violation before a PR can merge."

Embedded software that runs directly on hardware without an operating system — a single infinite loop with interrupt handlers, no task scheduler, no memory management, no OS primitives. Used when RTOS overhead is unacceptable.

"The bootloader runs bare metal — no RTOS, no HAL, just direct register writes to initialise the flash controller, copy the application image from external flash, verify the CRC, and jump to the application entry point. Sub-50ms boot time is required."

Synchronisation primitives in an RTOS. A mutex protects a shared resource from concurrent access (binary, with ownership). A counting semaphore signals resource availability or event occurrence between tasks or between ISRs and tasks.

"The SPI bus is shared between the display driver and the sensor driver tasks. We protect it with a mutex — whichever task acquires the mutex owns the bus. The sensor task tries to take the mutex with a 10ms timeout; if the display task holds it longer, the sensor task logs a timeout and retries."

A hardware or software timer that resets the microcontroller if the main application fails to periodically "kick" (reset) the timer within a defined window — detecting software hangs and triggering a controlled recovery.

"Every task kicks the watchdog at the end of its main loop. If the motor control task misses its kick for 50ms — indicating it's stuck or deadlocked — the watchdog fires a hardware reset and the system boots into safe state, stopping all actuators."

A configuration file for the linker that defines the memory map of the target device — specifying where flash, RAM, and peripheral registers are located, and how code sections (.text, .data, .bss) are placed in memory.

"The linker script defines two RAM regions: main RAM (128KB for stack and heap) and tightly-coupled memory (64KB for the motor control ISR code, marked ITCM for zero wait-state execution). Placing ISR code in ITCM reduces worst-case interrupt latency by 40%."