Microcontroller Unit (MCU)

An MCU is a System-on-Chip (SoC) that consolidates all core computing components onto a single silicon die. This monolithic integration is key to its low cost, small form factor, and power efficiency.

Core components include:

• Central Processing Unit (CPU): A low-power processor core (e.g., ARM Cortex-M, RISC-V).
• Memory: Integrated volatile RAM for runtime data and non-volatile Flash for program storage.
• Peripherals: Directly accessible GPIO pins, Analog-to-Digital Converters (ADCs), timers, and communication interfaces like I²C, SPI, and UART.

This tight integration eliminates the need for external memory or complex buses, making it ideal for dedicated control tasks in embedded systems.

MCUs operate under severe memory constraints, which define the feasibility of TinyML models. Memory is divided into two primary types, both typically measured in kilobytes (KB) or megabytes (MB).

• Flash Memory (Program Memory): Stores the model's weights, the firmware, and the application code. Typical range: 64 KB to 2 MB.
• RAM (Working Memory): Holds the model's activations, runtime buffers, input data, and intermediate results during inference or training. Typical range: 8 KB to 512 KB.

This limited hierarchy forces extreme model compression via quantization, pruning, and sparsification. The model's total memory footprint must fit within these strict bounds.

MCU compute is characterized by low clock speeds (MHz range), single or dual-core designs, and a focus on energy efficiency, not raw performance. This defines the compute constraint for on-device algorithms.

Key architectural traits:

• Clock Speed: Typically 10 MHz to 300 MHz.
• No Floating-Point Unit (FPU): Many low-end MCUs lack hardware FPUs, making 32-bit floating-point operations slow and power-intensive. This necessitates integer-only inference using 8-bit or 16-bit arithmetic.
• Ultra-Low-Power States: MCUs excel at spending most of their time in sleep or deep-sleep modes (consuming microamps), waking briefly to perform tasks. This directly impacts the energy budget for ML operations.

Compute-intensive tasks like training must be meticulously optimized to avoid thermal throttling and excessive battery drain.

MCUs are the central hub for sensor data streams, interfacing directly with the physical world via built-in peripherals. This enables real-time on-device preprocessing before data reaches the ML model.

Critical interfaces include:

• Analog-to-Digital Converters (ADCs): Convert real-world signals (e.g., voltage from a temperature sensor) into digital values for the CPU.
• Digital I/O (GPIO): General-purpose pins for reading buttons or controlling LEDs.
• Communication Protocols:
  • I²C & SPI: For connecting multiple sensors (e.g., accelerometers, gyroscopes).
  • UART: For serial communication with other modules or for debugging.

This direct hardware access allows MCUs to perform feature extraction (like computing a Fast Fourier Transform on audio) locally, reducing the data volume for the model.

Deploying ML to an MCU involves compiling the model into efficient, low-level code and integrating it into the device's firmware—the permanent software that controls the hardware.

The deployment pipeline:

1. Model Conversion & Optimization: A trained model is compressed via Post-Training Quantization (PTQ) or Quantization-Aware Training (QAT) and converted to a compatible format (e.g., TensorFlow Lite for Microcontrollers).
2. Cross-Compilation: The model and application code are compiled on a powerful host computer for the MCU's specific instruction set architecture (ISA).
3. Firmware Integration: The compiled model is linked with a minimal TinyML runtime and the main application firmware.
4. Flashing: The final binary is loaded onto the MCU's Flash memory via a programmer or Over-the-Air (OTA) update system.

The result is a single, self-contained executable that runs the ML model without an OS.

In Federated Learning for TinyML, MCUs act as the heterogeneous clients. Their extreme constraints shape the entire federated learning algorithm design.

Key implications for FL:

• Sparse Updates: To respect communication-efficient principles, clients often send only sparse updates (e.g., top-k gradients) to the server.
• Partial Participation: MCU clients have limited availability windows (when powered and idle), leading to partial participation in rounds and the straggler problem.
• On-Device Training: Training must use low-precision arithmetic and manage memory footprint to avoid crashing. Embedded FL runtimes must handle checkpointing and resource management.
• Secure & Private Execution: The MCU's isolated environment is ideal for executing secure aggregation protocols and applying differential privacy noise locally before any data leaves the chip.

The MCU is not just an inference target but an active, private participant in the collaborative learning process.

An MCU is a complete computer system on a single chip. Unlike general-purpose CPUs, it integrates the processor core (CPU), volatile memory (RAM), non-volatile memory (Flash/ROM), and programmable input/output (I/O) peripherals into one silicon package. This monolithic design is critical for TinyML because:

• It minimizes physical size and power consumption by eliminating external memory buses.
• It provides deterministic, low-latency access to on-chip memory, which is essential for real-time sensor data processing.
• The fixed memory hierarchy (e.g., 256 KB Flash, 64 KB RAM) sets the absolute upper bound for model size and complexity.

MCUs are engineered for microwatt to milliwatt power budgets, enabling years of operation on a coin-cell battery. This is non-negotiable for always-on TinyML sensors. Key power management features include:

• Multiple Sleep Modes: Deep sleep states that draw < 1µA, waking only for inference or data collection.
• Clock Gating: Dynamically shutting down unused peripherals and CPU subsystems.
• Energy-Proportional Computing: The ability to scale active power consumption nearly linearly with workload. This constrained energy budget forces federated edge learning algorithms to be communication-sparse and limits the computational intensity of local training rounds.

MCUs run bare-metal firmware or a Real-Time Operating System (RTOS), not a general-purpose OS like Linux. This provides:

• Deterministic Timing: Guaranteed interrupt response times and task execution deadlines, crucial for processing sensor data streams without missing samples.
• No Memory Paging: Eliminates unpredictable latency from virtual memory swaps, ensuring consistent inference times.
• Direct Hardware Access: Firmware has exclusive control over peripherals (ADCs, I2C, SPI), allowing precise scheduling of sensor sampling and radio transmission windows for federated updates. This predictability is essential for reliable, safety-critical TinyML applications.

The memory profile of an MCU is the primary constraint for TinyML model design. A typical Arm Cortex-M4F MCU might have:

• Flash Memory (512 KB): Stores the model weights, firmware code, and a small static dataset.
• SRAM (128 KB): Holds the model's runtime activations, intermediate tensors, and the live sensor data buffer. This forces extreme model compression via quantization, pruning, and sparsification. The entire inference engine, model parameters, and activation buffers must fit within the SRAM limit to avoid catastrophic slowdowns from external memory access.

MCUs directly interface with the physical world through built-in peripherals, creating a self-contained sensing and actuation system. Common integrated peripherals include:

• Analog-to-Digital Converters (ADCs): For reading analog sensors (temperature, vibration, audio).
• Digital I/O & PWM: For controlling LEDs, motors, or relays.
• Communication Interfaces: I2C, SPI, UART for connecting additional sensors; Bluetooth Low Energy (BLE) or IEEE 802.15.4 for federated learning communications. This integration allows raw sensor data streams to be preprocessed, inferred upon, and acted upon entirely on-device, minimizing latency and enabling true edge autonomy.

MCUs are the physical instantiation of a federated learning client. Their characteristics directly shape the FL algorithm design:

• Heterogeneity: Variations in MCU compute class (Cortex-M0 vs. M7) and memory create heterogeneous clients, requiring adaptive workload assignment.
• Availability Windows: Battery-powered MCUs are only intermittently available for training, enforcing partial participation.
• Communication Cost: Sending full 32-bit floating-point updates over low-power radios is prohibitive, necessitating sparse updates and quantized communication.
• On-Device Training: Newer MCUs with modest DSP extensions enable local stochastic gradient descent (SGD), making true federated edge learning possible without a central cloud.

Tiny Machine Learning (TinyML) is the subfield focused on developing and deploying ultra-low-power, memory-efficient models capable of running inference and training directly on microcontroller units (MCUs) and other deeply embedded devices. It is the foundational paradigm enabling Federated Learning at the extreme edge.

• Core Challenge: Operates within severe constraints of < 1 MB of memory and milliwatt power budgets.
• Key Enablers: Techniques like quantization, pruning, and specialized neural network architectures (e.g., MobileNetV3, MicroNets).
• Application Scope: Enables always-on, battery-powered smart sensors for predictive maintenance, keyword spotting, and anomaly detection.

A resource-constrained device is an embedded system, typically based on an MCU, with severe limitations that define the TinyML challenge space. These constraints are absolute boundaries for federated edge learning algorithms.

• Primary Constraints:
  • Memory: Often < 512 KB RAM for runtime, < 2 MB Flash for model storage.
  • Compute: Clock speeds in the tens to hundreds of MHz, lacking floating-point units (FPUs).
  • Energy: Powered by small batteries or energy harvesting, with total energy budgets in the joule range.
  • Connectivity: Low-bandwidth, intermittent links (e.g., LoRaWAN, BLE).
• Design Implication: Algorithms must be designed for worst-case resource availability, not averages.

Memory footprint refers to the total volatile (RAM) and non-volatile (Flash) memory consumed by a machine learning model's parameters, activations, and runtime buffers. It is the first-order constraint for MCU deployment.

• Breakdown:
  • Model Weights: Stored in Flash memory. Reduced via post-training quantization (PTQ) to 8-bit integers.
  • Activation Memory: Stored in RAM during inference/training. A major bottleneck for layer size.
  • Runtime Buffers: Memory for intermediate computations.
• TinyML Target: Total RAM footprint often must be under 256 KB, including the federated learning client runtime.

Compute constraint refers to the limitation imposed by the available processing power of an MCU, restricting the complexity of models and training algorithms. It is measured in Millions of Operations Per Second (MOPS).

• Typical MCU Profile: A 80 MHz ARM Cortex-M4 core can perform ~ 100-200 MOPS.
• Federated Learning Impact: Limits:
  • Local Training Steps (Epochs): Often just 1-5 per round.
  • Model Architecture: Deep networks are infeasible; shallow, efficient networks are required.
  • Batch Size: Frequently 1 (online learning) due to RAM limits.
• Mitigation: Use of hardware accelerators (e.g., Arm Ethos-U55 microNPU) for specific ops.

The energy budget is the total electrical energy allocated for a computational task, a fundamental design constraint for battery-powered MCUs. It directly dictates the feasibility and frequency of federated training rounds.

• Components of Consumption:
  • Sensing & Data Collection: Often minimal.
  • On-Device Training: The dominant consumer. A single training step can cost ~10-100 microjoules per parameter update.
  • Wireless Communication: Transmitting a model update can be 10-1000x more costly than computing it.
• System Design Goal: Maximize learning progress per joule of energy expended, favoring sparse updates and efficient communication.

Heterogeneous clients in federated edge learning refer to the significant variation across MCU-based devices. This heterogeneity complicates synchronous training and requires robust, adaptive algorithms.

• Dimensions of Heterogeneity:
  • Hardware: Different MCU families (Cortex-M0 vs M7), memory sizes, and presence of accelerators.
  • Data Distribution: Non-IID data is the rule, as each sensor sees a unique physical environment.
  • Availability: Devices have intermittent availability windows based on power state and primary task.
  • Connectivity: Varied bandwidth and latency.
• Algorithmic Challenge: Must avoid the straggler problem and ensure fairness despite vastly different client capabilities.