Project 24: Hardware Expansion Rig (I2S Codec + SPI DMA Display + Sensor Fusion)

Build a multi-bus expansion platform on NeoTrellis M4 that keeps audio/control real-time guarantees while driving external peripherals.

Quick Reference

Attribute Value
Difficulty Level 5: Master
Time Estimate 3-4 weeks
Main Programming Language C/C++
Alternative Programming Languages Bare-metal C (subset)
Coolness Level Level 5: The “WTF, That’s Possible?”
Business Potential 3. The “Open Core”
Prerequisites SPI/I2C basics, DMA concepts, digital audio interfaces
Key Topics DMA SPI display, I2S codec integration, sensor fusion scheduling, bus arbitration

1. Learning Objectives

By completing this project, you will:

  1. Integrate an external I2S codec with stable clocking.
  2. Implement DMA-driven SPI display updates with dirty-region strategy.
  3. Add sensor-fusion loop with bounded compute cost.
  4. Design bus-priority policy that protects real-time control/audio paths.
  5. Prove multi-bus stability with long-run stress telemetry.

2. All Theory Needed (Project-Scoped)

2.1 Multi-Bus Contention

Adding peripherals multiplies contention and schedule complexity; priority policy becomes mandatory.

2.2 I2S Clock Domains

Clock role configuration and synchronization determine audio stability.

2.3 SPI Display Throughput

Full-screen redraws are expensive; DMA dirty-region updates preserve responsiveness.

2.4 Sensor Fusion Scheduling

Fusion quality depends on timing consistency and calibrated data, not only algorithm choice.

2.5 Graceful Degradation

When overloaded, degrade display and noncritical work before audio/control quality.

3. Project Specification

3.1 What You Will Build

A hardware expansion profile that runs:

  • external I2S audio codec
  • SPI DMA display renderer
  • sensor-fusion control stream
  • real-time control and LED feedback

3.2 Functional Requirements

  1. Stable audio path through external codec.
  2. Display updates executed via DMA and bounded frame budget.
  3. Sensor fusion updates at configured periodic rate.
  4. Unified telemetry for bus latency and deadline misses.

3.3 Non-Functional Requirements

  • Performance: no audio underruns in stress mode.
  • Reliability: bounded control-loop latency under visual load.
  • Maintainability: explicit bus-priority and degrade policy docs.

3.4 Real World Outcome

$ expansion_rig_benchmark --duration 180s
[I2S] rate=48000 underruns=0 drift_ppm=3.2
[SPI] fps=57.8 frame_dma_ms_avg=2.9 full_redraws=0
[FUSION] rate_hz=100 dropped_samples=0
[RT] control_loop_p99_us=930
PASS: multi-bus integration stable

4. Solution Architecture

4.1 High-Level Design

Input events --> control scheduler --> audio engine --> I2S codec
                               |--> display scheduler --> SPI DMA renderer
                               |--> sensor scheduler --> fusion stage

4.2 Key Components

Component Responsibility Key Decision
Audio path render and stream to I2S audio highest bus priority
Display path visual UI refresh dirty-region DMA, capped frame budget
Sensor path acquisition + fusion fixed-rate update with bounded compute
Arbitration policy protect critical tasks degrade display first under overload

4.3 Scheduling Policy (Pseudocode)

every 2.67 ms: audio block render + I2S refill
every 1 ms: control scan and event dispatch
every 10 ms: sensor fusion update
every 16.6 ms: display DMA dirty-region commit (if budget allows)

5. Implementation Guide

5.1 Phases

  1. Bring up I2S codec and verify clean tone output.
  2. Add SPI display DMA path with partial update engine.
  3. Add sensor read + fusion loop with timestamping.
  4. Integrate arbitration and overload policy; stress-test.

5.2 The Core Question You’re Answering

“Can one MCU coordinate multiple high-throughput peripherals without violating hard timing constraints?”

5.3 Questions to Guide Design

  1. Which transfers can overlap and which must serialize?
  2. How is overload detected and handled deterministically?
  3. What evidence proves core latency stayed bounded after expansion?

5.4 Thinking Exercise

Write an overload timeline showing what happens when display workload spikes while full polyphony audio and sensor fusion are active.

5.5 Interview Questions They Will Ask

  1. How do you prevent display rendering from glitching audio?
  2. What are the failure signs of I2S clock mismatch?
  3. How do you schedule sensor fusion without starving control loops?
  4. What bus metrics reveal saturation early?
  5. Why is graceful degradation a systems requirement?

5.6 Hints in Layers

  • Hint 1: Stabilize audio path before adding visuals.
  • Hint 2: Use dirty regions; avoid full redraw loops.
  • Hint 3: Timestamp sensor data for consistent fusion timing.
  • Hint 4: Instrument DMA wait time and queue occupancy.

5.7 Common Pitfalls and Debugging

Problem Why Fix Quick Test
Audio pops during animations blocking SPI updates shift to DMA and frame budget limits animate full UI while playing audio
Control lag spikes noncritical tasks overrun throttle display/fusion rate monitor control p99 latency
Drift artifacts I2S clock configuration mismatch align master/slave roles and clocks long sine stability test

5.8 Definition of Done

  • 30-minute stress run with no audio underruns.
  • Control-loop p99 latency meets target.
  • Display path uses DMA partial updates only.
  • Sensor-fusion loop runs at stable, documented rate.

6. References