C/C++ on embedded systems

Why this matters

C and C++ remain the main languages of embedded systems because they control memory and hardware directly and run fast; both ArduPilot and PX4 are written in C++. But that power brings risk: variables that overflow silently, or variables the compiler optimises away because it does not know the hardware can change them, cause the hardest bugs to find. This module uses Python to simulate those behaviours before writing on a real board.

Fixed-width data types

Embedded code should use types of known size from <stdint.h>, such as uint8_t (0 to 255), int16_t and uint32_t, rather than int, whose size depends on the chip. When a value exceeds the range, unsigned integers wrap around without warning.

def as_uint8(x):
    return x & 0xFF                       # keep only the low 8 bits, like uint8_t


count = 250
for pulse in range(8):
    count = as_uint8(count + 1)
    print(count, end=" ")
print()
print("elapsed pulses between readings 250 and 2:", as_uint8(2 - 250))

251 252 253 254 255 0 1 2
elapsed pulses between readings 250 and 2: 8

Manipulating register bits

Peripherals are controlled through registers, in which each bit has a meaning: one bit turns on an LED, another selects a mode. Changing one bit must not disturb the others.

reg = 0b00101001
print(f"start        {reg:08b}")
reg |= 1 << 4            # set bit 4
print(f"set bit 4    {reg:08b}")
reg &= ~(1 << 0) & 0xFF  # clear bit 0
print(f"clear bit 0  {reg:08b}")
reg ^= 1 << 7            # toggle bit 7
print(f"toggle bit 7 {reg:08b}")
print("bit 3 is", (reg >> 3) & 1, "| bits 5..4 as a field:", (reg >> 4) & 0b11)

start        00101001
set bit 4    00111001
clear bit 0  00111000
toggle bit 7 10111000
bit 3 is 1 | bits 5..4 as a field: 3

volatile

Compilers speed up code by assuming a variable only changes when the program writes it. But hardware registers and variables modified by interrupts can change without the main program knowing. The volatile qualifier tells the compiler to read the value from memory every time. Per Arm’s guide, use it for peripheral registers, variables shared with interrupt routines and variables shared between threads.

volatile uint8_t data_ready = 0;      /* ISR sets it, main loop reads it */

void sensor_isr(void) { data_ready = 1; }

int main(void) {
    for (;;) {
        if (data_ready) {             /* without volatile the compiler may read this only once */
            data_ready = 0;
            read_sensor();
        }
    }
}

Memory and coding standards

An MCU has little SRAM. The stack holds function variables and grows downwards with nested calls; the heap holds memory requested at run time. If they grow into each other, the program fails unpredictably, so safety-critical systems often forbid dynamic allocation after start-up.

Coding standards help prevent such bugs. MISRA C (the current edition is MISRA C:2025) is used where safety matters, such as automotive and aviation, and Barr Group’s BARR-C:2018 is a free standard that makes a good starting point.

Module lab

Common mistakes

Summary

• Use fixed-width types, and watch for unsigned wrap-around
• Set bits with OR, clear with AND of the complement, toggle with XOR
• volatile forces a real read every time, for registers and interrupt-shared variables
• Stack and heap share SRAM, and MISRA C and BARR-C help reduce bugs

Check your understanding

1. What is the largest value a uint16_t can hold?
2. A uint8_t holds 200. What is it after adding 100?
3. What is register 0b00001111 after clearing bit 2?
4. Why must a variable modified by an ISR be declared volatile?
5. Which C coding standard is a free download?