Project 2: GPIO Map and Alternate-Function Explorer

A verified pin capability map that documents usable pins and proves alternate-function routing with hardware tests.

Quick Reference

Attribute Value
Difficulty Level 1: Beginner
Time Estimate 1-2 weeks
Main Programming Language C (Alternatives: C++, Rust, Ada)
Alternative Programming Languages C++, Rust, Ada
Coolness Level Level 3: Genuinely Clever
Business Potential 1. The “Resume Gold”
Prerequisites GPIO basics, reading datasheets, simple UART logs
Key Topics GPIO modes, alternate functions, board schematic reading

1. Learning Objectives

By completing this project, you will:

  1. Build a constraint-aware pin map for the STM32F3DISCOVERY.
  2. Configure and validate at least three alternate functions on hardware.
  3. Resolve pin conflicts using datasheet and schematic evidence.
  4. Create a reusable GPIO/AF checklist for new projects.

2. All Theory Needed (Per-Concept Breakdown)

GPIO Modes and Alternate Functions (Pin Multiplexing)

Fundamentals GPIO is the MCU’s physical interface to the outside world. Each pin can be configured as input, output, analog, or alternate function. Alternate function routes internal peripheral signals (UART, SPI, timers, etc.) to the pin. On STM32, a pin can support multiple alternate functions, but only one can be active at a time. A correct GPIO configuration must include mode, pull-up/pull-down, output type, speed, and alternate function selection. Misconfiguring any of these leads to silent failure, which is why a pin map validation project is essential.

Deep Dive into the concept The STM32 GPIO subsystem is both electrical and logical. Electrically, you choose input or output driver types (push-pull or open-drain), internal pulls, and slew rate. Logically, you choose whether the pin is GPIO-controlled or assigned to a peripheral. These decisions interact: for example, I2C requires open-drain outputs with pull-ups, while SPI requires push-pull. Alternate functions are selected via the AFR registers, which are split into low and high halves for pins 0-7 and 8-15. Each pin can have up to 16 alternate function mappings (AF0-AF15), and the mapping is defined in the datasheet’s AF table. You cannot infer AF numbers; you must consult the table. Additionally, some pins are already occupied on the discovery board by LEDs, sensors, or the ST-LINK interface. That means your pin map must include board-level constraints, not just MCU capability. A thorough pin map process starts with the board schematic, identifies which pins are routed to headers, and then annotates each with possible peripheral functions and conflicts. You should then validate at least one alternate function per peripheral class with a visible effect: UART TX should print, a timer channel should output PWM, and an ADC input should show a voltage change. This validation proves that your clock, GPIO configuration, and pin selection are all correct. It also trains you to resolve conflicts: if two peripherals want the same pin, you must choose a different mapping or a different peripheral instance. In real products, pin mux decisions are architectural: they affect board layout, firmware flexibility, and even BOM cost. By building a pin map and verifying functions, you practice the exact process used in professional embedded hardware bring-up.

How this fit on projects In GPIO Map and Alternate-Function Explorer, you document and verify a pin map that includes GPIO modes, alternate functions, and board-level conflicts.

Definitions & key terms

  • Push-pull -> Output driver actively drives high and low; strong drive for digital outputs.
  • Open-drain -> Output can only pull low; requires pull-up for high.
  • Alternate function -> Pin routing selection for peripheral signals.
  • Slew rate -> Output transition speed setting that affects EMI and signal integrity.
  • Pin mux -> The multiplexer that selects which internal signal appears on a pin.

Mental model diagram (ASCII)

[Peripheral A]--
           >--[Pin MUX]--> Pin PA9
[Peripheral B]--/
             (select AF mapping)

How it works (step-by-step, with invariants and failure modes)

  1. Identify required peripherals and candidate pins from the datasheet.
  2. Check board schematic for pins already used by LEDs, sensors, or debug interfaces.
  3. Configure GPIO mode, pull, speed, and alternate function for each selected pin.
  4. Validate each mapped pin by creating a physical or observable signal.
  5. Invariant: each pin has a single active function; failure mode: silent conflicts or wrong AF number.

Minimal concrete example

// Configure PA9 as USART1_TX (AF7)
GPIOA->MODER |= (2 << (9 * 2));
GPIOA->AFR[1] |= (7 << ((9 - 8) * 4));

Common misconceptions

  • Any pin can be mapped to any peripheral ignores fixed AF tables.
  • GPIO defaults are safe ignores that pins may power up in analog mode.
  • If a pin works once, it is always correct ignores board-level conflicts and alternate mappings.

Check-your-understanding questions

  1. Why does I2C require open-drain outputs?
  2. How do you find the correct AF number for a pin?
  3. What symptoms indicate that a pin conflict exists?

Check-your-understanding answers

  1. I2C uses wired-AND signaling where multiple devices pull the line low, requiring open-drain drivers and pull-ups.
  2. Consult the datasheet’s alternate function table for that specific pin and peripheral.
  3. Signals appear on the wrong pin, remain stuck, or multiple peripherals stop working when enabled together.

Real-world applications

  • Board bring-up and pin validation in new hardware.
  • Multi-peripheral embedded devices with strict pin budgets.
  • Signal integrity tuning by selecting appropriate slew rates.

Where you’ll apply it

References

  • STM32F3 Reference Manual (GPIO and AF registers).
  • STM32F3DISCOVERY board schematic (pin usage).
  • Joseph Yiu, ‘The Definitive Guide to ARM Cortex-M3/M4’ (I/O configuration).

Key insights

  • Pin muxing is an architectural choice; you must prove it with hardware behavior, not just code.

Summary GPIO configuration ties firmware to the physical board. Correct alternate-function selection, electrical mode, and board-level awareness are what turn a schematic into a working product.

Homework/Exercises to practice the concept

  1. Create a pin map table for 10 pins and include at least two alternate functions each.
  2. Verify one UART TX pin and one timer channel on hardware.
  3. Identify two pins that cannot be used because of on-board sensors.

Solutions to the homework/exercises

  1. A valid pin map includes port, pin, AF number, peripheral, and board conflict notes.
  2. UART TX can be verified by printing a known string at 115200 baud.
  3. On-board MEMS sensors occupy dedicated I2C/SPI pins; consult the schematic to identify them.

Board Schematic Reading and Pin Constraints

Fundamentals A datasheet tells you what the MCU can do, but the board schematic tells you what you can actually use. The STM32F3DISCOVERY connects LEDs, sensors, and debug interfaces to specific pins. Those pins are no longer ‘free’ for arbitrary functions. Reading the schematic lets you see which nets go to headers, which are tied to components, and which are shared. A pin map is only correct when it accounts for these board constraints.

Deep Dive into the concept A schematic is a connectivity map, not just a drawing. Each symbol connects to nets that represent electrical nodes, and each net corresponds to a MCU pin or off-board connector. When you read a board schematic, you trace a pin to see all the components attached to it. If a pin drives an LED through a resistor, you know it has a load and might be shared with a timer output. If a pin connects to an accelerometer, you know that I2C or SPI peripheral is already in use. The STM32F3DISCOVERY uses a dedicated ST-LINK interface that can occupy SWD pins and sometimes UART pins for virtual COM. Schematic reading also reveals power domains: which pins are powered at 3.3 V, which are analog, and how ground is routed. This matters because analog performance depends on low-noise grounding and clean Vref pins. By combining the schematic with the datasheet, you can build a pin constraint table. This table contains each pin, its board usage, any alternate functions available, and the conflicts. In real projects, this process informs both firmware and hardware decisions. If you need an extra PWM output but all timer channels are used by LEDs, you must choose a different timer, reroute on hardware, or change the product requirement. The key is to treat the board as a fixed system with constraints, not a blank MCU. In the context of the STM32F3DISCOVERY, a simple example is the user LEDs on port E: they are easy to use for status, but they also consume GPIOs and timer channels. If you plan to use PWM or advanced timers, you must cross-reference those pins. Thus, schematic reading is not a separate activity; it is a part of reliable firmware design.

How this fit on projects In GPIO Map and Alternate-Function Explorer, you trace board nets to understand which pins are usable and which are already assigned to onboard hardware, then verify those decisions in firmware.

Definitions & key terms

  • Net -> An electrical connection that ties multiple pins together.
  • Header -> A connector that exposes MCU pins for external use.
  • Pull-up resistor -> A resistor that biases a line high when not actively driven.
  • Load -> Anything attached to a pin that draws current or affects signal integrity.
  • Constraint -> A limitation imposed by board routing or attached components.

Mental model diagram (ASCII)

MCU Pin -> Net -> (LED + Resistor) -> GND
    -> Net -> Header Pin
(two loads share one MCU pin)

How it works (step-by-step, with invariants and failure modes)

  1. Open the board schematic and locate the MCU pinout page.
  2. Trace each pin of interest to see which nets and components it connects to.
  3. Mark pins that are shared with sensors, LEDs, or debug interfaces.
  4. Build a constraint-aware pin map that lists usable pins and conflicts.
  5. Invariant: each firmware pin decision matches the board wiring; failure mode: conflicts with onboard components.

Minimal concrete example

// Example pin map entry
// PE8: LED3 -> TIM1_CH1 possible, but LED load affects PWM brightness
// PA13/PA14: SWD -> reserved for debug

Common misconceptions

  • If the MCU datasheet lists it, I can use it ignores board wiring constraints.
  • LED pins are always free ignores timer channel sharing and current load.
  • Debug pins are optional ignores the need for SWD during development.

Check-your-understanding questions

  1. Why might a PWM output on an LED pin distort a sensor signal?
  2. How can the ST-LINK interface restrict your pin choices?
  3. What is the first step in creating a constraint-aware pin map?

Check-your-understanding answers

  1. Because the LED and resistor create an electrical load and can inject noise or limit voltage swing.
  2. ST-LINK uses SWD pins and sometimes a UART bridge, which reserves those pins.
  3. Start with the board schematic to identify which pins are already connected to components.

Real-world applications

  • Early-stage board bring-up when peripherals do not respond.
  • Pin budget planning in resource-constrained designs.
  • Avoiding electrical conflicts in mixed-signal systems.

Where you’ll apply it

References

  • STM32F3DISCOVERY board schematic (net mapping).
  • ‘Practical Electronics for Inventors’ (basic schematic reading).
  • ST application notes on board bring-up and pin multiplexing.

Key insights

  • The board schematic is your ground truth for what pins are truly available.

Summary You cannot assign pins from the datasheet alone. The schematic tells you what the board already uses, and a correct firmware design respects those constraints.

Homework/Exercises to practice the concept

  1. Identify three pins that are reserved by ST-LINK or sensors.
  2. Find one pin that is routed to a header and list two possible alternate functions.
  3. Document the power rail connected to the analog pins.

Solutions to the homework/exercises

  1. SWD pins and sensor bus pins are typically reserved; confirm in the schematic.
  2. A header pin might support UART or timer functions; confirm using the AF table.
  3. Analog pins share AVDD/AGND rails; note the decoupling components shown in the schematic.

Clock Tree, PLL, and Prescalers (System Timing Backbone)

Fundamentals Every peripheral timing and every delay in your firmware depends on the clock tree. The STM32F3 can run from internal or external oscillators, and uses a PLL to multiply those sources to reach the desired system clock. From that system clock, prescalers divide down to generate the AHB, APB1, and APB2 bus clocks, which in turn feed timers, ADCs, UARTs, and other peripherals. If you misconfigure any divider, you will see subtle failures: UART baud errors, PWM drift, incorrect ADC sampling, and watchdog timeouts. A clock tree audit is the practice of proving, with measurements, that your configured frequencies match reality. It is the single most valuable habit for embedded reliability.

Deep Dive into the concept The STM32F3 clock system is a directed graph of sources, multipliers, and dividers. At the root are the HSI (internal RC oscillator) and HSE (external crystal or clock). The PLL takes one of those sources and applies multiplication factors to produce a higher-frequency output used as the system clock. On STM32 devices, the system clock (SYSCLK) feeds the AHB bus, while APB1 and APB2 buses are derived by additional prescalers. Timers on APB buses often have a ‘x2’ effect when the prescaler is not 1, which means timer clocks can be double the APB frequency. If you forget that rule, PWM frequencies are off by exactly 2x, a classic bring-up trap. The clock tree is also linked to power: higher frequencies increase current draw, and some peripherals require specific clock ranges. USB and ADCs, for example, require precise clocks to meet protocol or sampling accuracy requirements. The RCC (Reset and Clock Control) registers configure all of this. A good audit reads those registers at runtime and recomputes derived clocks, then compares expected timing (based on configuration) to observed timing (based on measurement). Measurement can be as simple as toggling a GPIO at a known rate and timing it with a stopwatch, or as precise as using a logic analyzer to measure a timer output. A thorough audit includes the SysTick frequency, timer tick frequency, and peripheral baud rate verification. There are also failure modes: the external crystal may not start, the PLL may fail to lock, or the clock security system may switch back to HSI without warning. In robust firmware, you detect and log these events. The clock tree is therefore not just a setup routine, but an operational dependency that must be measured. When you develop on the STM32F3DISCOVERY, you should record expected frequencies, read RCC_CFGR to confirm clock sources, and validate at least one timer output. This practice makes you immune to the most common cause of ‘mystery bugs’ in embedded projects: silent timing errors.

How this fit on projects In GPIO Map and Alternate-Function Explorer, you audit the clock tree by reading RCC configuration, computing derived clocks, and validating time with measured outputs (LEDs, timers, or UART).

Definitions & key terms

  • HSI -> Internal high-speed oscillator, convenient but less accurate.
  • HSE -> External crystal oscillator, more accurate but requires hardware.
  • PLL -> Phase-Locked Loop that multiplies an input frequency.
  • SYSCLK -> System clock feeding the CPU core.
  • AHB/APB -> Buses that distribute clocks to memory and peripherals.

Mental model diagram (ASCII)

HSI/HSE -> PLL -> SYSCLK -> AHB -> APB1/APB2 -> Peripherals
         |                |            |
       prescalers       timers       UART/ADC

How it works (step-by-step, with invariants and failure modes)

  1. Select a clock source (HSI or HSE) and enable it.
  2. Configure PLL multipliers/dividers to reach target SYSCLK.
  3. Set AHB/APB prescalers to keep peripherals within spec.
  4. Validate that timers and UARTs use the expected derived clocks.
  5. Invariant: All configured clocks must be within device limits; failure mode: peripheral timing mismatch or PLL unlock.

Minimal concrete example

// Pseudocode: compute SYSCLK from RCC registers
uint32_t sysclk = rcc_get_sysclk();
uint32_t hclk = sysclk / ahb_prescaler();
uint32_t pclk1 = hclk / apb1_prescaler();
printf("SYSCLK=%lu HCLK=%lu PCLK1=%lu\n", sysclk, hclk, pclk1);

Common misconceptions

  • If SYSCLK is correct, peripherals are correct ignores bus prescalers and timer x2 behavior.
  • HSI is good enough for all peripherals ignores baud accuracy and ADC sampling constraints.
  • PLL always locks ignores startup and clock security failures.

Check-your-understanding questions

  1. Why can a timer run at twice the APB clock on STM32?
  2. How would you detect that the HSE crystal failed to start?
  3. What is the difference between SYSCLK and HCLK?
  4. Why does UART baud depend on clock prescalers?

Check-your-understanding answers

  1. When APB prescaler is not 1, timer clocks are doubled to preserve timer resolution.
  2. Check RCC flags for HSE ready or clock security events and log a fallback to HSI.
  3. SYSCLK feeds the core; HCLK is SYSCLK after the AHB prescaler.
  4. UART divider is computed from the peripheral clock; a mismatch shifts baud rate.

Real-world applications

  • Motor control where PWM frequency accuracy matters.
  • Precision sensing with ADC sampling rate requirements.
  • Communication interfaces that need accurate baud rates.

Where you’ll apply it

References

  • STM32F3 Reference Manual (RCC chapter).
  • Joseph Yiu, ‘The Definitive Guide to ARM Cortex-M3/M4’ (system clocking).
  • Elecia White, ‘Making Embedded Systems’ (timing and measurement).

Key insights

  • If you cannot measure your clock tree, you cannot trust any timing claim in your system.

Summary Clock configuration is a system-wide contract. A small prescaler mistake can propagate into every peripheral. A clock audit makes timing visible and protects you from silent configuration errors.

Homework/Exercises to practice the concept

  1. Compute expected timer tick rates for APB1 and APB2 given a target SYSCLK.
  2. Toggle a GPIO every 1000 SysTick ticks and measure the period with a stopwatch.
  3. Force a fallback to HSI and log the resulting SYSCLK change.

Solutions to the homework/exercises

  1. Use the RCC_CFGR register to determine prescalers and apply the x2 rule for timers.
  2. 1,000 ticks at 1 kHz should be 1 second; if not, check SysTick reload value.
  3. When HSE fails, the system clock source bit will indicate HSI; log the event over UART.

3. Project Specification

3.1 What You Will Build

A pin capability document and verification firmware that maps each usable pin to its alternate functions, and proves at least three functions (UART TX, timer PWM, ADC input) via visible outputs.

3.2 Functional Requirements

  1. Pin Map Table: List at least 20 pins with GPIO mode, AF options, and board conflicts.
  2. AF Verification: Demonstrate at least three alternate functions with physical evidence.
  3. Conflict Resolution: Document conflicts with onboard sensors and LEDs.
  4. Repeatable Test Harness: Provide firmware that can be run to validate pins on demand.

3.3 Non-Functional Requirements

  • Performance: AF validation should complete in under 1 minute with clear outputs.
  • Reliability: Pin map must match actual board wiring.
  • Usability: Documentation must be readable by another engineer without guesswork.

3.4 Example Usage / Output

PA9: USART1_TX -> verified (serial output)
PA8: TIM1_CH1  -> verified (PWM on LED)
PA1: ADC1_IN2  -> verified (analog read changes)
Status: 3/3 functions confirmed

3.5 Data Formats / Schemas / Protocols

Pin map row format:

  • PIN, GPIO_MODE, AF_LIST, BOARD_USE, VERIFIED Example: PA9, AF, [USART1_TX, TIM1_CH2], STLINK_VCP, YES

3.6 Edge Cases

  • Pin used by sensor conflicts with desired peripheral.
  • Alternate function number is incorrect in code.
  • GPIO clock for a port is not enabled.
  • Pin configured as analog so digital output fails.

3.7 Real World Outcome

You will have a documented pin map and a verification firmware that proves routing decisions.

3.7.1 How to Run (Copy/Paste)

$ make flash
$ screen /dev/tty.usbmodem* 115200

3.7.2 Golden Path Demo (Deterministic)

  • Run the firmware and observe UART output, PWM LED brightness, and ADC change with a potentiometer.

3.7.3 CLI Transcript (Success)

$ screen /dev/tty.usbmodem* 115200
PINMAP_OK
PA9 USART1_TX VERIFIED
PA8 TIM1_CH1 VERIFIED
PA1 ADC1_IN2 VERIFIED
RESULT=PASS
# Exit code: 0

3.7.4 Failure Demo (Bad AF)

  • Configure PA9 with wrong AF number.
$ screen /dev/tty.usbmodem* 115200
PA9 USART1_TX FAILED (no output)
RESULT=FAIL
# Exit code: 2

4. Solution Architecture

The solution is a pin map document plus a validation firmware that exercises alternate functions with observable outputs.

4.1 High-Level Design

Pin Map Doc -> Firmware Test Harness -> Physical Verification

4.2 Key Components

Component Responsibility Key Decisions
Pin Map Table Records pin capabilities and conflicts Use schematic as ground truth
AF Configurator Initializes GPIO and AF registers Manual register setup for clarity
Verification Outputs UART/PWM/ADC validation Pick outputs with visible effects

4.3 Data Structures (No Full Code)

typedef struct {
const char* pin;
const char* af_list;
const char* board_use;
uint8_t verified;
} pinmap_entry_t;

4.4 Algorithm Overview

Pin Validation Loop

  1. Configure pin for target AF.
  2. Trigger peripheral action (send UART, PWM toggle, ADC read).
  3. Record pass/fail.

Complexity Analysis: O(N) for N pins.

5. Implementation Guide

5.1 Development Environment Setup

make init
make flash
screen /dev/tty.usbmodem* 115200

5.2 Project Structure

project-root/
|-- src/
|   |-- main.c
|   |-- pinmap.c
|   `-- af_verify.c
|-- docs/
|   `-- pinmap.csv
`-- README.md

5.3 The Core Question You’re Answering

“How do I know which pins can actually do the job I want?”

5.4 Concepts You Must Understand First

  1. GPIO Modes
    • Input vs output vs analog vs alternate
  2. Alternate Functions
    • AF numbers and datasheet tables
  3. Schematic Reading
    • Trace pins to board components

5.5 Questions to Guide Your Design

  1. Which pins are exposed on headers vs reserved on-board?
  2. Which alternate functions overlap on the same pin?
  3. How will you verify each function without special tools?

5.6 Thinking Exercise

Pin Conflict Resolution

Peripheral A -> Pin X or Pin Y
Peripheral B -> Pin Y or Pin Z
Peripheral C -> Pin X or Pin Z
Decision: choose Pin Y for B, Pin Z for C, Pin X for A

5.7 The Interview Questions They’ll Ask

  1. Explain alternate-function GPIO and why it matters.
  2. How do you resolve pin conflicts in an MCU design?
  3. What is the difference between open-drain and push-pull?

5.8 Hints in Layers

Hint 1: Start with the LED pins on Port E. Hint 2: Map one UART and verify TX output. Hint 3: Verify at least one ADC input with a known voltage.

5.9 Books That Will Help

Topic Book Chapter
GPIO config Making Embedded Systems Ch. 5
Pin muxing Definitive Guide to ARM Cortex-M Ch. 8

5.10 Implementation Phases

Phase 1: Pin Map Draft (2-3 days)

Build the table from datasheet and schematic.

Phase 2: AF Verification (3-5 days)

Implement test firmware for UART, PWM, ADC.

Phase 3: Conflict Resolution (2-3 days)

Document conflicts and final recommended pin assignments.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
AF selection Multiple AFs per pin Choose least-conflicted Avoid board collisions
Documentation CSV vs Markdown CSV + README Easy import to tools

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Validate AF mapping table CSV parser checks
Integration Tests Run AF verification firmware UART/PWM/ADC checks
Edge Case Tests Wrong AF or missing clock Deliberate misconfig

6.2 Critical Test Cases

  1. UART TX Pin: Serial output observed on correct pin.
  2. PWM Output: LED brightness changes with duty cycle.
  3. ADC Input: Voltage change reflected in log.

6.3 Test Data

PA9=USART1_TX (verified)
PA8=TIM1_CH1 (verified)
PA1=ADC1_IN2 (verified)

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
GPIO clock disabled Pin does not toggle Enable RCC for GPIO port
Wrong AF number Peripheral silent Verify AF mapping in datasheet
Board conflict Pin behaves unpredictably Check schematic for shared usage

7.2 Debugging Strategies

  • Toggle a known-good LED to confirm GPIO is alive.
  • Use a multimeter or logic analyzer to confirm pin activity.
  • Temporarily disable onboard sensors to isolate conflicts.

7.3 Performance Traps

Avoid initializing multiple peripherals on conflicting pins without documenting the conflict.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a CSV export for the pin map.
  • Verify one more alternate function (I2C or SPI).

8.2 Intermediate Extensions

  • Create a script that cross-references AF tables and generates a map.
  • Add a test mode to validate all GPIO outputs sequentially.

8.3 Advanced Extensions

  • Integrate pin map into a board support package generator.
  • Add electrical characteristics (drive strength, pull type) to the map.

9. Real-World Connections

9.1 Industry Applications

  • Custom embedded boards: Pin mux planning prevents rework and board respins.
  • Industrial automation: Precise pin assignment avoids wiring errors.
  • STM32CubeMX: Pin configuration and peripheral mapping tool.
  • Zephyr board definitions: Open-source pin mapping examples.

9.3 Interview Relevance

  • Pin multiplexing and GPIO configuration scenarios.
  • Conflict resolution in board design questions.

10. Resources

10.1 Essential Reading

  • Making Embedded Systems by Elecia White - GPIO and hardware integration basics.
  • Definitive Guide to ARM Cortex-M by Joseph Yiu - GPIO and peripheral configuration.

10.2 Video Resources

  • STM32 pin multiplexing demo - ST community video.
  • GPIO configuration basics - embedded tutorials.

10.3 Tools & Documentation

  • STM32CubeIDE: Firmware build and flash.
  • Multimeter/Logic analyzer: Validate pin signals.

11. Self-Assessment Checklist

11.1 Understanding

  • I can read a schematic and trace MCU pins to components.
  • I can select a correct AF for a given peripheral.
  • I understand open-drain vs push-pull usage.

11.2 Implementation

  • Pin map includes conflicts and verified pins.
  • Three AF outputs verified on hardware.
  • Documentation is reproducible by another engineer.

11.3 Growth

  • I can justify each pin selection with evidence.
  • I can resolve a new pin conflict quickly.
  • I can explain the pin map in an interview.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Pin map created with at least 20 pins.
  • Three alternate functions verified.
  • Conflicts documented.

Full Completion:

  • Pin map exported to CSV and README.
  • Test harness covers all verified pins.

Excellence (Going Above & Beyond):

  • Automated pin map generator script added.
  • Expanded map includes electrical properties.