Multi-Peripheral SPI Telemetry System
Bare-metal shared-bus SPI driver with a FreeRTOS telemetry pipeline on STM32F4
MCU
STM32F446RE
Bus
SPI1 @ 1 MHz · shared, multi-CS
Model
Producer / consumer + ISR
Safety
Timeout recovery · seq. validation
01Overview
A firmware-first project that builds a bare-metal SPI driver on the STM32F446RE capable of servicing multiple peripherals on a single shared bus, each with independent chip-select control, and wires it into a FreeRTOS telemetry pipeline that is resilient to peripheral faults.
The emphasis is on register-level control of the SPI peripheral and on safe, deterministic interaction between interrupt context and RTOS tasks.
02Problem Statement
Sharing one SPI bus across several peripherals requires careful chip-select arbitration and transaction handling so devices don't collide or stall the bus.
Telemetry systems must keep flowing even when a peripheral misbehaves. An unresponsive device or a dropped frame should be detected and recovered from, not allowed to hang the pipeline.
03Architecture
Driver: a bare-metal SPI driver configures SPI1 directly through its registers (CR1 and CR2) for a 1 MHz transfer rate, and drives full-duplex transactions under interrupt control. Each peripheral on the shared bus is addressed through its own chip-select line.
Pipeline: a FreeRTOS producer/consumer model moves data from the bus to the telemetry sink. The producer side runs from the SPI ISR, handing data to a queue with xQueueSendFromISR and yielding correctly with portYIELD_FROM_ISR; the consumer task drains the queue.
Fault handling: stale-data timeout detection, timeout-based recovery for unresponsive peripherals, and sequence-number validation for dropped-frame detection keep the stream trustworthy.
04Technical Challenges
Safe ISR-to-task handoff
Passing data from the SPI interrupt into FreeRTOS safely means using the FromISR API family: xQueueSendFromISR to enqueue and portYIELD_FROM_ISR to request a context switch on exit, so a higher-priority consumer can run immediately without violating the kernel's ISR contract.
NVIC priority configuration
Interrupts that call FreeRTOS APIs must sit at or below configMAX_SYSCALL_INTERRUPT_PRIORITY. NVIC priorities were configured to respect this requirement so kernel-aware ISRs interact with the scheduler safely.
Tolerating misbehaving peripherals
On a shared bus, one stuck device can stall everything. Stale-data timeouts, timeout-based recovery for unresponsive peripherals, and sequence-number validation for dropped frames make the pipeline fault-tolerant instead of fragile.
05Implementation Details
Register-level SPI driver
Implemented a bare-metal SPI driver supporting multiple peripherals on a shared bus with independent chip-select control. SPI1 is configured directly via CR1 and CR2 for a 1 MHz transfer rate, with interrupt-driven full-duplex transactions.
FreeRTOS telemetry pipeline
Built a producer/consumer telemetry pipeline on FreeRTOS. The producer enqueues from the SPI ISR using xQueueSendFromISR and portYIELD_FROM_ISR; a consumer task processes the stream.
Kernel-safe interrupt priorities
Configured NVIC priorities according to configMAX_SYSCALL_INTERRUPT_PRIORITY so any interrupt invoking FreeRTOS APIs does so within the supported priority band.
Fault detection and recovery
Implemented stale-data timeout detection, timeout-based recovery for unresponsive peripherals, and sequence-number validation to detect dropped frames.
06Key Engineering Decisions
Bare-metal over HAL
Configuring SPI1 at the register level (CR1/CR2) instead of relying on HAL gives precise control over transfer rate, framing, and interrupt behavior, and it demonstrates a working understanding of the peripheral itself.
Interrupt-driven, not polled
Full-duplex transactions run under interrupt control so the CPU isn't spinning on the bus, which keeps the RTOS responsive and the telemetry path efficient.
Designed for failure modes first
Timeouts, recovery, and sequence validation were treated as core features rather than add-ons, reflecting how real telemetry systems are judged on robustness, not just throughput.
07Future Improvements
- Add DMA-backed SPI transfers to reduce per-byte interrupt overhead.
- Expand the driver to arbitrate more peripherals with prioritized scheduling.
- Add a CRC-protected framing layer to the telemetry output.
- Instrument the pipeline with runtime statistics (queue depth, recovery counts).
08Media & Documentation
Visual documentation for this project. Placeholders below are reserved for assets being produced during development.
Open to opportunities
Seeking Fall 2026 embedded / firmware / hardware co-op.
If you're hiring for embedded, firmware, or hardware roles, I'd be glad to talk through my projects and how I work. The fastest way to reach me is email.
