Project 7: SPI Throughput Bench - High-Speed Sensor Logger

Benchmark SPI throughput and reliability at high speeds while logging sensor data.

Quick Reference

Attribute Value
Difficulty Level 3: Advanced
Time Estimate 20-30 hours
Main Programming Language C++
Alternative Programming Languages C
Coolness Level Level 4: Hardcore Tech Flex
Business Potential 3. The “Service” Model
Prerequisites C/C++ basics, Teensyduino setup, basic electronics, ability to use a multimeter/logic analyzer
Key Topics SPI timing, throughput, DMA, signal integrity

1. Learning Objectives

By completing this project, you will:

  1. Explain the core question for this project in your own words.
  2. Implement the main workflow and validate it with measurements.
  3. Handle at least two failure modes and document recovery.
  4. Produce a deterministic report that matches hardware behavior.

2. All Theory Needed (Per-Concept Breakdown)

SPI Throughput, Mode Timing, and Signal Integrity

Fundamentals SPI is a synchronous full-duplex bus with clock, MOSI, MISO, and chip-select lines. Throughput depends on clock rate, transfer size, and overhead. At high speed, signal integrity and timing margins become the dominant failure modes. This project measures real throughput rather than assuming datasheet numbers.

Deep Dive into the concept SPI mode (CPOL/CPHA) defines when data is sampled. If the mode is wrong, data shifts or corrupts. At high clock rates, long wires or poor grounding cause ringing and timing violations. The fix is shorter wiring, better grounding, or slower clock. Throughput is not only clock rate; chip-select setup and inter-byte gaps add overhead, especially for small packets. DMA can improve throughput by removing CPU overhead, but DMA also uses bus bandwidth and can affect latency elsewhere. Measuring throughput across packet sizes and clock rates reveals the true system limit. This project builds a benchmark that logs bytes per second and error rate so you can choose stable operating points.

How this fit on projects This concept directly powers the implementation choices and validation steps in this project.

Definitions & key terms

  • CPOL/CPHA: Clock polarity/phase settings that define SPI mode.
  • Chip select: Signal that selects the active SPI slave.
  • Burst transfer: Back-to-back transfer without deasserting CS.
  • Signal integrity: Quality of the electrical waveform on a bus.

Mental model diagram (ASCII)

Master -> SCK/MOSI/MISO/CS -> SPI device

How it works (step-by-step)

  1. Set SPI mode and clock based on device datasheet.
  2. Transfer known patterns and verify data integrity.
  3. Benchmark throughput for multiple packet sizes.
  4. Record error rates and identify limiting factors.

Minimal concrete example

SPI.beginTransaction(SPISettings(24000000, MSBFIRST, SPI_MODE0));
SPI.transfer(buffer, len);
SPI.endTransaction();

Common misconceptions

  • Higher SPI clock always means higher throughput.
  • SPI has no need for error detection.
  • CS timing doesn’t matter if clock is correct.

Check-your-understanding questions

  • Why can a faster clock reduce throughput?
  • How do CPOL/CPHA affect sampling?
  • Why is burst size important?

Check-your-understanding answers

  • Errors or retries can reduce effective throughput at high speeds.
  • They determine which clock edge samples data.
  • Larger bursts reduce per-transfer overhead.

Real-world applications

  • High-speed sensors
  • Display controllers
  • External flash memory

Where you’ll apply it

References

  • SPI device datasheets
  • Making Embedded Systems, performance chapters

Key insights

Throughput is a measurement, not a promise from a datasheet.

Summary

SPI performance is limited by both firmware overhead and physical bus behavior.

Homework/Exercises to practice the concept

  • Measure throughput for 16B vs 1024B transfers.
  • Reduce clock until errors disappear and record threshold.

Solutions to the homework/exercises

  • Use timing logs to compute bytes/sec for each packet size.
  • Lower clock in steps and note when checksum errors stop.

3. Project Specification

3.1 What You Will Build

Benchmark SPI throughput and reliability at high speeds while logging sensor data.

3.2 Functional Requirements

  1. Transfer data at multiple SPI clock rates.
  2. Measure throughput and error rate for each rate.
  3. Log sensor frames to memory or SD.
  4. Generate a throughput vs error report.

3.3 Non-Functional Requirements

  • Performance: Meet the target timing/throughput for the project.
  • Reliability: Detect errors and recover without undefined behavior.
  • Usability: Provide clear logs and a repeatable workflow.

3.4 Example Usage / Output

./P07-spi-throughput-bench-high-speed-sensor-logger --run

3.5 Data Formats / Schemas / Protocols

CSV with columns: clock_hz, bytes_per_sec, error_rate

3.6 Edge Cases

  • Signal ringing at high clock
  • Chip select timing violations
  • CPU starvation under heavy SPI load

3.7 Real World Outcome

You will run the project and see deterministic logs and measurements that match physical hardware behavior.

3.7.1 How to Run (Copy/Paste)

cd project-root
make
./P07-spi-throughput-bench-high-speed-sensor-logger --run

3.7.2 Golden Path Demo (Deterministic)

Use a fixed input configuration and a known test signal. Capture output for 60 seconds and verify it matches expected values.

3.7.3 If CLI: exact terminal transcript

$ ./P07-spi-throughput-bench-high-speed-sensor-logger --run --seed 42
[INFO] SPI Throughput Bench - High-Speed Sensor Logger starting
[INFO] Report saved to data/report.csv
[INFO] Status: OK
$ echo $?
0

Failure Demo (Deterministic)

$ ./P07-spi-throughput-bench-high-speed-sensor-logger --run --missing-device
[ERROR] Device not detected
$ echo $?
2

4. Solution Architecture

4.1 High-Level Design

Inputs -> Acquisition -> Processing -> Output/Log

4.2 Key Components

Component Responsibility Key Decisions
Acquisition Configure peripherals and capture data Use stable clock settings
Processing Convert raw data to meaningful values Apply calibration/filters
Output/Log Emit reports and logs CSV for reproducibility

4.3 Data Structures (No Full Code)

struct Sample {
    uint32_t timestamp_us;
    uint32_t value;
    uint32_t flags;
};

4.4 Algorithm Overview

Key Algorithm: Measurement + Report

  1. Initialize hardware and verify configuration.
  2. Capture data and record timestamps.
  3. Compute metrics and write report.

Complexity Analysis:

  • Time: O(n) in samples
  • Space: O(n) for log storage

5. Implementation Guide

5.1 Development Environment Setup

# Arduino IDE + Teensyduino must be installed
# Optional CLI workflow
arduino-cli core update-index
arduino-cli core install teensy:avr

5.2 Project Structure

project-root/
├── src/
│   ├── main.ino
│   ├── hw_config.h
│   └── measurements.cpp
├── tools/
│   └── analyze.py
├── data/
│   └── samples.csv
└── README.md

5.3 The Core Question You’re Answering

“What is the real throughput of my SPI pipeline under load?”

5.4 Concepts You Must Understand First

Stop and research these before coding:

  1. SPI timing, throughput, DMA, signal integrity
  2. Data logging and measurement techniques
  3. Basic timing math and error analysis

5.5 Questions to Guide Your Design

  1. What packet size gives best throughput?
  2. How will you detect corrupted data?
  3. How will you separate bus errors from sensor errors?

5.6 Thinking Exercise

Compute theoretical throughput at 24 MHz and compare to measured.

5.7 The Interview Questions They’ll Ask

  1. How do CPOL/CPHA affect SPI sampling?
  2. Why can higher clock reduce reliability?
  3. What is burst mode?

5.8 Hints in Layers

  • Start at low speed and scale up gradually.
  • Use a checksum per frame to detect errors.
  • Shorten wiring to improve signal integrity.

5.9 Books That Will Help

| Topic | Book | Chapter | |——-|——|———| | SPI timing | Making Embedded Systems | Ch. 6 | | Digital signals | High-Speed Digital Design | Ch. 2 | | Embedded performance | Real-Time Concepts | Ch. 4 |

5.10 Implementation Phases

Phase 1: Foundation (6 hours)

Goals:

  • Build SPI transfer loop
  • Validate sensor data

Tasks:

  1. Build SPI transfer loop
  2. Validate sensor data

Checkpoint: Baseline throughput

Phase 2: Core Functionality (10 hours)

Goals:

  • Benchmark multiple speeds
  • Log errors

Tasks:

  1. Benchmark multiple speeds
  2. Log errors

Checkpoint: Throughput report

Phase 3: Polish (6 hours)

Goals:

  • Add DMA
  • Analyze signal integrity

Tasks:

  1. Add DMA
  2. Analyze signal integrity

Checkpoint: Final analysis

5.11 Key Implementation Decisions

| Decision | Options | Recommendation | Rationale | |———-|———|—————-|———–| | Buffering | Single buffer, double buffer | Double buffer | Avoids data loss during processing | | Logging format | CSV, binary | CSV | Human-readable while still scriptable | | Clock speed | Default, overclock | Default | Keeps peripherals in spec |

6. Testing Strategy

6.1 Test Categories

| Category | Purpose | Examples | |———-|———|———-| | Unit Tests | Validate math, parsing, and conversions | Timer math, CRC checks | | Integration Tests | Verify peripherals and pipelines | DMA -> buffer -> log | | Edge Case Tests | Handle boundary conditions | Brownout, missing sensor |

6.2 Critical Test Cases

{test_cases}

6.3 Test Data

Use a fixed test input pattern and record outputs to data/report.csv

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

| Pitfall | Symptom | Solution | |———|———|———-| {pitfalls}

7.2 Debugging Strategies

{debug_strats}

7.3 Performance Traps

Large buffers improve stability but increase latency. Measure both throughput and jitter to choose the right size.

8. Extensions & Challenges

8.1 Beginner Extensions

{ex_begin}

8.2 Intermediate Extensions

{ex_inter}

8.3 Advanced Extensions

{ex_adv}

9. Real-World Connections

9.1 Industry Applications

{industry_apps}

{open_source}

9.3 Interview Relevance

{interview_rel}

10. Resources

10.1 Essential Reading

{resources}

10.2 Video Resources

  • Embedded systems timing walkthrough (YouTube)
  • Teensy hardware deep dive (Conference talk)

10.3 Tools & Documentation

  • Teensyduino: Toolchain for Teensy boards
  • Logic Analyzer: Timing verification
  • Multimeter: Voltage and current measurement

{related_projects}

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain the main concept without notes.
  • I can explain why the measurements match (or do not match) expectations.
  • I understand at least one tradeoff made in this project.

11.2 Implementation

  • All functional requirements are met.
  • All critical test cases pass.
  • Logs and reports are reproducible.
  • Edge cases are handled.

11.3 Growth

  • I documented lessons learned.
  • I can explain this project in a job interview.
  • I identified one improvement for next iteration.

12. Submission / Completion Criteria

Minimum Viable Completion: {comp_min}

Full Completion: {comp_full}

Excellence (Going Above & Beyond): {comp_ex}