Project 15: Peripheral Atlas - Pin Multiplexing and Conflicts

Create a pin multiplexing atlas that documents peripheral conflicts and pin capabilities.

Quick Reference

Attribute Value
Difficulty Level 2: Intermediate
Time Estimate 10-15 hours
Main Programming Language N/A (documentation project)
Alternative Programming Languages N/A
Coolness Level Level 3: Genuinely Clever
Business Potential 2. The “Design” Model
Prerequisites C/C++ basics, Teensyduino setup, basic electronics, ability to use a multimeter/logic analyzer
Key Topics pin muxing, conflict planning, documentation

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)

Pin Multiplexing Planning and Conflict Resolution

Fundamentals Pin multiplexing is the mapping between internal peripheral signals and external pins. Conflicts are inevitable because there are more functions than pins. Planning requires a matrix of required peripherals, candidate pins, and conflicts so hardware and firmware can coexist. This project turns the pin map into a reusable design artifact.

Deep Dive into the concept The IOMUX controller routes internal signals to pins. Each pin can serve multiple functions, but only one at a time. The planning problem is combinatorial: UART, SPI, I2C, PWM, ADC, and USB all compete for pins. A pin atlas resolves this by documenting possible functions per pin, conflicts, and recommended assignments. A good planning workflow assigns critical signals first, reserves flexible pins for later, and documents constraints. Validation with real hardware prevents mistakes: toggle pins, verify alternate functions, and confirm electrical limits. This project produces a conflict-aware atlas that prevents late-stage rewiring.

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

Definitions & key terms

  • IOMUX: Pin multiplexing controller that routes signals to pins.
  • ALT function: Alternate function assigned to a pin.
  • Conflict: Two required functions that cannot share a pin.
  • Pin atlas: Documentation of pin capabilities and conflicts.

Mental model diagram (ASCII)

Peripheral signals -> IOMUX -> Pin matrix -> Wiring plan

How it works (step-by-step)

  1. List required peripherals and signals.
  2. Map candidate pins and note alternate functions.
  3. Mark conflicts and choose final assignments.
  4. Validate assignments with a simple GPIO test.

Minimal concrete example

Pin 10: PWM1 / SPI1_MOSI
Pin 11: PWM2 / SPI1_MISO

Common misconceptions

  • Pin conflicts can be resolved later in software.
  • All PWM pins are interchangeable.
  • If it fits on a breadboard, it will scale.

Check-your-understanding questions

  • How do you prioritize pin assignments?
  • What is the risk of ignoring alternate functions?
  • How do you document conflicts for future projects?

Check-your-understanding answers

  • Assign critical signals first and reserve flexible pins.
  • You may lose access to a needed peripheral later.
  • Use a spreadsheet or diagram with clear labels.

Real-world applications

  • Custom PCB design
  • Multi-peripheral prototypes
  • System integration planning

Where you’ll apply it

References

  • Teensy 4.x pinout card
  • i.MX RT1062 IOMUX tables

Key insights

Pin planning is system design, not just wiring.

Summary

A pin atlas prevents late-stage conflicts in complex builds.

Homework/Exercises to practice the concept

  • Create a pin map for SPI + I2C + PWM and mark conflicts.
  • Validate at least two pins with GPIO toggles.

Solutions to the homework/exercises

  • Use the pinout card to create a table and check overlaps.
  • Write a small sketch to toggle candidate pins.

3. Project Specification

3.1 What You Will Build

Create a pin multiplexing atlas that documents peripheral conflicts and pin capabilities.

3.2 Functional Requirements

  1. List all pin functions for Teensy 4.x.
  2. Identify conflicts for UART/I2C/SPI/PWM/ADC.
  3. Create reusable pin planning matrix.
  4. Validate at least 5 pins with real measurements.

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

./P15-peripheral-atlas-pin-multiplexing-and-conflicts --run

3.5 Data Formats / Schemas / Protocols

Spreadsheet/CSV with columns: pin, function, conflict_notes

3.6 Edge Cases

  • Pin has multiple alternate functions
  • Special pins reserved for USB/boot
  • Analog-only pins used for digital

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
./P15-peripheral-atlas-pin-multiplexing-and-conflicts --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

$ ./P15-peripheral-atlas-pin-multiplexing-and-conflicts --run --seed 42
[INFO] Peripheral Atlas - Pin Multiplexing and Conflicts starting
[INFO] Report saved to data/report.csv
[INFO] Status: OK
$ echo $?
0

Failure Demo (Deterministic)

$ ./P15-peripheral-atlas-pin-multiplexing-and-conflicts --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

“How do I prevent pin conflicts before they happen?”

5.4 Concepts You Must Understand First

Stop and research these before coding:

  1. pin muxing, conflict planning, documentation
  2. Data logging and measurement techniques
  3. Basic timing math and error analysis

5.5 Questions to Guide Your Design

  1. Which peripherals are mandatory?
  2. Which pins are flexible vs fixed?
  3. How will you document conflicts?

5.6 Thinking Exercise

Assign pins for SPI, I2C, and PWM without conflicts.

5.7 The Interview Questions They’ll Ask

  1. What is pin multiplexing?
  2. How do you resolve pin conflicts?
  3. Why document pin assignments?

5.8 Hints in Layers

  • Start with official pinout tables.
  • Use color coding for conflicts.
  • Validate a subset with real toggles.

5.9 Books That Will Help

| Topic | Book | Chapter | |——-|——|———| | Architecture | Making Embedded Systems | Ch. 1 | | Planning | Embedded Systems Design | Ch. 2 | | MCU manuals | i.MX RT1062 RM | Pin mux tables |

5.10 Implementation Phases

Phase 1: Foundation (4 hours)

Goals:

  • Extract pin data
  • Build initial table

Tasks:

  1. Extract pin data
  2. Build initial table

Checkpoint: Pin table created

Phase 2: Core Functionality (6 hours)

Goals:

  • Add conflicts
  • Validate with hardware

Tasks:

  1. Add conflicts
  2. Validate with hardware

Checkpoint: Atlas usable

Phase 3: Polish (3 hours)

Goals:

  • Create templates
  • Publish documentation

Tasks:

  1. Create templates
  2. Publish documentation

Checkpoint: Final atlas

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}