Types Of Operating Systems - Learning Module

Loading content...

0/227

Embedded Operating Systems

Computing in the Physical World

Every device around you—your thermostat, your car's dashboard, your washing machine, your fitness tracker, your smart doorbell—contains a computer. Not a computer like your laptop, with gigabytes of RAM and terabytes of storage, but a computer nonetheless: a processor executing code, managing inputs, producing outputs.

These are embedded systems—computers embedded within larger products, invisible to users, dedicated to specific functions. And many of them run Embedded Operating Systems—specialized software that mediates between hardware and application code, but under constraints that desktop OS designers never face.

The embedded world operates by different rules. Where desktop systems have gigabytes, embedded systems may have kilobytes. Where servers draw hundreds of watts, embedded devices run on button batteries for years. Where Linux boots in seconds, embedded systems must respond in microseconds. Understanding embedded OS requires understanding these physical constraints and the architectural choices they necessitate.

Learning Objectives

By the end of this page, you will understand:

• The defining characteristics and constraints of embedded systems • The spectrum from bare-metal programming to full RTOS • Memory management in severely constrained environments • Power-aware design and energy harvesting considerations • Hardware abstraction layers and board support packages • The diversity of embedded applications: IoT, automotive, industrial, consumer

What Makes a System 'Embedded'?

The term 'embedded system' covers an enormous range, from 8-bit microcontrollers with 2KB RAM to powerful multi-core application processors. What unifies them is not any specific hardware capability but a set of shared characteristics:

Defining Characteristics

•Dedicated Function — Unlike general-purpose computers, embedded systems perform specific, predefined tasks. A microwave controller doesn't run spreadsheets; it controls magnetron timing.
•Integration Within Larger Systems — The computer is a component, not the product. Users interact with the product (car, appliance, device), not the embedded computer directly.
•Real-world Interaction — Embedded systems interact with the physical world through sensors, actuators, displays, and communication interfaces. They're reactive to physical events.
•Resource Constraints — Memory, processing power, storage, and energy are typically limited. Designs must operate within strict physical and cost budgets.
•Reliability Requirements — Many embedded systems operate unattended for years. A thermostat can't require daily reboots; a pacemaker can't crash.
•Cost Sensitivity — High-volume consumer products drive extreme cost optimization. Saving $0.10 per unit matters when manufacturing millions.

Embedded Systems Spectrum
Category	Resources	OS Approach	Examples
Tiny Microcontroller	2-32 KB RAM, 8-16 bit	Bare metal or minimal RTOS	TV remote, simple sensors
Small Microcontroller	32-256 KB RAM, 32-bit	RTOS (FreeRTOS, Zephyr)	Fitness trackers, smart locks
Resource-moderate	256 KB - 16 MB RAM	RTOS or Embedded Linux	Industrial controllers, infotainment
Application Processor	64 MB - 4 GB RAM	Full Linux/Android	Smartphones, smart TVs, cameras
High-end Embedded	Multi-GB RAM, multi-core	Full OS with RT extensions	Autonomous vehicles, medical imaging

Embedded vs. General-Purpose: The Design Philosophy Difference

General-purpose operating systems (Windows, Linux, macOS) optimize for:

Supporting arbitrary, unknown applications
Maximizing hardware utilization
User experience and interactivity
Flexibility and extensibility

Embedded operating systems optimize for:

Minimal footprint (use only what's needed)
Deterministic, predictable behavior
Long-term reliability without maintenance
Power efficiency (battery life, thermal limits)
Fast startup (instant-on for appliances)
Hard real-time response (where required)

These differing priorities lead to fundamentally different architectural choices.

The 10× Rule of Embedded

A rule of thumb for embedded development:

• If your target has 256 KB RAM, design for 25 KB • If you need 80% CPU utilization, target 8% • If battery must last 1 year, design for 10 years

Embedded margins must account for manufacturing variation, environmental conditions, edge cases, and future firmware updates. The dramatic-seeming margins enable robust products.

Bare-Metal Programming: No OS at All

Many embedded systems don't run an operating system at all. Bare-metal programming means application code runs directly on hardware, with no OS layer between. This approach remains common for the smallest, most resource-constrained systems.

When Bare-Metal Makes Sense:

Extremely limited memory (< 8 KB RAM)
Hard real-time with minimal jitter requirements
Maximum control over timing and peripherals
Simplest possible system (fewer failure modes)
Cost optimization (no OS licensing, smaller flash)

Bare-Metal Application (Super Loop Pattern)
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// Classic bare-metal architecture: Super Loop
// No OS, no task switching, just one infinite loop
 
#include <stdint.h>
#include "hardware.h"
 
// Global state
volatile uint8_t button_pressed = 0;
volatile uint16_t sensor_value = 0;
volatile uint32_t system_tick = 0;
 
// Interrupt Service Routine - Timer (1ms)
void Timer_ISR(void) {
    system_tick++;
    // Set flags for periodic tasks
}
 
// Interrupt Service Routine - Button
void Button_ISR(void) {
    button_pressed = 1;
}
 
// Main application
int main(void) {
    // Initialize hardware
    Hardware_Init();
    Timer_Init(1000);  // 1ms tick
    ADC_Init();
    UART_Init(9600);
    
    // Enable interrupts
    Interrupts_Enable();
    
    // Super loop - runs forever
    while (1) {
        // Task 1: Sample sensor (every 100ms)
        if ((system_tick % 100) == 0) {
            sensor_value = ADC_Read(SENSOR_CHANNEL);
        }
        
        // Task 2: Send data (every 1000ms)
        if ((system_tick % 1000) == 0) {
            UART_SendValue(sensor_value);
        }
        
        // Task 3: Handle button (event-driven)
        if (button_pressed) {
            button_pressed = 0;
            LED_Toggle();
        }
        
        // Task 4: Sleep if possible (power saving)
        Enter_Low_Power_Until_Interrupt();
    }
    
    return 0;  // Never reached
}

Super Loop Advantages:

Minimal overhead: No scheduler, no context switching
Fully deterministic: Timing exactly controlled
Small footprint: Often < 2 KB total code
Easy to debug: One execution path to trace

Super Loop Limitations:

Blocking: One slow task blocks everything
Inflexible: Adding tasks requires restructuring
Manual timing: Developer manages all time-slicing
No prioritization: All tasks equal regardless of urgency

When to Evolve Beyond Bare Metal

Consider adopting an RTOS when:

• Multiple tasks with different priorities • Task blocking (waiting for events, I/O) is common • Code modularity and maintainability matter • Timing requirements require prioritized preemption • Team size is growing (RTOS APIs standardize design)

The overhead of a small RTOS (2-10 KB) is often worthwhile when it enables cleaner architecture and maintainable code.

Embedded RTOS Architecture

When bare-metal becomes unwieldy, a minimal Real-Time Operating System provides task management, scheduling, and synchronization without the overhead of a full OS.

Typical Embedded RTOS Components:

Converting Mermaid diagram...

Core RTOS Components

•Task/Thread Management — Create, delete, suspend, resume tasks. Each task has its own stack and context. Priority-based preemptive scheduling standard.
•Scheduler — Determines which task runs next. Fixed-priority preemptive common. Round-robin among equal priorities. O(1) scheduling essential for determinism.
•Inter-Task Communication — Queues (message passing), semaphores (signaling), mutexes (mutual exclusion). Must be ISR-safe (callable from interrupt context).
•Timer Services — Software timers built on hardware timer. Callbacks, delayed execution, periodic tasks. Resolution typically 1-10 ms.
•Memory Management — Static pools or minimal heap. No malloc() in critical sections. Fragmentation management crucial in long-running systems.
•Interrupt Management — Prioritized, nested interrupts. Deferred processing (bottom halves) for complex handling outside ISR.

FreeRTOS Task Example
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
#include "FreeRTOS.h"
#include "task.h"
#include "queue.h"
#include "semphr.h"
 
// Queue handle for sensor data
QueueHandle_t xSensorQueue;
 
// Mutex for shared resource
SemaphoreHandle_t xUARTMutex;
 
// High-priority task: Sensor sampling
void vSensorTask(void *pvParameters) {
    uint16_t sensorReading;
    TickType_t xLastWakeTime = xTaskGetTickCount();
    
    for (;;) {
        // Sample sensor
        sensorReading = ADC_Read(0);
        
        // Send to processing queue (non-blocking)
        xQueueSend(xSensorQueue, &sensorReading, 0);
        
        // Wait until next period (exactly 10ms)
        vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(10));
    }
}
 
// Low-priority task: Serial output
void vOutputTask(void *pvParameters) {
    uint16_t receivedValue;
    
    for (;;) {
        // Wait for data from queue (blocking)
        if (xQueueReceive(xSensorQueue, &receivedValue, 
                          portMAX_DELAY) == pdTRUE) {
            
            // Protect UART access
            if (xSemaphoreTake(xUARTMutex, 
                               pdMS_TO_TICKS(100)) == pdTRUE) {
                UART_Print("Sensor: %d\n", receivedValue);
                xSemaphoreGive(xUARTMutex);
            }
        }
    }
}
 
int main(void) {
    Hardware_Init();
    
    // Create IPC primitives
    xSensorQueue = xQueueCreate(10, sizeof(uint16_t));
    xUARTMutex = xSemaphoreCreateMutex();
    
    // Create tasks with priorities
    xTaskCreate(vSensorTask, "Sensor", 128, NULL, 3, NULL);
    xTaskCreate(vOutputTask, "Output", 256, NULL, 1, NULL);
    
    // Start scheduler (never returns)
    vTaskStartScheduler();
    
    return 0;
}

RTOS Memory Footprint

Typical embedded RTOS sizes:

• FreeRTOS kernel: 4-9 KB ROM, 250 bytes RAM per task • Zephyr minimal kernel: 8 KB ROM, 2-5 KB RAM • ThreadX: 2 KB ROM, 200 bytes per thread • RIOT: 1.5 KB ROM, 0.5 KB RAM

Compare to Linux minimal kernel: 4 MB ROM, 16 MB RAM minimum. Embedded RTOS can run on hardware that couldn't boot Linux.

Memory Management in Constrained Environments

Memory management in embedded systems differs fundamentally from desktop environments. With kilobytes instead of gigabytes, every byte matters, and dynamic allocation becomes dangerous.

The Problem with malloc():

+--------+--------+--------+--------+--------+--------+
|  Obj1  |  free  |  Obj2  |  free  |  Obj3  |  free  |
+--------+--------+--------+--------+--------+--------+
         ^fragmentation^      ^fragmentation^

// After many alloc/free cycles:
// 500 bytes free total, but max contiguous = 50 bytes
// Cannot allocate 100-byte object despite 'enough' memory

Fragmentation in long-running embedded systems eventually causes allocation failures, system instability, or crashes—unacceptable for devices running for years.

Embedded Memory Strategies:

Static Allocation: No Runtime Allocation

All memory is allocated at compile time. No malloc, no free, no fragmentation.

// All buffers are static, sized at compile time
static uint8_t uart_rx_buffer[256];
static SensorData sensor_history[100];
static TaskData task_data[MAX_TASKS];

// Stack sizes fixed at task creation
static StackType_t sensor_stack[256];
static StackType_t output_stack[512];

Advantages:

Zero fragmentation (no dynamic allocation)
Deterministic: Linker verifies memory fit
No runtime allocation failures
Easier to analyze for safety certification

Disadvantages:

Must know worst-case sizes at design time
Memory 'wasted' if not always used
Less flexible for variable workloads

When To Use:

Safety-critical systems (mandatory for some certifications)
Most resource-constrained systems
When reliability trumps flexibility

Memory Corruption: The Silent Killer

Embedded systems lack desktop memory protection. In most small RTOS:

• All tasks share one address space • Stack overflows corrupt other task stacks or global data • Dangling pointers cause insidious bugs • Hardware memory protection (MPU) may exist but is often disabled for simplicity

Without virtual memory protection, memory bugs are harder to detect and often manifest as seemingly unrelated failures. Defensive coding, stack overflow detection, and thorough testing are essential.

Power-Aware Design: Energy as a Primary Constraint

For many embedded systems, energy is the ultimate limiting resource. A sensor node on a coin cell battery must operate for years without maintenance. A wearable must last days between charges. Power-aware design permeates every level of the system.

Power Consumption Hierarchy:

Typical Power States (ARM Cortex-M4 @ 3V)
State	Current Draw	Wake Time	Use Case
Full Run	10-30 mA	—	Active computation
Idle/Sleep	1-5 mA	< 10 µs	Waiting for interrupt
Deep Sleep	5-50 µA	< 100 µs	Peripherals off, RAM retained
Stop	1-10 µA	< 1 ms	Minimal, RTC running
Standby/Off	100 nA - 1 µA	< 10 ms	Wake on RTC or pin

Power Management Strategies:

Embedded Power Optimization

•Sleep When Idle — Any moment without work should be spent in lowest-power state possible. Tickless idle eliminates periodic timer wakes.
•Clock Gating — Disable clocks to unused peripherals. A peripheral with no clock draws nearly no power.
•Voltage Scaling — Lower voltage = quadratic power reduction. Run at minimum voltage for current clock speed.
•Frequency Scaling — Lower frequency for lower power when full speed isn't needed (DVFS: Dynamic Voltage and Frequency Scaling).
•Peripheral Duty Cycling — Power on sensors only when sampling. A GPS that runs 1 second per minute uses 1/60th the energy.
•Wake-on-Event — Use low-power peripherals to wake system only when meaningful events occur. Wake on motion, not on timer.
•Efficient Algorithms — O(n) vs O(n²) isn't just about speed—it's about energy. Less computation = less power.

FreeRTOS Tickless Idle
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// FreeRTOS configuration for tickless idle
// configUSE_TICKLESS_IDLE = 1 in FreeRTOSConfig.h
 
// RTOS calculates time until next scheduled event
// Instead of waking every 1ms tick, sleeps until needed
 
// Power impact:
// With 1ms tick:    Wake 1000 times/second
// Tickless idle:    Wake only when task ready
 
// Custom implementation for low-power mode
void vPortSuppressTicksAndSleep(TickType_t xExpectedIdleTime) {
    // Calculate actual microseconds to sleep
    uint32_t sleep_us = xExpectedIdleTime * (1000000 / configTICK_RATE_HZ);
    
    // Configure low-power timer to wake us
    LPTimer_SetWakeup(sleep_us);
    
    // Disable systick interrupt
    SysTick->CTRL &= ~SysTick_CTRL_ENABLE_Msk;
    
    // Enter deep sleep mode
    __WFI();  // Wait For Interrupt
    
    // Woken up - calculate actual sleep time
    uint32_t actual_sleep = LPTimer_GetElapsed();
    TickType_t ticks_slept = actual_sleep / (1000000 / configTICK_RATE_HZ);
    
    // Update tick count
    vTaskStepTick(ticks_slept);
    
    // Re-enable systick
    SysTick->CTRL |= SysTick_CTRL_ENABLE_Msk;
}

Energy Budgeting

For battery-powered systems, create an energy budget:

CR2032 coin cell: 220 mAh capacity
Target life: 5 years = 43,800 hours
Average current budget: 220 / 43800 = 5 µA

Breakdown:
  Deep sleep (99.9%): 1 µA × 0.999 = 1.0 µA
  Active (0.1%): 20 mA × 0.001 = 20 µA
  Total average: 21 µA > budget! Need optimization

Every active millisecond costs 1000× more energy than sleep. The design goal is maximizing sleep time.

Hardware Abstraction and Portability

Embedded systems span enormous hardware diversity: different CPU architectures, peripheral sets, memory maps, and interrupt systems. Hardware Abstraction Layers (HAL) isolate application code from hardware specifics, enabling portability and maintainability.

Abstraction Layers in Embedded Systems:

┌─────────────────────────────────────────────────────────────┐
│                    Application Code                          │
│                (Business logic, portable)                    │
├─────────────────────────────────────────────────────────────┤
│                    Middleware                                │
│        (Networking, filesystems, USB, GUI)                  │
├─────────────────────────────────────────────────────────────┤
│                    RTOS Abstraction                          │
│        (Task, timer, IPC APIs - portable)                   │
├─────────────────────────────────────────────────────────────┤
│               Hardware Abstraction Layer (HAL)               │
│    (GPIO, UART, SPI, I2C, ADC, Timers - chip-specific)      │
├─────────────────────────────────────────────────────────────┤
│              Board Support Package (BSP)                     │
│    (Pinout, clock config, memory map - board-specific)       │
├─────────────────────────────────────────────────────────────┤
│                      Hardware                                │
│           (Specific MCU, peripherals, board)                 │
└─────────────────────────────────────────────────────────────┘

Common Embedded HAL Standards
HAL/Standard	Provider	Target	Characteristics
CMSIS	ARM	Cortex-M	Standard core access, DSP, RTOS interface
STM32 HAL	STMicroelectronics	STM32 family	Comprehensive peripheral abstraction
Zephyr Devicetree	Linux Foundation	Zephyr OS	Hardware description, driver binding
Arduino API	Arduino	Many platforms	Simplicity-focused, beginner-friendly
Mbed OS HAL	ARM	Mbed-enabled boards	Object-oriented C++ APIs
ESP-IDF	Espressif	ESP32 family	WiFi/BLE native support

Hardware Abstraction Example
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// Application code uses abstract HAL interface
// Works on any platform implementing the HAL
 
#include "hal_gpio.h"
#include "hal_uart.h"
 
void application_init(void) {
    // Abstract: "configure LED pin as output"
    // HAL translates to platform-specific calls
    HAL_GPIO_SetMode(LED_PIN, GPIO_MODE_OUTPUT);
    
    // Abstract: "initialize UART at 115200"
    HAL_UART_Init(UART_DEBUG, 115200);
}
 
void application_loop(void) {
    HAL_GPIO_Toggle(LED_PIN);
    HAL_UART_Print(UART_DEBUG, "Hello from %s\n", 
                   BSP_GetPlatformName());
    HAL_Delay_ms(1000);
}
 
// Platform-specific implementation (e.g., STM32)
// hal_gpio_stm32.c
void HAL_GPIO_Toggle(uint32_t pin) {
    HAL_GPIO_TogglePin(pin_to_port(pin), pin_to_bit(pin));
}
 
// Different implementation for different platform
// hal_gpio_esp32.c  
void HAL_GPIO_Toggle(uint32_t pin) {
    gpio_set_level(pin, !gpio_get_level(pin));
}

The Abstraction Trade-off

HAL provides portability but adds overhead:

• Function call layers add latency • Generic interfaces may not expose hardware-specific optimizations • More code = larger flash footprint

For many applications, this trade-off is worthwhile. For ultra-constrained systems or timing-critical code, direct register access may be necessary for hot paths while HAL covers the rest.

Embedded Systems in the Real World

Embedded systems span virtually every industry. Each domain brings unique requirements shaping OS and architecture choices.

Internet of Things and Wearable Devices

Characteristics:

Battery-powered, multi-year life required
Wireless connectivity (BLE, WiFi, LoRa, NB-IoT)
Small form factors, tight cost constraints
Over-the-air firmware updates
Security increasingly critical

Typical OS Choices:

FreeRTOS (especially with AWS IoT integration)
Zephyr (excellent connectivity support)
RIOT (research-focused, many protocols)
Mbed OS (ARM-optimized IoT stack)
Nordic SoftDevice (BLE-specific)

Examples:

Smart home sensors and actuators
Fitness trackers and smartwatches
Agricultural monitoring systems
Industrial asset trackers
Smart meters and grid devices

Key Challenges:

Power efficiency: Must sleep 99%+ of time
Security: OTA updates, secure boot, encryption
Connectivity reliability in harsh RF environments
Scalability: Fleet of thousands of devices

Summary: Embedded Operating Systems

We've explored the world of embedded operating systems—a vast domain where computing meets the physical world under constraints that reshape every architectural decision.

Key Takeaways

•Embedded systems prioritize constraint optimization — Unlike general-purpose systems maximizing flexibility, embedded systems optimize for the specific: minimal footprint, power efficiency, determinism, reliability.
•The spectrum spans bare-metal to full Linux — From 2KB super-loop firmware to Android running on automotive head units, 'embedded' covers enormous diversity, each with appropriate OS approaches.
•Memory management requires discipline — Without virtual memory protection and with fragmentation risks, embedded systems favor static allocation, memory pools, and startup-only dynamic allocation.
•Power awareness is non-negotiable — For battery systems, every mA matters. Tickless idle, sleep modes, peripheral duty-cycling, and efficient algorithms are essential, not optional.
•Hardware abstraction enables portability — HAL, BSP, and standards like CMSIS isolate application code from hardware specifics, enabling code reuse and maintainability.
•Every industry relies on embedded systems — From pacemakers to power grids, from wearables to wind turbines, embedded computing is infrastructure for modern life.

Module Conclusion: Types of Operating Systems

We have completed our exploration of operating system types:

Batch OS — Maximizing throughput through automated job sequencing, where human interaction yields to automation
Multi-tasking/Time-sharing — Bringing interactivity through rapid context switching, creating illusions of dedicated access
Real-time OS — Guaranteeing deterministic timing for safety-critical applications where deadlines are inviolable
Distributed OS — Coordinating multiple machines as unified systems, grappling with impossibility results and consistency trade-offs
Embedded OS — Operating under physical constraints of power, size, and cost, integrating computing into the fabric of everyday objects

These categories aren't mutually exclusive. Modern automotive systems blend real-time (braking), embedded (resource constraints), and distributed (vehicle networks) characteristics. Cloud platforms combine time-sharing (multi-tenancy), batch (data processing), and distributed (cluster management).

Understanding each paradigm equips you to recognize the design patterns and trade-offs that shape every operating system you encounter.

Module Complete

You have completed Module 3: Types of Operating Systems. You now understand the full spectrum from batch processing origins through time-sharing interactivity, real-time determinism, distributed coordination, and embedded constraints. Each paradigm represents distinct design philosophies with lessons that transcend their specific domains.