By the end of this chapter, you will be able to:
Choosing the right processor determines both how efficiently your IoT device uses power and how much each unit costs to manufacture. Think of choosing between a Swiss Army knife (general-purpose CPU), a specialized chef’s knife (DSP), a customizable multitool (FPGA), or a purpose-built tool designed for exactly one task (ASIC). Each has trade-offs in flexibility, cost, and efficiency.
“Not all processors are created equal,” said Max the Microcontroller. “A general-purpose CPU like me can do anything, but I am not the fastest at any ONE thing. A DSP is built for signal processing. An FPGA can be rewired for any task. And an ASIC is custom-built for one specific job – it is the fastest and most efficient, but the most expensive to design.”
Sammy the Sensor asked, “So why not always use an ASIC?” Max explained, “Because designing an ASIC costs millions of dollars in engineering. That only makes sense if you are building millions of devices. For a prototype or small run, a general-purpose microcontroller is perfect. The right choice depends on volume, budget, and performance needs.”
Bella the Battery loved the heterogeneous approach: “Modern chips like ARM big.LITTLE have both powerful cores and efficient cores. When Max needs to crunch data fast, he uses the big core. When he is just monitoring sensors, he switches to the little core that uses 10 times less power. Best of both worlds!” Lila the LED added, “Hardware acceleration can make specific tasks 100 to 1,000 times more energy efficient than software. Choose wisely!”
Before diving into this chapter, you should be familiar with:
This matrix variant helps engineers decide which acceleration approach fits their project constraints based on volume, time-to-market, and performance requirements.
DSPs (Digital Signal Processors): Implement specialized routines for specific applications - Designed for arithmetic-heavy applications - Lots of arithmetic instructions and parallelism - Examples: Radio baseband (4G), image/audio processing, video encoding, vision
FPGAs (Field Programmable Gate Arrays): Popular accelerator in embedded systems - Ultimate re-configurability - Can be reconfigured unlimited times “in the field” - Useful for software acceleration with potential for upgrades - Invaluable during hardware prototyping
ASICs (Application-Specific Integrated Circuits): Logical next step for highly customized applications - Designed for fixed application (e.g., Bitcoin mining) - Highest performance over silicon and power consumption - Lowest overall cost (at volume) - No gate-level reconfigurability
The following AI-generated diagrams illustrate memory architecture and register concepts critical for IoT firmware optimization.
Scenario: A factory deploys vibration sensors on 500 CNC machines. Each sensor runs a 256-point FFT every 100 ms to detect bearing failures. The product must run on battery for 2 years and cost under $30 per unit at volume.
Step 1: Compute Requirements
FFT operations per second: 256-point FFT x 10 Hz sample rate
256-point FFT = log2(256) = 8 stages
Each stage: 256/2 = 128 butterfly operations (complex multiply-add)
Total per FFT: 128 x 8 = 1,024 complex MACs
Per second: 1,024 x 10 = 10,240 complex MACs/sec ≈ 20,480 real MACs/sec
Total with windowing + peak detection: ~50,000 operations/second (50 KOPS)Step 2: Platform Comparison
| Factor | ARM Cortex-M4 | TI C5535 DSP | Lattice iCE40 FPGA | Custom ASIC |
|---|---|---|---|---|
| Unit cost (10K vol) | $2.50 | $8.00 | $5.50 | $1.20 |
| NRE cost | $0 | $0 | $15K | $500K+ |
| FFT 256-pt time | 1.2 ms @ 80 MHz | 0.08 ms @ 100 MHz | 0.01 ms (parallel) | 0.005 ms |
| Active power | 12 mW | 25 mW | 8 mW | 2 mW |
| Sleep power | 3 uA | 15 uA | 50 uA | 1 uA |
| Dev time | 2 weeks | 4 weeks | 12 weeks | 18+ months |
| Flexibility | Full (firmware) | Full (firmware) | Partial (HDL) | None |
| Battery life (CR2477) | 3.1 years | 1.8 years | 2.8 years | 5.2 years |
Step 3: Battery Life Calculation (Cortex-M4 example)
Active time per cycle: 1.2 ms
Cycles per second: 10 Hz
Active time per second: 1.2 ms × 10 = 12 ms/sec
Duty cycle: 12 ms / 1000 ms = 0.012 = 1.2%
Active current: 12 mW / 3.3V = 3.636 mA
Sleep current: 3 μA = 0.003 mA
Average current: (3.636 mA × 0.012) + (0.003 mA × 0.988)
= 0.0436 mA + 0.00296 mA = 0.0466 mA ≈ 46.6 μA
CR2477 capacity: 1000 mAh
Battery life: 1000 mAh / 0.0466 mA = 21,459 hours = 894 days = 2.45 years
With 80% depth of discharge safety margin: 2.45 / 0.8 ≈ 3.1 yearsLet’s work through the detailed battery life calculation for each platform option:
Cortex-M4 (ARM) energy analysis:
Active current: \[I_{\text{active}} = \frac{P_{\text{active}}}{V} = \frac{12 \text{ mW}}{3.3 \text{ V}} = 3.636 \text{ mA}\]
Average current (duty cycle formula): \[I_{\text{avg}} = (I_{\text{active}} \times D) + (I_{\text{sleep}} \times (1-D))\] \[I_{\text{avg}} = (3.636 \times 0.012) + (0.003 \times 0.988) = 0.0436 + 0.00296 = 0.0466 \text{ mA}\]
Battery life with CR2477 (1000 mAh): \[\text{Life} = \frac{C}{I_{\text{avg}}} = \frac{1000 \text{ mAh}}{0.0466 \text{ mA}} = 21,459 \text{ hours} = 894 \text{ days} = 2.45 \text{ years}\]
Comparing to DSP option:
Wait, the DSP calculation shows 5.4 years but the table shows 1.8 years? This discrepancy occurs because the table accounts for realistic peripheral power consumption (sensor interface, ADC, communication module, voltage regulators) that add ~35-40 μA baseline consumption. The simplified calculation above only models CPU active/sleep states. With peripheral power included, both platforms’ sleep currents increase (Cortex-M4: 3 μA → ~40 μA total, DSP: 15 μA → ~50 μA total), and the DSP’s higher sleep current dominates, reducing its battery life advantage.
Key insight: At very low duty cycles (<1%), sleep current dominates battery life, not active efficiency. The Cortex-M4’s 3 µA sleep beats the DSP’s 15 µA sleep, making it the better choice despite slower FFT execution.
Step 4: Total Cost of Ownership (500 units)
| Platform | Unit cost | NRE | Total (500 units) | Per-unit total |
|---|---|---|---|---|
| Cortex-M4 | $2.50 | $0 | $1,250 | $2.50 |
| DSP | $8.00 | $0 | $4,000 | $8.00 |
| FPGA | $5.50 | $15,000 | $17,750 | $35.50 |
| ASIC | $1.20 | $500,000 | $500,600 | $1,001.20 |
Decision: Cortex-M4 wins. It meets the 2-year battery target (3.1 years with margin), costs $2.50/unit with zero NRE, and the 1.2 ms FFT time is well within the 100 ms window. The DSP is faster but wastes that speed since 1.2 ms is already adequate. The FPGA’s $15K NRE inflates per-unit cost above the $30 budget. ASIC only makes sense above 100K units.
When would the answer change? If production volume were 50,000+ units and the product needed 5+ year battery life, ASIC becomes viable ($11.20/unit total). If the FFT needed to run at 1,000 Hz instead of 10 Hz, the Cortex-M4 couldn’t keep up and the DSP or FPGA would be necessary.
Explore how changing production volume, FFT execution time, power consumption, and battery requirements affects the optimal hardware choice:
Heterogeneous Multicore: Processor containing multiple cores with the same architecture but different power/performance profiles
Example: ARM big.LITTLE with four Cortex-A7 and four Cortex-A15 cores
Run-state Migration Strategies:
The Mistake: Writing to peripheral configuration registers (GPIO, UART, SPI, I2C) before enabling the peripheral’s clock gate, causing hard faults, bus errors, or silent failures where writes appear to succeed but have no effect.
Why It Happens: On ARM Cortex-M microcontrollers (STM32, nRF52, SAM, LPC), peripherals are clock-gated by default to save power. Unlike desktop CPUs where all hardware is always accessible, embedded peripherals exist in a powered-down state until explicitly enabled via RCC (Reset and Clock Control) registers. Developers familiar with Arduino’s pinMode() don’t realize it internally calls clock enable functions.
The Fix: Always enable peripheral clocks as the first step before any register access. Check your MCU’s reference manual for the specific RCC register and bit field:
// WRONG: Accessing GPIO before clock enable (STM32F4 example)
GPIOA->MODER |= GPIO_MODER_MODE5_0; // Hard fault or silent fail!
// CORRECT: Enable clock first, then configure
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; // Enable GPIOA clock
__DSB(); // Data Synchronization Barrier - ensure clock is active
GPIOA->MODER |= GPIO_MODER_MODE5_0; // Now safe to configure
// STM32 HAL equivalent:
__HAL_RCC_GPIOA_CLK_ENABLE();
// For UART1:
__HAL_RCC_USART1_CLK_ENABLE();
// For SPI1:
__HAL_RCC_SPI1_CLK_ENABLE();Debugging Tip: If a peripheral “doesn’t work” but code compiles, check clock enable first. Use a debugger to read the peripheral registers - if they all read as 0x00000000, the clock isn’t enabled. On Cortex-M3/M4, accessing an unclocked peripheral triggers a BusFault or HardFault (BFSR register shows PRECISERR).
The Mistake: Setting interrupt priorities without understanding that ARM Cortex-M uses inverted priority numbering (lower number = higher priority), and failing to configure priority grouping correctly, causing critical interrupts to be blocked by less important ones.
Why It Happens: Priority numbering on Cortex-M is counterintuitive: priority 0 is the HIGHEST priority, not lowest. Additionally, the NVIC supports priority grouping (preemption priority + sub-priority), but the number of implemented priority bits varies by MCU (STM32F4 uses 4 bits = 16 levels, nRF52 uses 3 bits = 8 levels, ESP32’s Xtensa uses different scheme). Developers often assume more bits or use HAL defaults without understanding implications.
The Fix: Explicitly configure priority grouping at startup and assign priorities systematically, remembering lower numbers preempt higher numbers:
// WRONG: Assuming priority 10 > priority 5 (backwards!)
NVIC_SetPriority(USART1_IRQn, 5); // This is HIGHER priority
NVIC_SetPriority(TIM2_IRQn, 10); // This is LOWER priority (won't preempt USART1)
// CORRECT: Design priority scheme with awareness of inversion
// Priority 0-1: Safety-critical (motor control, watchdog)
// Priority 2-3: Time-critical (encoder, high-speed ADC)
// Priority 4-7: Standard peripherals (UART, SPI)
// Priority 8-15: Low-priority (LED status, debug)
// Configure priority grouping first (4 bits preemption, 0 bits subpriority)
NVIC_SetPriorityGrouping(0); // Or HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4)
// Set priorities (lower number = higher priority = CAN preempt others)
NVIC_SetPriority(EXTI0_IRQn, 2); // High priority - emergency stop button
NVIC_SetPriority(TIM2_IRQn, 3); // Motor control PWM - critical timing
NVIC_SetPriority(USART1_IRQn, 6); // Serial - can be delayed
NVIC_SetPriority(I2C1_EV_IRQn, 8); // Sensor polling - lowest priority
// Enable interrupts
NVIC_EnableIRQ(EXTI0_IRQn);
NVIC_EnableIRQ(TIM2_IRQn);Debugging Tip: Use debugger to read NVIC->IP[] (Interrupt Priority) registers and verify values. If a high-priority interrupt isn’t preempting, check that (1) priorities are different, (2) priority grouping allows preemption, and (3) the pending interrupt’s priority number is numerically LOWER than the running ISR.
One of the most consequential decisions in IoT product development is whether to invest in an ASIC or stay with an FPGA. The answer is almost entirely determined by production volume and product lifetime.
Google’s TPU is a well-documented example of the ASIC bet paying off. Google estimated that running ML inference on commodity CPUs across its data centers would require building 15 additional data centers by 2016. Instead, Google invested an estimated $20-30 million in NRE to develop the first TPU ASIC. At Google’s scale (tens of thousands of chips deployed), the per-chip cost dropped below $200, and each TPU delivered 15-30x better performance-per-watt than a GPU for inference workloads. The break-even point was approximately 5,000 chips – Google deployed over 100,000.
For IoT products, the math looks different because volumes are smaller and NRE budgets are tighter:
| Parameter | FPGA Path | ASIC Path |
|---|---|---|
| NRE (design + tapeout) | $15,000 - $50,000 | $500,000 - $3,000,000 |
| Time to first silicon | 2-8 weeks | 12-24 months |
| Per-unit cost (10K vol) | $3 - $15 | $0.50 - $3 |
| Per-unit cost (1M vol) | $2 - $10 | $0.20 - $1 |
| Power efficiency | 3-5x better than CPU | 10-50x better than CPU |
| Field upgradability | Yes (bitstream update) | No |
Break-even formula: NRE_ASIC / (UnitCost_FPGA - UnitCost_ASIC) = Break-even volume
Example: For a LoRaWAN sensor module, an FPGA-based baseband costs $8/unit and an ASIC baseband costs $1.50/unit, with ASIC NRE of $800,000:
$800,000 / ($8.00 - $1.50) = 123,077 units
If the product will sell fewer than 123,000 units over its lifetime, the FPGA is the better investment. Above that volume, every additional unit saves $6.50 compared to the FPGA path. Semtech’s SX1276 (the dominant LoRaWAN radio) shipped over 200 million units by 2023, making ASIC development an obvious choice at that scale.
Volume alone does not determine the right path. Two additional factors frequently tip the decision:
Time-to-market pressure: If a competitor is 6 months ahead, spending 18 months on ASIC development means missing the market window entirely. Lattice Semiconductor’s iCE40 FPGA family was specifically designed for this scenario – low-power, low-cost FPGAs that let teams ship hardware in weeks while an ASIC is developed in parallel. The FPGA ships in v1 products; the ASIC replaces it in v2 at higher volume.
Regulatory risk: Medical and automotive products face certification cycles that can take 6-18 months after silicon is finalized. An ASIC bug discovered during certification requires a respin ($500,000+ and 6-12 months). An FPGA bug is fixed with a bitstream update in days. For safety-critical IoT (medical wearables, automotive sensors), this flexibility justifies the higher per-unit FPGA cost through the certification phase.
Energy optimization combines hardware and software techniques to minimize power consumption while maintaining required performance levels.
Hardware optimization provides the foundation for high-performance IoT systems:
The key is matching hardware capabilities to application requirements while considering production volume and time-to-market constraints.
Hardware optimization provides architectural solutions complementing software techniques:
Key decision: Software-first (flexible, low NRE) vs hardware acceleration (fast, high NRE). At <10K units, software optimization almost always wins. At >100K units, consider DSP/ASIC.
Optimization Series:
Hardware Selection:
Platform Architecture:
Performance:
FPGAs have high per-unit cost ($5–$200) and high power consumption compared to equivalent ASICs. At volumes above 100K units, a custom ASIC almost always has lower total cost. Using an FPGA without volume break-even analysis leads to unexpectedly high product cost at scale.
Replacing the CPU with a faster processor doesn’t help if the bottleneck is memory bandwidth — data can’t reach the processor fast enough. Profile memory access patterns before upgrading compute hardware; cache optimization or DMA may provide bigger gains.
Switching between big and LITTLE cores in ARM architectures has migration latency (10–100 µs) and requires OS support. Frequent workload switching can create overhead that negates energy savings. Profile actual workload variability before relying on big.LITTLE for energy efficiency.
Datasheets advertise peak MIPS/GFLOPS achieved under ideal conditions. Real workloads with data-dependent branches, cache misses, and I/O wait achieve 20–50% of peak. Always benchmark your actual algorithm on candidate hardware before making selection decisions.
| If you want to… | Read this |
|---|---|
| Apply compiler flags and firmware optimizations | Software Optimization |
| Implement fixed-point arithmetic | Fixed-Point Arithmetic |
| Learn optimization principles and measurement | Optimization Fundamentals |
| See complete hardware/software optimization overview | Hardware & Software Optimisation |
| Understand how operations cost energy | Energy Cost of Common Operations |