Electronics Guide

Memory Sections

Embedded C programs divide memory into distinct sections, each serving specific purposes:

Text section (.text): Contains executable code, typically stored in flash memory. This section is read-only during execution, protecting code from accidental modification.

Read-only data (.rodata): Stores constant data such as string literals and const-qualified variables. Like the text section, this typically resides in flash memory.

Initialized data (.data): Contains global and static variables with non-zero initial values. The initial values are stored in flash and copied to RAM during startup.

Uninitialized data (.bss): Holds global and static variables without explicit initializers. The startup code zeroes this section in RAM, requiring no flash storage for initial values.

Stack: Provides storage for local variables, function parameters, and return addresses. The stack grows and shrinks as functions are called and return.

Heap: Optional memory region for dynamic allocation. Many embedded systems avoid heap usage due to fragmentation concerns and the unpredictable nature of dynamic allocation.

Linker Scripts

Linker scripts define how the linker places program sections in memory. Understanding linker scripts is essential for embedded development, as incorrect memory placement causes immediate program failure.

A typical linker script specifies memory regions available on the target device, assigns sections to appropriate regions, defines symbols for the startup code to use when initializing data sections, and configures stack and heap locations and sizes.

Developers must ensure their linker scripts accurately reflect the target hardware's memory map. Attempting to place code in non-existent memory or data in read-only memory results in systems that fail to boot or exhibit mysterious runtime errors.

Stack Management

Stack overflow is a common source of embedded system failures. Unlike desktop systems where the operating system may detect and handle stack overflow, bare-metal embedded systems typically crash without warning when the stack exceeds its allocated space.

Preventing stack overflow requires allocating sufficient stack space based on maximum call depth, avoiding deeply recursive algorithms, minimizing large local arrays that consume stack space, and using static analysis tools to estimate maximum stack usage.

Stack painting or stack monitoring techniques can help detect stack overflow during development. These approaches fill the stack with known patterns and periodically check whether the patterns have been overwritten.

When to Use Volatile

The volatile qualifier is essential in three primary situations:

Hardware registers: Memory-mapped hardware registers can change value due to hardware events, independent of program execution. Reading a status register might return different values on successive reads as hardware state changes. Similarly, writing to a control register causes hardware side effects beyond simply storing a value.

Variables shared with interrupt handlers: When main code and interrupt service routines share variables, the compiler cannot see that interrupts modify those variables. Without volatile, the compiler might optimize away seemingly redundant reads, causing the main code to miss changes made by interrupts.

Variables shared between threads: In multi-threaded systems, variables shared between threads require volatile to prevent similar optimization issues. However, volatile alone is insufficient for thread safety; proper synchronization mechanisms are also required.

Volatile Semantics

The volatile qualifier provides specific guarantees: every read from a volatile variable accesses memory rather than using a cached value, every write to a volatile variable stores to memory immediately, and reads and writes to volatile variables occur in program order relative to other volatile accesses.

Importantly, volatile does not guarantee atomicity or provide memory barriers between volatile and non-volatile accesses. For multi-threaded code, additional synchronization is necessary.

Proper Volatile Usage

Consider a hardware register at address 0x40000000 that provides status information. The correct way to access it:

#define STATUS_REG (*(volatile uint32_t *)0x40000000)

void wait_for_ready(void) {
    while ((STATUS_REG & READY_BIT) == 0) {
        // Wait for hardware to become ready
    }
}

Without volatile, the compiler might read STATUS_REG once before the loop, then test the same cached value forever, never detecting when hardware becomes ready.

Volatile Pointers versus Pointers to Volatile

The placement of volatile affects its meaning. Understanding the distinction is crucial:

volatile uint32_t *ptr declares a pointer to volatile data. The pointer itself is not volatile, but the data it points to is.

uint32_t * volatile ptr declares a volatile pointer to non-volatile data. The pointer value may change unexpectedly, but the data it points to is normal.

volatile uint32_t * volatile ptr declares a volatile pointer to volatile data. Both the pointer and the data may change unexpectedly.

For hardware registers, typically only the data is volatile; the register addresses are constants known at compile time.

Bitwise Operators

C provides six bitwise operators for manipulating individual bits:

AND (&): Produces 1 only where both operands have 1. Used to mask off bits or test whether specific bits are set.

OR (|): Produces 1 where either operand has 1. Used to set specific bits while preserving others.

XOR (^): Produces 1 where operands differ. Used to toggle bits or compare values.

NOT (~): Inverts all bits. Used to create masks for clearing bits.

Left shift (<<): Shifts bits toward higher positions, filling with zeros. Multiplies by powers of two.

Right shift (>>): Shifts bits toward lower positions. For unsigned types, fills with zeros. For signed types, behavior is implementation-defined.

Common Bit Operations

Several patterns appear repeatedly in embedded code:

Setting a bit: Use OR with a mask containing 1 in the desired position:

register_value |= (1 << bit_position);

Clearing a bit: Use AND with the inverse of a mask:

register_value &= ~(1 << bit_position);

Toggling a bit: Use XOR with a mask:

register_value ^= (1 << bit_position);

Testing a bit: Use AND to isolate the bit, then test for non-zero:

if (register_value & (1 << bit_position)) {
    // Bit is set
}

Extracting a bit field: Shift right to align the field, then mask off unwanted bits:

field_value = (register_value >> field_start) & field_mask;

Inserting a bit field: Clear the field, then OR in the new value:

register_value = (register_value & ~(field_mask << field_start)) |
                 ((new_value & field_mask) << field_start);

Bit Field Structures

C provides bit fields within structures for convenient access to individual bits:

typedef struct {
    uint32_t enable     : 1;
    uint32_t mode       : 3;
    uint32_t reserved   : 4;
    uint32_t prescaler  : 8;
    uint32_t count      : 16;
} timer_config_t;

While convenient, bit fields have portability concerns. The C standard leaves bit field layout implementation-defined, including bit ordering within storage units and whether bit fields can cross storage unit boundaries. For maximum portability, especially when accessing hardware registers, explicit masking and shifting is more reliable than bit fields.

Efficient Bit Manipulation

Several techniques improve bit manipulation efficiency:

Combine operations: When modifying multiple bits, combine them into single operations rather than modifying one bit at a time. This reduces the number of read-modify-write cycles.

Use constants for masks: Define bit masks as preprocessor constants or enumerations. The compiler can evaluate these at compile time, avoiding runtime computation.

Consider architecture-specific instructions: Many processors provide specialized bit manipulation instructions. Compilers often recognize common patterns and generate optimal code, but inline assembly may be necessary for unusual operations.

Memory-Mapped I/O

Most embedded processors access peripherals through memory-mapped I/O, where hardware registers appear at specific memory addresses. Reading or writing these addresses communicates with the hardware rather than accessing ordinary memory.

The fundamental technique for accessing a hardware register:

#define PERIPHERAL_BASE  0x40000000
#define CONTROL_OFFSET   0x00
#define STATUS_OFFSET    0x04
#define DATA_OFFSET      0x08

#define CONTROL_REG  (*(volatile uint32_t *)(PERIPHERAL_BASE + CONTROL_OFFSET))
#define STATUS_REG   (*(volatile uint32_t *)(PERIPHERAL_BASE + STATUS_OFFSET))
#define DATA_REG     (*(volatile uint32_t *)(PERIPHERAL_BASE + DATA_OFFSET))

This pattern casts the address to a pointer to volatile data, then dereferences it to create an lvalue that can be read or written.

Register Structures

For peripherals with many registers, structures provide cleaner organization:

typedef struct {
    volatile uint32_t CONTROL;
    volatile uint32_t STATUS;
    volatile uint32_t DATA;
    volatile uint32_t reserved[5];
    volatile uint32_t CONFIG;
} peripheral_regs_t;

#define PERIPHERAL ((peripheral_regs_t *)0x40000000)

// Usage:
PERIPHERAL->CONTROL = 0x01;
uint32_t status = PERIPHERAL->STATUS;

Structure-based access is cleaner and allows the compiler to compute offsets at compile time. However, the structure layout must exactly match the hardware register layout, including any reserved or padding registers.

Read-Modify-Write Hazards

When modifying specific bits in a register while preserving others, the typical pattern reads the current value, modifies the desired bits, and writes the result back. This read-modify-write sequence creates potential hazards:

Interrupt hazards: If an interrupt occurs between the read and write, and the interrupt handler modifies the same register, the main code will overwrite the interrupt's changes. Disabling interrupts around critical read-modify-write sequences prevents this.

Hardware hazards: Some registers have bits that hardware can modify while the processor is performing the read-modify-write. Careful study of hardware documentation reveals which registers have such hazards and how to handle them.

Write-only registers: Some registers are write-only; reading them returns undefined data or zero. Read-modify-write is impossible for these registers. Software must maintain shadow copies of the written values if bit manipulation is needed.

Access Width

Hardware registers often require specific access widths. A 32-bit register might require 32-bit accesses; attempting to write it as four separate bytes might not work correctly. Similarly, some peripherals have registers that must be accessed as 8-bit or 16-bit quantities.

Using appropriately sized types (uint8_t, uint16_t, uint32_t) and volatile qualification typically generates correct access widths. However, structure access and compiler optimizations can sometimes combine or split accesses unexpectedly. When access width is critical, verify the generated assembly code.

Common Optimization Techniques

Dead code elimination: The compiler removes code that cannot affect program output. This includes unreachable code and computations whose results are never used.

Constant folding: Expressions involving only constants are evaluated at compile time. This includes arithmetic, logical operations, and even function calls in some cases.

Common subexpression elimination: When the same expression appears multiple times, the compiler computes it once and reuses the result.

Loop optimizations: Compilers move invariant computations out of loops, unroll small loops, and sometimes vectorize loops using SIMD instructions.

Inlining: Small functions are expanded inline at call sites, eliminating function call overhead and enabling further optimization across the combined code.

Register allocation: Frequently used variables are kept in processor registers rather than memory, dramatically improving access speed.

Optimization Levels

Compilers provide optimization level flags that control the aggressiveness of optimization:

-O0: No optimization. Code is straightforward to debug but inefficient. Useful during initial development.

-O1: Basic optimization. Improves performance with minimal impact on compile time and code size.

-O2: Standard optimization. Good balance of performance, code size, and compilation time. Often the default for production code.

-O3: Aggressive optimization. May increase code size substantially and sometimes causes unexpected behavior if code relies on undefined behavior.

-Os: Optimize for size. Similar to -O2 but prefers smaller code over faster code. Important for memory-constrained systems.

-Og: Optimize for debugging. Applies optimizations that don't interfere with debugging.

Function Attributes

Compiler-specific attributes provide fine-grained control over optimization:

inline: Suggests the compiler inline a function. The compiler may ignore this suggestion.

always_inline: Forces inlining (GCC/Clang attribute). Use sparingly as excessive inlining increases code size.

noinline: Prevents inlining. Useful for debugging or when function call overhead is acceptable and code size is critical.

pure: Indicates a function has no side effects and depends only on parameters and global memory. Enables additional optimization.

const: Stricter than pure; function depends only on parameters. Multiple calls with the same arguments can be eliminated.

noreturn: Indicates a function never returns. Allows optimization of code following calls to such functions.

Avoiding Optimization Barriers

Certain constructs prevent optimization or cause compilers to generate suboptimal code:

Function pointers: Calling through function pointers prevents inlining and limits interprocedural optimization.

Pointer aliasing: When the compiler cannot determine whether pointers alias (point to the same memory), it must assume they might, preventing certain optimizations. The restrict keyword helps in some cases.

Volatile accesses: Necessary for hardware access but prevent many optimizations. Use volatile only where required.

Memory barriers: Explicit memory barriers prevent instruction reordering across them, which may inhibit optimization.

When to Use Inline Assembly

Inline assembly is appropriate in limited circumstances:

Special instructions: Processor-specific instructions without C equivalents, such as interrupt enable/disable, cache control, or atomic operations.

Precise timing: When exact cycle counts matter and compiler-generated code varies unpredictably.

Critical performance: Hot spots where hand-optimized assembly significantly outperforms compiled code. This is increasingly rare with modern compilers.

Startup code: Processor initialization before the C runtime is operational.

GCC Extended Assembly Syntax

GCC and compatible compilers provide extended inline assembly with explicit specification of inputs, outputs, and clobbered registers:

uint32_t result;
uint32_t operand = 42;

asm volatile (
    "instruction %0, %1"
    : "=r" (result)          // Output operands
    : "r" (operand)          // Input operands
    : "memory"               // Clobbers
);

The constraint letters specify how operands are passed. Common constraints include "r" for any general register, "m" for memory operand, "i" for immediate value, and "=" prefix for output operands.

The clobber list tells the compiler which resources the assembly modifies beyond the declared outputs. The "memory" clobber indicates the assembly accesses memory in ways the compiler cannot track.

Portable Alternatives

Before resorting to inline assembly, consider alternatives:

Compiler intrinsics: Many compilers provide intrinsic functions that generate specific instructions while remaining C code. These are more portable than inline assembly.

CMSIS functions: For ARM Cortex-M processors, CMSIS provides standardized functions for common operations like interrupt control and special register access.

Compiler builtins: GCC provides __builtin functions for many common operations, from bit counting to atomic operations.

Fixed-Width Integer Types

The stdint.h header provides integer types with guaranteed sizes: int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, and their 64-bit counterparts. These types are essential for embedded programming where data must match hardware register sizes or communication protocol requirements.

Using int or long for hardware-related code is risky because their sizes vary between platforms. A variable declared as int might be 16 bits on one compiler and 32 bits on another, causing subtle bugs when porting code.

Size and Alignment

Data structure layout affects both memory usage and access efficiency. Compilers typically align structure members to their natural boundaries, inserting padding between members to maintain alignment.

Understanding and controlling alignment matters for embedded systems:

Memory efficiency: Reordering structure members can reduce padding and decrease memory usage.

Hardware requirements: Some processors require aligned accesses; misaligned accesses cause exceptions or incorrect results.

Communication protocols: Data structures exchanged with external systems often require specific layouts that may not match the compiler's default packing.

The packed attribute forces structures to use no padding, essential for matching external data formats but potentially causing slower access or alignment faults on some processors.

Endianness

Endianness determines the byte order of multi-byte values in memory. Big-endian systems store the most significant byte at the lowest address; little-endian systems store the least significant byte first.

Endianness matters when interpreting data from external sources or writing data for external consumption. Network protocols typically use big-endian byte order (network byte order), while most modern processors are little-endian.

Converting between byte orders requires explicit code. Standard functions like htons() and htonl() convert between host and network byte order. For embedded systems without standard library support, explicit byte swapping is necessary.

Interrupt Service Routine Structure

Compiler-specific attributes mark functions as interrupt handlers, instructing the compiler to generate appropriate prologue and epilogue code:

void __attribute__((interrupt)) timer_isr(void) {
    // Clear interrupt flag
    TIMER_STATUS = TIMER_FLAG;
    
    // Handle interrupt
    timer_ticks++;
}

The exact syntax varies by compiler and architecture. ARM Cortex-M processors use a simpler model where interrupt handlers are ordinary functions; the hardware handles context saving.

Shared Data Protection

Variables shared between interrupt handlers and main code require careful handling:

Volatile declaration: Shared variables must be volatile to prevent the compiler from caching values across interrupt boundaries.

Atomic access: Operations on shared variables must be atomic to prevent corruption. Reading or writing a single byte is typically atomic; multi-byte operations may not be.

Critical sections: When atomic access is insufficient, disable interrupts around critical sections that access shared data:

uint32_t irq_state = disable_interrupts();
// Access shared data
critical_shared_variable++;
restore_interrupts(irq_state);

Interrupt Latency

Interrupt handlers should complete quickly to maintain system responsiveness. Long handlers increase interrupt latency for other interrupts and may cause missed events.

When significant processing is required in response to an interrupt, the handler should capture essential data, set a flag, and defer processing to main code. This deferred processing pattern keeps handlers short while ensuring events are handled.

Input Validation

Functions should validate inputs before using them. This is especially important for values from external sources such as communication interfaces or sensors:

bool set_speed(uint16_t rpm) {
    if (rpm > MAX_RPM) {
        // Log error, return failure, or clamp value
        return false;
    }
    motor_speed = rpm;
    return true;
}

Assert and Static Assert

The assert macro catches programming errors during development. In embedded systems, assert behavior typically differs from desktop systems; rather than printing a message and exiting, embedded asserts might trigger a breakpoint, log to flash, or reset the system.

Static assertions (static_assert in C11) catch errors at compile time, useful for verifying assumptions about type sizes, structure layouts, and configuration values.

Watchdog Integration

Watchdog timers reset the system if software fails to refresh them periodically. Effective watchdog usage requires refreshing only when the system is operating correctly, not merely when code executes:

void main_loop(void) {
    while (1) {
        if (check_sensors_valid() &&
            check_communication_active() &&
            check_state_machine_healthy()) {
            watchdog_refresh();
        }
        // Continue processing
    }
}

Error Handling Strategies

Embedded systems need clear strategies for handling errors. Options include returning error codes from functions, using global error flags, logging errors for later analysis, attempting recovery procedures, and failing safe when recovery is impossible.

The appropriate strategy depends on the application. Safety-critical systems may require immediate safe shutdown, while consumer devices might attempt recovery or graceful degradation.

Header File Organization

Header files should provide clean interfaces while hiding implementation details:

#ifndef MODULE_H
#define MODULE_H

#include <stdint.h>

// Public types
typedef struct {
    uint32_t value;
} module_handle_t;

// Public functions
void module_init(void);
module_handle_t *module_create(void);
void module_process(module_handle_t *handle);

#endif // MODULE_H

Include guards prevent multiple inclusion. Minimize dependencies by including only necessary headers. Declare, rather than define, in headers to avoid multiple definition errors.

Naming Conventions

Consistent naming improves code readability:

Functions: Use verb phrases describing actions: uart_send_byte(), timer_get_count().

Variables: Use descriptive names indicating purpose: bytes_received, motor_speed_rpm.

Constants: Use uppercase with underscores: MAX_BUFFER_SIZE, UART_BAUD_RATE.

Types: Use suffix conventions: _t for types, _e for enums, _s for structs.

Prefix module-specific identifiers with the module name to avoid name collisions in large projects.

Documentation

Embedded code documentation should explain the why, not just the what. Hardware interactions, timing requirements, and design decisions benefit from comments. Generated documentation tools like Doxygen work well for API documentation.

Unit Testing

Unit tests verify individual functions in isolation. Hardware abstraction layers enable testing business logic on development computers without target hardware. Mocking frameworks substitute test implementations for hardware-dependent code.

Static Analysis

Static analysis tools examine code without executing it, finding potential bugs, style violations, and security vulnerabilities. Tools like PC-lint, Polyspace, and open-source alternatives catch issues that might escape code review and testing.

On-Target Testing

Despite off-target testing value, testing on actual hardware remains essential. Hardware-in-the-loop testing combines real hardware with simulated environments, enabling comprehensive testing of hardware interactions.