ArduCAM Driver on STM32H7

The problem

Capture frames from an ArduCAM over SPI, log them to an SD card, and stream metadata over UART — all at once, on one microcontroller, without dropping frames. The naive version (read a frame, write a frame, repeat) stalls: the CPU spends its life waiting on SPI, and the SD card’s unpredictable write latency blows the frame deadline.

What I built

I wrote the driver from scratch in C on an STM32H7. The capture path is DMA-driven with double-buffering: while DMA fills one buffer from the camera, the CPU drains the other to the SD card through FatFS and pushes frame metadata out over UART. The CPU never sits in a polling loop on the hot path.

Getting sustained throughput meant tuning the real constraints — SPI clock frequency against what the camera and board layout could honestly support, and DMA buffer sizes against the SD card’s write-burst behavior. Too-small buffers meant interrupt overhead; too-large meant the SD write couldn’t finish before the next swap.

Hardening

Cameras and SD cards fail in undignified ways, so every error path is explicit: timeouts on every SPI transaction, CRC checks on data, and retry mechanisms that recover the capture pipeline instead of wedging it. A pulled SD card degrades the system; it doesn’t hang it.

Validation

I validated frame timing with a logic analyzer on the SPI bus — measuring actual transfer windows and buffer-swap timing rather than trusting the firmware’s opinion of itself — and documented the test procedure so the results are reproducible by anyone on the team. The driver pattern (SPI + DMA double-buffering with concurrent storage and streaming) became a template we reused in the CanSat avionics.