10. Future Trends in Embedded Systems

Learning Objectives

• Explain TinyML and why running machine learning inference directly on a microcontroller is different from cloud-based ML
• Compare edge computing to cloud computing and identify which fits a given latency/bandwidth constraint
• Explain why RISC-V is gaining adoption relative to proprietary architectures like ARM
• Identify the main IoT security threats and describe secure boot as a mitigation
• Explain energy harvesting and why it changes power-budget design assumptions
• Analyze a proposed embedded product and identify which emerging trend(s) are relevant to its design

Quick Answer

Embedded systems are being reshaped by four converging forces: machine learning small enough to run on a microcontroller (TinyML), open-source processor architectures (RISC-V) challenging proprietary designs like ARM, growing security requirements as billions of devices connect to networks, and energy harvesting that lets devices run without ever needing a battery replacement. None of these are speculative — TinyML models already run inference on chips with under 256KB of RAM, RISC-V cores ship in production silicon today, and IoT security regulations (like the EU Cyber Resilience Act) are now legally mandatory, not optional best practice. Understanding these trends matters because they change fundamental design assumptions: a device no longer needs cloud connectivity to make an ML-based decision, doesn't need a fixed-architecture license fee, must assume it will be attacked, and might never need a battery swap at all.

TinyML: Machine Learning on Microcontrollers

TinyML runs a trained neural network's inference step directly on a microcontroller — not in the cloud — using highly compressed models (via quantization, reducing weights from 32-bit floats to 8-bit integers) that fit in kilobytes of flash and execute in milliseconds without a GPU.

// Conceptual TFLite Micro inference call — the model itself is
// pre-trained and converted/quantized offline, then embedded as a
// C byte array compiled directly into firmware
#include "tensorflow/lite/micro/micro_interpreter.h"
#include "model_data.h"   // the quantized model, as a byte array

TfLiteStatus run_inference(float *sensor_input, float *output) {
    static uint8_t tensor_arena[10 * 1024];  // 10KB working memory — this small!
    tflite::MicroInterpreter interpreter(model, resolver, tensor_arena,
                                          sizeof(tensor_arena));
    interpreter.AllocateTensors();

    TfLiteTensor *input_tensor = interpreter.input(0);
    input_tensor->data.f[0] = sensor_input[0];

    TfLiteStatus invoke_status = interpreter.Invoke();
    output[0] = interpreter.output(0)->data.f[0];
    return invoke_status;
}

The real significance of TinyML: a wildlife camera trap can run image classification locally to decide "is this actually an animal, or wind moving a branch?" before ever using battery power to transmit an image over a satellite link — the decision that used to require sending all data to the cloud now happens in milliseconds on-device, using microwatts of power.

Edge Computing: Processing Where Data Is Generated

Edge computing moves computation from a centralized cloud server to the device (or a nearby gateway) generating the data. It's closely related to but broader than TinyML — edge computing can also mean running conventional (non-ML) processing locally.

Factor	Cloud Computing	Edge Computing
Latency	Network round-trip (tens–hundreds of ms)	Local processing (microseconds–ms)
Bandwidth usage	High — raw data sent continuously	Low — only summarized results sent
Works offline	No	Yes
Compute power available	Effectively unlimited	Constrained by device power/silicon

A predictive maintenance sensor on a factory motor is a realistic example: sending raw vibration data (sampled at kilohertz rates) to the cloud continuously would consume far more bandwidth than the factory's network can spare. Instead, an edge-processing MCU computes a vibration signature locally and only transmits an alert when it detects an anomaly — reducing data volume by orders of magnitude while also working correctly during a network outage.

RISC-V: The Open Instruction Set Architecture

RISC-V is an open-source instruction set architecture (ISA) — the fundamental "language" a CPU executes — that doesn't require licensing fees, unlike ARM's proprietary architecture. Any company can design and manufacture a RISC-V CPU core without paying per-unit royalties to a single company.

Why this matters for embedded systems specifically: at high volumes (tens of millions of units), even a small per-unit ARM licensing fee becomes a significant cost. RISC-V removes that cost entirely and lets companies customize the instruction set for their exact application (adding custom instructions for, say, cryptography or DSP operations) without needing ARM's permission. Major semiconductor companies (including Western Digital, Qualcomm via its involvement in RISC-V International, and numerous Chinese chipmakers responding to geopolitical supply chain concerns) have adopted RISC-V cores in production silicon, particularly for simpler embedded controllers where ARM's ecosystem advantages (tooling, existing libraries) matter less.

IoT Security: From Afterthought to Legal Requirement

Billions of connected embedded devices create an enormous attack surface, and historically, security was often an afterthought in embedded design — default passwords, unencrypted communication, and no mechanism for firmware updates left many devices permanently vulnerable once a flaw was found (the Mirai botnet's 2016 attack recruited hundreds of thousands of IoT devices using nothing more than default factory passwords).

Secure boot is a foundational mitigation: the microcontroller's boot ROM cryptographically verifies the firmware's digital signature before executing it, ensuring only firmware signed by the legitimate manufacturer can run — preventing an attacker from replacing firmware with malicious code even with physical access to the flash memory.

// Conceptual secure boot verification step (simplified)
bool verify_firmware_signature(uint8_t *firmware, size_t len,
                                 uint8_t *signature, uint8_t *public_key) {
    uint8_t computed_hash[32];
    sha256(firmware, len, computed_hash);
    return ecdsa_verify(public_key, computed_hash, signature);  // must match
}

void boot_sequence(void) {
    if (!verify_firmware_signature(app_firmware, FIRMWARE_SIZE,
                                     app_signature, manufacturer_public_key)) {
        halt_and_flash_error_led();   // refuse to run unverified/tampered code
        return;
    }
    jump_to_application(app_firmware);
}

Regulation is now catching up: the EU's Cyber Resilience Act (entering into force in the mid-2020s) legally mandates security-by-design practices — including vulnerability disclosure processes and update mechanisms — for connected products sold in the EU, turning what used to be "best practice" into a compliance requirement with real penalties.

Energy Harvesting: Devices That Never Need a Battery Swap

Energy harvesting captures ambient energy — light (photovoltaic), vibration (piezoelectric), temperature gradients (thermoelectric), or even ambient RF signals — to power ultra-low-power embedded devices indefinitely, eliminating battery replacement entirely.

This fundamentally changes the power-budget design approach covered in embedded system design: instead of calculating "how long will this battery last," the design goal becomes "can the device harvest enough energy during its duty cycle to recharge a small buffer capacitor faster than it depletes it?" A wireless sensor that wakes once per hour, harvests light energy the rest of the time, and stores just enough charge in a supercapacitor to transmit one reading, can theoretically run forever — provided its average power draw stays below the average harvested power, a genuinely different design constraint than a fixed battery capacity.

Why It Matters

These trends aren't independent — they compound. A wildlife monitoring sensor might combine all four: TinyML for on-device species classification (avoiding unnecessary cloud transmission), a RISC-V-based ultra-low-power MCU (avoiding licensing cost at scale), secure boot (preventing tampering in an unattended remote location), and solar energy harvesting (avoiding battery replacement trips to a remote forest). Understanding each trend individually is necessary, but recognizing how they combine to enable genuinely new product categories — devices that see, decide, and report entirely on their own, indefinitely, without a network connection or battery service — is the deeper insight.

Key Terms

Term	Definition	Related Concept
TinyML	Running machine learning inference directly on a microcontroller with kilobytes of memory	Quantization, edge computing
Quantization	Compressing a neural network's weights (e.g., 32-bit float to 8-bit integer) to fit constrained memory	TinyML
Edge computing	Processing data locally on or near the device generating it, rather than in a centralized cloud	Latency, bandwidth
RISC-V	An open-source, royalty-free instruction set architecture	ISA, ARM
Secure boot	Cryptographic verification of firmware signature before execution, preventing unauthorized code from running	IoT security
Energy harvesting	Capturing ambient energy (light, vibration, heat, RF) to power a device indefinitely without battery replacement	Power budget

Common Mistakes

Misconception: TinyML means running a full-size cloud ML model on a microcontroller. Why it's wrong: Cloud ML models often have millions to billions of parameters requiring gigabytes of memory and GPU acceleration; a microcontroller has kilobytes of RAM. TinyML specifically means models compressed through quantization and pruning to fit this radically smaller footprint. Correct understanding: TinyML models are purpose-built, heavily compressed versions trained and converted offline specifically to run within an MCU's severe memory and compute constraints.

---

Misconception: RISC-V is primarily attractive because it's technically superior to ARM's architecture. Why it's wrong: RISC-V's main advantage is licensing — it's open and royalty-free — not inherent technical superiority; ARM's mature ecosystem (tooling, existing software, established supply chains) still offers real advantages RISC-V is still catching up on in many cases. Correct understanding: RISC-V adoption is driven primarily by cost (no per-unit royalty) and the freedom to customize the instruction set, not by a categorical performance advantage over ARM.

---

Misconception: Energy harvesting means a device has unlimited power and design constraints no longer matter. Why it's wrong: Harvested energy is typically extremely low and variable (a small solar cell indoors, ambient vibration) — if the device's average power draw exceeds the average harvested power, it will still eventually deplete its energy buffer and fail, just on a different timeline than a battery. Correct understanding: Energy harvesting changes the design question from "how long until the battery dies" to "does average power draw stay below average harvested power," which still requires careful power budgeting, arguably more precise than with a large fixed battery.

Comparison and Connections

Trend	Solves	Key Trade-off
TinyML	Reduces need for constant cloud connectivity for ML decisions	Requires heavily compressed, less accurate models than cloud-scale ML
Edge computing	Reduces latency and bandwidth vs. cloud-only processing	Limited by on-device compute/power budget
RISC-V	Removes per-unit ISA licensing cost	Less mature tooling/ecosystem than ARM in some domains
IoT security (secure boot)	Prevents unauthorized/malicious firmware execution	Adds complexity and boot-time overhead
Energy harvesting	Eliminates battery replacement	Requires very low, carefully budgeted average power draw

Practice Questions

Recall

1. What is quantization, and why is it necessary for TinyML? Answer guidance: Quantization compresses a neural network's weights (typically from 32-bit floating point to 8-bit integers), drastically reducing memory and compute requirements so the model can fit and run within a microcontroller's kilobytes of RAM and limited processing power.

2. What does secure boot verify, and what does it prevent? Answer guidance: Secure boot verifies a cryptographic signature on the firmware image before allowing it to execute; it prevents unauthorized or maliciously modified firmware from running, even if an attacker has physical access to the device's flash memory.

Understanding

3. Explain why edge computing reduces bandwidth usage compared to sending all raw sensor data to the cloud. Answer guidance: Edge computing processes and summarizes data locally (e.g., detecting an anomaly) and only transmits the meaningful result rather than the continuous raw data stream, drastically cutting the volume of data sent over the network.

4. Why does energy harvesting change the fundamental power-budget question compared to battery-powered design? Answer guidance: Battery design asks "how long will a fixed energy reserve last given average draw"; energy harvesting design asks "does average power draw stay below average harvested power," since the energy source is continuously replenished rather than finite and depleting.

Application

5. A remote wildlife camera trap needs to classify images as "animal" or "not animal" before deciding whether to transmit via expensive satellite uplink, and it must run for years on a small solar panel. Identify which two trends from this page directly apply and justify each. Answer guidance: TinyML — running image classification on-device avoids transmitting every frame via the expensive satellite link, only sending confirmed animal detections. Energy harvesting — the solar panel design must ensure average harvested power exceeds the camera's average draw (including periodic ML inference) to run indefinitely without battery replacement in a remote location.

6. A chip manufacturer plans to ship 50 million units of a simple sensor controller and is deciding between an ARM Cortex-M0 (with per-unit licensing fee) and an equivalent RISC-V core. Explain the primary factor in this decision. Answer guidance: At 50 million units, even a small per-unit ARM royalty compounds into a very large total cost; RISC-V's royalty-free licensing directly reduces per-unit cost at this volume, making it the primary factor, assuming the RISC-V ecosystem's tooling/software support is sufficient for the simple controller's needs.

Analysis

7. A company ships an IoT device with no secure boot and a default admin password that most users never change. Analyze the security risk and connect it to a real historical precedent mentioned on this page. Answer guidance: Without secure boot, an attacker with physical or remote access could replace firmware with malicious code; combined with unchanged default passwords, the device becomes trivially compromisable — this is exactly the vulnerability pattern the 2016 Mirai botnet exploited across hundreds of thousands of IoT devices using only default credentials, without needing any firmware-level attack at all.

8. A team argues that because their device now uses energy harvesting, they no longer need to optimize their firmware's power consumption. Evaluate this reasoning using the concepts on this page. Answer guidance: This reasoning is flawed — energy harvesting typically provides small, variable amounts of power (e.g., indoor light, ambient vibration); if firmware power draw isn't optimized and exceeds the average harvested power, the device's energy buffer will still deplete over time and the device will fail intermittently or permanently, just as surely as a poorly optimized battery-powered device drains its battery faster than expected.

FAQ

Does TinyML mean cloud-based AI is becoming obsolete for embedded devices? No — TinyML and cloud AI serve different needs. TinyML handles latency-sensitive, bandwidth-constrained, or offline-capable decisions locally (e.g., "is this a person?"), while more complex analysis, model retraining, and aggregating data across many devices still typically happens in the cloud. Most real systems use both together.

Is RISC-V going to fully replace ARM in embedded systems? Not immediately or entirely — ARM's mature toolchain, existing software libraries, and established supply chains still offer real advantages, especially for complex applications. RISC-V is gaining the most ground in cost-sensitive, high-volume, or geopolitically motivated scenarios (companies wanting to avoid dependence on a single foreign IP licensor) rather than uniformly across all embedded use cases.

Why can't every embedded device just add secure boot and call itself secure? Secure boot addresses one specific threat (unauthorized firmware execution) but is only one layer of a broader security posture — a device also needs secure communication (TLS), secure key storage, protection against physical attacks, and a process for patching newly discovered vulnerabilities. Secure boot is necessary but not sufficient on its own.

How much power can realistically be harvested from ambient sources? It varies enormously by source: indoor photovoltaic might yield only tens of microwatts per square centimeter, while outdoor sunlight yields far more; vibration harvesting from industrial machinery might yield hundreds of microwatts; thermoelectric harvesting depends on the temperature gradient available. This is precisely why energy-harvesting designs require very aggressive power budgeting — the available power is often orders of magnitude smaller than a coin-cell battery's effective output.

Are these trends relevant to hobbyist or student projects, or only industrial-scale products? All four are increasingly accessible at small scale — TensorFlow Lite Micro runs on affordable dev boards, several RISC-V-based dev boards are available for under $10, secure boot is supported on many mainstream MCUs' boot ROMs, and small solar/piezo harvesting modules are inexpensive and available for hobbyist projects. Understanding these trends now is directly applicable to real, buildable student projects, not just theoretical future industry direction.

Quick Revision

• TinyML runs compressed (quantized) ML inference directly on microcontrollers with kilobytes of memory, avoiding cloud round-trips
• Edge computing processes data locally to reduce latency, bandwidth, and dependence on network connectivity
• RISC-V is an open, royalty-free instruction set architecture gaining adoption for its cost and customization advantages over proprietary ARM licensing
• IoT security failures (e.g., Mirai botnet, 2016) show the real cost of skipping security-by-design in connected devices
• Secure boot cryptographically verifies firmware before execution, preventing unauthorized code from running
• Regulations like the EU Cyber Resilience Act now make IoT security a legal requirement, not just best practice
• Energy harvesting captures ambient light, vibration, heat, or RF energy to eliminate battery replacement
• Energy harvesting design shifts the power question from "battery life" to "does average draw stay below average harvested power"
• These trends compound in real products — a single device can combine TinyML, edge processing, RISC-V, secure boot, and harvesting together
• None of these trends are purely speculative — production silicon, deployed regulations, and buildable hobbyist hardware exist today for each

Related Topics

Prerequisites: Embedded System Applications, Embedded System Design

Related Topics: Embedded System Architecture, Embedded System Interfaces, Debugging Embedded Systems

Next Topics: Real-Time Operating Systems (RTOS choices for TinyML/edge workloads), Hardware-Software Co-Design (partitioning ML inference between hardware accelerators and software)