Embedded platforms and device programming notes — Unit 2

To understand IoT embedded platforms, one must first grasp the fundamental architectural difference between the processors in our laptops and the processors in our smart lightbulbs.

⇒1.1 The Microprocessor (MPU)

A microprocessor (like an Intel Core i7 or ARM Cortex-A series) is the heart of a general-purpose computer. It contains the CPU arithmetic and logic units, but it lacks built-in memory (RAM/ROM) and I/O peripherals. These must be added externally on a motherboard. MPUs are designed for maximum computational power, handling heavy operating systems like Windows or Linux.

⇒1.2 The Microcontroller (MCU)

A microcontroller is an entire 'computer-on-a-chip'. It contains the CPU, alongside RAM, flash memory (for storing the program), and vital I/O peripherals (ADC, timers, serial communication ports) all on a single piece of silicon. MCUs are designed for highly specific, low-power control tasks. They do not run full operating systems; they usually run a single, compiled loop of C/C++ code (or a lightweight RTOS) forever.

The barrier to entry for IoT development has been destroyed by the rise of open-source hardware prototyping platforms. These abstract away the complex electrical engineering required to design custom PCBs.

⇒2.1 The Arduino Ecosystem

Arduino is not a specific chip, but an ecosystem comprising standardized hardware boards (like the Arduino Uno based on the ATmega328P MCU), a simplified C++ programming environment, and a massive community library. Arduinos are perfect for reading sensors and controlling simple actuators, but basic models lack native internet connectivity.

⇒2.2 The ESP8266 and ESP32

Manufactured by Espressif, these are revolutionary MCUs. The ESP32 provides a powerful dual-core processor, native Wi-Fi, and native Bluetooth (BLE) built directly into a chip that costs less than $3. They can be programmed using the Arduino IDE, making them the default choice for modern, low-cost wireless IoT prototyping.

When a microcontroller lacks the processing power to handle complex tasks like image recognition, video streaming, or running a local database, developers turn to Single Board Computers.

⇒3.1 The Raspberry Pi

The Raspberry Pi is a fully functional computer shrunk to the size of a credit card. It uses a Broadcom ARM microprocessor (MPU), has gigabytes of RAM, uses an SD card as a hard drive, and runs a full Debian Linux operating system (Raspberry Pi OS).

Crucially for IoT, it includes General Purpose Input/Output (GPIO) pins, allowing Python or C scripts running in Linux to directly read sensors and control hardware. In a multi-tier IoT architecture, MCUs act as the edge sensors (Layer 1), while a Raspberry Pi often acts as the Edge Gateway (Layer 3), aggregating data from the MCUs via Bluetooth, processing it, and forwarding it to the cloud via Wi-Fi/Ethernet.

Writing code for an MCU with 32 Kilobytes of RAM requires a fundamentally different mindset than writing a web app for a server with 32 Gigabytes of RAM.

⇒4.1 The Super-Loop Architecture

The most basic embedded software architecture is the infinite loop (often called 'bare-metal' programming).

void setup() {
  // Initialize hardware, set pin modes, connect to Wi-Fi.
  // This runs exactly once upon boot.
  initializeSensors();
}

void loop() {
  // This runs continuously, forever.
  int temp = readTemperature();
  if (temp > 50) {
    turnOnFan();
  }
  delay(1000); // Sleep for 1 second to save power
}

While simple, the super-loop fails spectacularly when tasks must run concurrently. If `readTemperature()` takes 5 seconds to execute because it's waiting for a network response, the entire device freezes for 5 seconds. It cannot blink an LED or read a button press during that time. This is known as blocking code.

To solve the problem of blocking code, microcontrollers utilize hardware Interrupts.

⇒5.1 The Interrupt Service Routine (ISR)

An interrupt is a hardware signal that violently pauses the main `loop()`, saves the exact state of the CPU, and forces the CPU to immediately execute a special, tiny function called an Interrupt Service Routine (ISR). Once the ISR finishes, the CPU resumes the main loop exactly where it left off.

• External Interrupts: Triggered by physical events. E.g., A button press sends a voltage spike to a specific pin. The CPU stops what it's doing immediately to register the press, ensuring no clicks are missed even if the main loop is busy.
• Timer Interrupts: Triggered by internal hardware timers ticking down. Crucial for executing code at exactly precise intervals (e.g., 'sample this audio sensor exactly 44,100 times per second').

ISRs must be incredibly short and fast. You should never put a `delay()` or a complex print statement inside an ISR, as it halts the rest of the system.

When an IoT application becomes too complex for a super-loop with a few interrupts—for example, managing Wi-Fi, reading sensors, driving a display, and handling OTA (Over-The-Air) updates simultaneously—developers use an RTOS.

⇒6.1 Determinism vs. Speed

A general-purpose OS (like Windows or Linux) is designed for fairness and throughput. It gives every program a slice of CPU time, but it makes no guarantees exactly when a program will run. This is fatal in critical IoT (e.g., deploying an airbag or firing a pacemaker pulse).

An RTOS (like FreeRTOS or Zephyr) prioritizes determinism. It guarantees that high-priority tasks will meet strict timing deadlines, even if it means starving lower-priority tasks.

⇒7.1 Tasks and the Scheduler

In an RTOS, you write multiple infinite loops called Tasks. The RTOS Scheduler rapidly switches the CPU between these tasks. A high-priority task (like 'Read Crash Sensor') will instantly preempt (interrupt) a low-priority task (like 'Update LCD Display').

⇒7.2 Concurrency Primitives

Because multiple tasks might try to use the same resource simultaneously (e.g., two tasks trying to write to the same serial port), an RTOS provides mechanisms for safe sharing:

• Semaphores / Mutexes: Tokens that act as 'keys'. A task must acquire the key before using a shared resource. If another task has the key, the requesting task is put to sleep until the key is returned.
• Queues: Safe mailboxes for passing data between tasks. Task A reads the sensor and drops the value into a Queue. Task B reads the Queue and sends the data over Wi-Fi. This decouples the sensing speed from the network speed.

Unit 2 focuses on the software architecture of the devices themselves. The distinction between 'bare-metal' coding and operating systems is heavily tested.

• MCU vs MPU: Be able to explicitly define the difference based on memory integration and intended use-case (real-time control vs general computation).
• Arduino vs Raspberry Pi: Understand when to use an MCU (low power, simple sensing) versus an SBC (heavy processing, Linux requirement).
• Interrupts: Explain why polling (checking a pin state constantly in a loop) is inefficient compared to hardware interrupts.
• RTOS: Define determinism. Explain how a preemptive scheduler ensures critical deadlines are met, and why mechanisms like Mutexes are required to prevent data corruption.