Embedded Systems Series Part 1: Fundamentals & Architecture

Introduction: What Are Embedded Systems?

An embedded system is a computer system designed to perform dedicated functions within a larger mechanical or electronic system. Unlike general-purpose computers, embedded systems are optimized for specific tasks—from controlling your car's engine to managing a smart thermostat.

Embedded systems are everywhere: your microwave, washing machine, smartphone, car (with 50-100+ embedded controllers), medical devices, industrial robots, and the aircraft autopilot. The global embedded systems market exceeds $100 billion annually, making this one of the most important domains in computing.

Microcontroller vs Microprocessor

Understanding the difference between microcontrollers (MCUs) and microprocessors (MPUs) is fundamental to embedded systems design. Both are integrated circuits that execute instructions, but their architecture and use cases differ significantly.

Microcontroller Architecture

A microcontroller is a self-contained "system on a chip" (SoC) that integrates:

• CPU core: The processing unit (e.g., ARM Cortex-M, AVR, PIC)
• Flash memory: Non-volatile storage for program code (typically 16KB to 2MB)
• SRAM: Volatile memory for runtime data (typically 4KB to 512KB)
• Peripherals: GPIO, timers, UART, SPI, I2C, ADC, DAC
• Clock system: Internal oscillators and PLLs

Microprocessor Architecture

A microprocessor is primarily a CPU that requires external components:

• External RAM: DDR3/DDR4 memory modules (GBs of capacity)
• External storage: eMMC, SD card, NVMe for OS and data
• Support chips: Power management, memory controllers
• Higher performance: Complex instruction sets, caches, MMU

When to Use Which

Processor Architectures

Harvard vs Von Neumann Architecture

These two fundamental architectures define how processors access instructions and data.

Modified Harvard: Many modern processors use a hybrid approach—separate L1 caches for instructions and data (Harvard-style), but unified main memory (Von Neumann-style).

RISC vs CISC

Instruction set architecture (ISA) philosophies differ in how they approach CPU design:

ARM Architecture Overview

ARM (Advanced RISC Machines) dominates embedded systems. Understanding ARM's processor families is essential:

Memory Types in Embedded Systems

Flash Memory (Program Storage)

Flash memory stores your program code. It's non-volatile (retains data without power) and can be electrically erased and reprogrammed.

• NOR Flash: Execute-in-place (XIP), random access, used for code storage
• NAND Flash: Higher density, sequential access, used for mass storage
• Endurance: Limited write cycles (typically 10,000-100,000)
• Typical sizes: 16KB to 2MB in MCUs

// Flash memory is read-only at runtime
// Code executes directly from Flash (XIP)
const uint32_t lookup_table[] = {0, 1, 4, 9, 16, 25}; // Stored in Flash

SRAM (Data Memory)

Static RAM is fast, volatile memory used for runtime data—variables, stack, and heap.

• Speed: Single clock cycle access
• Volatility: Loses data when power is removed
• No refresh: Unlike DRAM, doesn't need periodic refresh
• Typical sizes: 4KB to 512KB in MCUs

// SRAM stores runtime variables
uint32_t counter = 0;        // Global variable in SRAM
uint8_t buffer[256];         // Array in SRAM

void function(void) {
    uint32_t local_var = 10; // Stack (also SRAM)
}

DRAM & DDR Memory in SoC Systems

While microcontrollers use on-chip SRAM (kilobytes), System-on-Chip (SoC) platforms like the TI AM335x, i.MX6, or Snapdragon processors use external DRAM (megabytes to gigabytes) as their main system memory. Understanding the DRAM family and DDR generations is essential for anyone working with embedded Linux, Android, or application-class embedded systems.

SRAM vs DRAM—The Fundamental Difference

• SRAM (Static RAM): Uses 6 transistors per bit. No refresh needed. Fast (single-cycle access), but large and expensive per bit. Used for caches, on-chip MCU memory, and register files. Typical embedded sizes: 4KB–512KB.
• DRAM (Dynamic RAM): Uses 1 transistor + 1 capacitor per bit. Needs periodic refresh (every 64 ms) because the capacitor charge leaks. Much higher density and lower cost per bit, but requires a dedicated DRAM controller to manage refresh cycles, timing, and command sequences. Typical embedded sizes: 128MB–8GB.

DDR Generations—From DDR2 to LPDDR5X

DDR (Double Data Rate) SDRAM transfers data on both the rising and falling edges of the clock signal, effectively doubling the bandwidth compared to single data rate (SDR) SDRAM. Each generation improves bandwidth, reduces voltage, and increases density:

// DDR3 timing parameters example (AM335x BeagleBone Black)
// These values are specific to the Kingston DDR3L chip used on BBB
// From: board/ti/am335x/board.c in U-Boot source

#include <asm/arch/ddr_defs.h>

const struct ddr_data ddr3_data = {
    .datardsratio0    = MT41K256M16HA125E_RD_DQS,
    .datawdsratio0    = MT41K256M16HA125E_WR_DQS,
    .datafwsratio0    = MT41K256M16HA125E_PHY_FIFO_WE,
    .datawrsratio0    = MT41K256M16HA125E_PHY_WR_DATA,
};

const struct cmd_control ddr3_cmd_ctrl_data = {
    .cmd0csratio  = MT41K256M16HA125E_RATIO,
    .cmd0iclkout  = MT41K256M16HA125E_INVERT_CLKOUT,
    .cmd1csratio  = MT41K256M16HA125E_RATIO,
    .cmd1iclkout  = MT41K256M16HA125E_INVERT_CLKOUT,
    .cmd2csratio  = MT41K256M16HA125E_RATIO,
    .cmd2iclkout  = MT41K256M16HA125E_INVERT_CLKOUT,
};

const struct emif_regs ddr3_emif_reg_data = {
    .sdram_config         = MT41K256M16HA125E_EMIF_SDCFG,
    .ref_ctrl             = MT41K256M16HA125E_EMIF_SDREF,
    .sdram_tim1           = MT41K256M16HA125E_EMIF_TIM1,
    .sdram_tim2           = MT41K256M16HA125E_EMIF_TIM2,
    .sdram_tim3           = MT41K256M16HA125E_EMIF_TIM3,
    .zq_config            = MT41K256M16HA125E_ZQ_CFG,
    .emif_ddr_phy_ctlr_1  = MT41K256M16HA125E_EMIF_READ_LATENCY,
};

EEPROM (Non-Volatile Data)

Electrically Erasable Programmable ROM stores configuration data that must survive power cycles. Unlike Flash memory which must be erased in large sectors (typically 4KB–128KB), EEPROM allows byte-level erase and write operations, making it ideal for storing small configuration values that change frequently during the device’s lifetime.

• Byte-erasable: Can erase and rewrite individual bytes without affecting neighboring data
• Slower writes: Typically 3–10 ms per byte (vs nanosecond reads)
• Higher endurance: Often 1 million write cycles (vs 10K–100K for Flash)
• Small capacity: Typically 256 bytes to 64KB in MCUs
• Asymmetric speed: Reads are fast (nanoseconds), but writes require an internal charge pump and are orders of magnitude slower
• Use cases: Calibration data, user settings, device IDs, boot configuration, error logs, counters

// Writing to internal EEPROM (STM32L0/L1 series)
#include "stm32l0xx_hal.h"

#define EEPROM_BASE  0x08080000
#define EEPROM_END   0x080807FF  // 2KB EEPROM on STM32L053

void eeprom_write_halfword(uint32_t address, uint16_t value) {
    HAL_FLASHEx_DATAEEPROM_Unlock();
    HAL_FLASHEx_DATAEEPROM_Program(
        FLASH_TYPEPROGRAMDATA_HALFWORD,
        EEPROM_BASE + address,
        value
    );
    HAL_FLASHEx_DATAEEPROM_Lock();
}

// Reading from internal EEPROM (direct memory-mapped access)
#include <stdint.h>

#define EEPROM_BASE  0x08080000

uint16_t eeprom_read_halfword(uint32_t address) {
    // EEPROM is memory-mapped — read like any memory location
    return *(__IO uint16_t *)(EEPROM_BASE + address);
}

uint8_t eeprom_read_byte(uint32_t address) {
    return *(__IO uint8_t *)(EEPROM_BASE + address);
}

// Usage: restore calibration after power cycle
uint16_t saved_cal = eeprom_read_halfword(0x0000);
uint8_t  device_id = eeprom_read_byte(0x0010);

Internal vs External EEPROM

EEPROM comes in two forms: internal EEPROM built into the MCU die, and external EEPROM chips connected via I2C or SPI. The choice depends on capacity requirements, MCU availability, and system constraints.

// Reading from external I2C EEPROM (AT24C256, 32KB)
// Using STM32 HAL — each snippet is self-contained
#include "stm32f4xx_hal.h"

#define EEPROM_I2C_ADDR  0xA0  // 7-bit: 0x50 left-shifted
#define EEPROM_PAGE_SIZE 64    // AT24C256 page size

extern I2C_HandleTypeDef hi2c1;

// Read N bytes from external EEPROM
HAL_StatusTypeDef eeprom_i2c_read(uint16_t mem_addr, uint8_t *data, uint16_t len) {
    return HAL_I2C_Mem_Read(
        &hi2c1,
        EEPROM_I2C_ADDR,
        mem_addr,
        I2C_MEMADD_SIZE_16BIT,  // AT24C256 uses 16-bit addresses
        data,
        len,
        HAL_MAX_DELAY
    );
}

// Writing to external I2C EEPROM (AT24C256)
// Must respect page boundaries and write cycle time
#include "stm32f4xx_hal.h"

#define EEPROM_I2C_ADDR  0xA0
#define EEPROM_PAGE_SIZE 64
#define EEPROM_WRITE_TIME 5  // 5ms max write cycle time

extern I2C_HandleTypeDef hi2c1;

// Write a single page (up to 64 bytes) — must not cross page boundary
HAL_StatusTypeDef eeprom_i2c_write_page(uint16_t mem_addr, uint8_t *data, uint16_t len) {
    HAL_StatusTypeDef status;

    status = HAL_I2C_Mem_Write(
        &hi2c1,
        EEPROM_I2C_ADDR,
        mem_addr,
        I2C_MEMADD_SIZE_16BIT,
        data,
        len,
        HAL_MAX_DELAY
    );

    // Wait for write cycle to complete
    HAL_Delay(EEPROM_WRITE_TIME);
    return status;
}

// Write arbitrary length — handles page boundary crossing
HAL_StatusTypeDef eeprom_i2c_write(uint16_t addr, uint8_t *data, uint16_t len) {
    while (len > 0) {
        uint16_t page_offset = addr % EEPROM_PAGE_SIZE;
        uint16_t bytes_in_page = EEPROM_PAGE_SIZE - page_offset;
        uint16_t chunk = (len < bytes_in_page) ? len : bytes_in_page;

        if (eeprom_i2c_write_page(addr, data, chunk) != HAL_OK)
            return HAL_ERROR;

        addr += chunk;
        data += chunk;
        len  -= chunk;
    }
    return HAL_OK;
}

EEPROM Wear-Leveling & Best Practices

EEPROM cells degrade with each write cycle. Wear leveling distributes writes across multiple addresses to extend the effective lifetime of the memory. This is especially critical for data that updates frequently—counters, timestamps, and sensor logs.

• Round-robin writing: Rotate writes across N slots—multiplies effective endurance by N
• Write-back caching: Accumulate changes in SRAM and flush to EEPROM periodically (e.g., on shutdown or every N minutes)
• Dirty flag pattern: Use a single status byte to track which EEPROM block holds the latest data
• CRC/checksum validation: Store a CRC alongside data to detect corruption from incomplete writes or cell degradation

// Simple round-robin wear-leveling for a 16-bit counter
// Spreads writes across 64 EEPROM slots to extend lifetime 64x
#include <stdint.h>
#include <string.h>

#define EEPROM_BASE       0x08080000
#define SLOT_COUNT        64
#define SLOT_SIZE         4   // 2 bytes data + 2 bytes sequence number
#define WEAR_LEVEL_START  0x0100  // Offset in EEPROM for this data

typedef struct {
    uint16_t value;
    uint16_t seq_num;  // Incrementing sequence to find latest
} eeprom_slot_t;

// Find the slot with the highest sequence number (latest write)
uint8_t find_latest_slot(void) {
    uint16_t max_seq = 0;
    uint8_t  latest  = 0;

    for (uint8_t i = 0; i < SLOT_COUNT; i++) {
        uint32_t addr = EEPROM_BASE + WEAR_LEVEL_START + (i * SLOT_SIZE);
        eeprom_slot_t slot;
        memcpy(&slot, (void *)addr, sizeof(slot));

        if (slot.seq_num >= max_seq && slot.seq_num != 0xFFFF) {
            max_seq = slot.seq_num;
            latest  = i;
        }
    }
    return latest;
}

// Write new value to the next slot in rotation
void wear_level_write(uint16_t new_value) {
    uint8_t latest = find_latest_slot();
    uint32_t addr  = EEPROM_BASE + WEAR_LEVEL_START + (latest * SLOT_SIZE);
    eeprom_slot_t old_slot;
    memcpy(&old_slot, (void *)addr, sizeof(old_slot));

    uint8_t next = (latest + 1) % SLOT_COUNT;
    eeprom_slot_t new_slot = {
        .value   = new_value,
        .seq_num = old_slot.seq_num + 1
    };

    uint32_t new_addr = EEPROM_BASE + WEAR_LEVEL_START + (next * SLOT_SIZE);
    // Write new_slot to new_addr using HAL or direct write
}

Flash-Emulated EEPROM

Many modern MCUs (e.g., STM32F4, STM32G4, ESP32) don’t include dedicated EEPROM. Instead, they use a software technique called Flash-emulated EEPROM (or EEPROM emulation) that reserves one or two Flash sectors to simulate byte-level EEPROM operations on top of sector-erasable Flash.

// Flash-emulated EEPROM using STM32 EEPROM Emulation library (AN4894)
// Requires linking ST's eeprom emulation middleware
#include "eeprom_emul.h"

#define VIRT_ADDR_CALIBRATION  0x0001
#define VIRT_ADDR_DEVICE_ID    0x0002
#define VIRT_ADDR_BOOT_COUNT   0x0003

void eeprom_emul_example(void) {
    // Initialize emulation (formats Flash pages on first run)
    EE_Status status = EE_Init(EE_FORCED_ERASE);
    if (status != EE_OK) {
        // Handle initialization error
        return;
    }

    // Write a virtual variable
    uint16_t cal_value = 0x1234;
    EE_WriteVariable16bits(VIRT_ADDR_CALIBRATION, cal_value);

    // Read it back
    uint16_t read_value = 0;
    EE_ReadVariable16bits(VIRT_ADDR_CALIBRATION, &read_value);
    // read_value == 0x1234

    // Increment boot counter
    uint16_t boot_count = 0;
    EE_ReadVariable16bits(VIRT_ADDR_BOOT_COUNT, &boot_count);
    EE_WriteVariable16bits(VIRT_ADDR_BOOT_COUNT, boot_count + 1);
}

Memory Map & Addressing

A memory map defines how the processor sees all addressable resources—memory, peripherals, and system registers.

Address Range        | Region
---------------------|---------------------------
0x00000000-0x1FFFFFFF | Code (Flash)
0x20000000-0x3FFFFFFF | SRAM
0x40000000-0x5FFFFFFF | Peripherals
0x60000000-0x9FFFFFFF | External RAM
0xA0000000-0xDFFFFFFF | External Device
0xE0000000-0xE00FFFFF | Private Peripheral Bus (NVIC, SysTick)
0xE0100000-0xFFFFFFFF | Vendor-specific

Interrupts & Exception Handling

Interrupt Basics

Interrupts allow the processor to respond to events asynchronously—without continuously polling for them.

NVIC (Nested Vectored Interrupt Controller)

ARM Cortex-M processors include the NVIC—a powerful interrupt controller with these features:

• Vectored: Each interrupt has a dedicated handler address
• Nested: Higher priority interrupts can preempt lower priority ones
• Programmable priorities: 0-255 priority levels (lower = higher priority)
• Low latency: Tail-chaining and late arrival optimization

// Enable and configure NVIC interrupt
void setup_interrupt(void) {
    // Set priority (0 = highest, 15 = lowest for 4-bit priority)
    NVIC_SetPriority(EXTI0_IRQn, 2);
    
    // Enable the interrupt
    NVIC_EnableIRQ(EXTI0_IRQn);
}

// Interrupt Service Routine
void EXTI0_IRQHandler(void) {
    // Clear the interrupt flag FIRST
    EXTI->PR |= EXTI_PR_PR0;
    
    // Handle the interrupt
    toggle_led();
}

ISR Design Best Practices

// Good ISR pattern
volatile uint8_t data_ready = 0;
volatile uint8_t rx_buffer[64];

void USART1_IRQHandler(void) {
    if (USART1->SR & USART_SR_RXNE) {
        rx_buffer[rx_index++] = USART1->DR; // Read clears flag
        data_ready = 1; // Signal main loop
    }
}

// Main loop processes data
int main(void) {
    while (1) {
        if (data_ready) {
            process_data(rx_buffer);
            data_ready = 0;
        }
    }
}

Real-Time Constraints

Hard vs Soft Real-Time

Real-time systems must respond to events within specified time constraints. The consequences of missing deadlines distinguish two categories:

Timing Analysis

Key timing metrics for embedded systems:

• Interrupt latency: Time from interrupt signal to ISR start (typically 12-20 cycles on Cortex-M)
• Response time: Total time from event to system response
• Jitter: Variation in response time
• WCET (Worst-Case Execution Time): Maximum time a code section can take

// Measuring execution time
#include "stm32f4xx.h"

void measure_timing(void) {
    // Enable DWT cycle counter
    CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
    DWT->CYCCNT = 0;
    DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;
    
    uint32_t start = DWT->CYCCNT;
    
    // Code to measure
    critical_function();
    
    uint32_t cycles = DWT->CYCCNT - start;
    float time_us = (float)cycles / (SystemCoreClock / 1000000);
}

Determinism in Embedded Systems

Deterministic behavior means the system's response time is predictable and bounded.

Development Tools & Workflow

Toolchains & Cross-Compilation

Embedded development uses cross-compilation—compiling on one platform (host PC) for another (target MCU).

# Basic compilation command
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 \
    -c main.c -o main.o

# Linking with linker script
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb \
    -T linker.ld -o firmware.elf main.o startup.o

# Convert to binary for flashing
arm-none-eabi-objcopy -O binary firmware.elf firmware.bin

# Check memory usage
arm-none-eabi-size firmware.elf

Debuggers & JTAG/SWD

Hardware debuggers connect your PC to the target MCU:

• JTAG: Older standard, 4-5 wire, supports multiple devices in chain
• SWD (Serial Wire Debug): ARM-specific, 2-wire, faster for single target

IDEs for Embedded Development

Bare-Metal Programming Basics

Bare-metal programming means writing code that runs directly on hardware without an operating system. Your code has complete control—and complete responsibility.

// Minimal bare-metal program structure
#include "stm32f4xx.h"

// Vector table (defined in startup code)
// Reset handler is the entry point

int main(void) {
    // 1. Initialize system clock
    SystemInit();
    
    // 2. Enable peripheral clocks
    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
    
    // 3. Configure peripherals
    GPIOA->MODER |= GPIO_MODER_MODER5_0; // PA5 as output
    
    // 4. Main loop
    while (1) {
        GPIOA->ODR ^= GPIO_ODR_OD5; // Toggle LED
        for (volatile int i = 0; i < 100000; i++); // Delay
    }
}

Conclusion & What's Next

You've now built a solid foundation in embedded systems fundamentals. You understand the key differences between microcontrollers and microprocessors, how Harvard and Von Neumann architectures work, the memory types available in MCUs, interrupt handling patterns, and real-time system requirements.

In Part 2, we'll dive deep into STM32 and ARM Cortex-M development—configuring peripherals, using HAL libraries, and building real embedded applications.