SPI camera on a microcontroller: sizing frame transfer over SPI

You have a 2 MP camera module that talks SPI and a microcontroller to drive it. Before writing a line of acquisition code, one number decides the design: how long a frame takes to cross the wire. At a practical 20 MHz SPI clock, a 1920 × 1080 frame with 16-bit pixels needs about 1.9 s — half a frame per second. Still capture is therefore a workable project; video streaming is not. This guide gives you the frame-size and transfer-time formulas, a worked example you can retune to your own clock, the SRAM reality on a small MCU, and the bench measurement that confirms the link. If you are stuck earlier — the sensor will not probe, or the host tool errors on download — work through the SPI camera interface troubleshooting guide first, then come back to the math.

What you need

Four numbers size the link. Three come from the camera module and one from the microcontroller.

• Frame resolution in pixels: 1920 × 1080 for the 2 MP class this article sizes.
• Bytes per pixel on the wire: raw 8-bit, RGB565 at 2 bytes, or a compressed file size.
• The module's maximum SPI clock.
• The MCU's peripheral ceiling: on the popular 125 MHz families this is half the system clock, so 62.5 MHz on paper.

Real wiring rarely reaches the paper ceiling. Reported stable rates for one 125 MHz family sit near 25 MHz on real wiring, and pushing that family's core past 125 MHz drops its SPI ceiling to 24 MHz, because the peripheral clock source falls back to 48 MHz. A faster MCU does not automatically mean a faster link. You also want a DMA-capable SPI peripheral and a timer for timestamps: polling loops shed bytes at these rates, DMA does not.

The frame-size formula

MB below means a million bytes. Common frames at 16 bits per pixel:

If the module compresses on-chip, replace width × height × 2 with the file size it actually outputs. Compression moves the number by roughly an order of magnitude, so the wire format matters more than the sensor's megapixel rating.

The transfer-time formula

Standard SPI moves one bit per clock, so bytes per second are the clock divided by clocks per byte. The ideal is 8; many MCU SPI peripherals insert one dummy clock per byte on reads, which makes it 9 and costs 11%. Compute with 9 and treat 8 as the optimistic bound.

A published design note for a 40 MHz SPI link puts its ceiling at 40,000,000 ÷ 8 = 5.0 MB/s, with measured transfers at or below that. Raw ceilings at 8 clocks per byte: 10 MHz gives 1.25 MB/s, 20 MHz gives 2.5 MB/s, 62.5 MHz gives 7.8 MB/s. Data rate first, frame rate second — that ordering drives every interface, and the USB2 and 5 MP frame-rate math is this same calculation on a different wire.

Worked example: a 2 MP 1920 × 1080 frame at a 20 MHz SPI clock

The inputs, each with its basis:

• 1920 × 1080 pixels — the resolution of the 2 MP module class in question.
• 2 bytes per pixel — 16-bit pixel data, the format these modules deliver on a raw read.
• A 20 MHz SPI clock — below the 24 and 25 MHz ceilings reported for the 125 MHz microcontroller families, leaving margin for jumper wiring. Everything after this bullet says "this clock" for the same setting.
• 9 clocks per byte — one dummy clock per byte; the ideal of 8 is carried as a check.

The rule in words: divide the frame's bytes by the bytes per second the clock delivers; the quotient is seconds per frame. The arithmetic:

• frame_bytes = 1920 × 1080 × 2 = 4,147,200 bytes (4.15 MB)
• rate = 20,000,000 Hz ÷ 9 = 2,222,222 bytes/s (2.22 MB/s)
• transfer = 4,147,200 ÷ 2,222,222 = 1.87 s per frame
• ideal check = 4,147,200 ÷ 2,500,000 = 1.66 s
• frame rate = 1 ÷ 1.87 = 0.53 fps

The decision: one still every 1.87 s makes a workable stills machine — snap, drain, process, repeat. Video does not fit. Thirty fps needs 4,147,200 × 30 = 124,416,000 bytes/s, about 124 MB/s or 995 Mbit/s: 50× the 20 Mbit/s this clock carries and 16× the 62.5 Mbit/s paper ceiling of a 125 MHz part. Even at that ceiling with zero overhead the frame takes 0.53 s, or 1.88 fps. If the task needs more than about 2 fps at 2 MP, change the interface — no code recovers a 50× shortfall on the wire.

What a small microcontroller can hold

A 4.15 MB frame does not fit in on-chip SRAM. Typical 32-bit MCUs carry 128 KB to 1 MB, so the frame is 4× to 32× larger than the memory you have. Plan the capture around chunks instead:

• Let the module hold the frame and clock it out after capture, if it has an internal buffer.
• Drain with DMA into double buffers of 4-16 KB. One 8 KB chunk at this clock takes 8,192 ÷ 2,222,222 = 3.7 ms, comfortable margin for the interrupt that refills the other buffer.
• Forward each chunk as it lands — to an SD card or a host port — because holding the whole frame doubles the buffer need for no gain.

The frame rate is set by the slowest leg of the chain. Whoever consumes the chunks must keep pace with 2.2 MB/s or becomes the new bottleneck. On embedded Linux boards with bigger processors, the raw-frame streaming with long exposures guide budgets the same pipeline one level up.

Sizing the link in six steps

1. Collect the four numbers: frame resolution, bytes per pixel on the wire, the module's maximum SPI clock, and the MCU's peripheral ceiling.
2. Compute frame bytes and transfer seconds at the planned clock. Write both down before touching hardware.
3. Set the clock below both ceilings — start at 20 MHz on jumper or protoboard wiring.
4. Measure: capture one frame, timestamp the DMA start and end, and divide bytes by seconds. A healthy link lands within about 10% of clock ÷ 9, which is 2.0-2.2 MB/s here.
5. Raise the clock in steps (20, then 25, then 40 MHz) and re-measure each time. Stop when the rate stops climbing or frames arrive corrupted, then back off about 20%.
6. Compare against demand: frames per second × frame bytes ÷ 1,000,000 gives the required MB/s. If demand exceeds the measured rate, the interface changes — the code does not.

When SPI is the wrong interface

SPI suits a still every second or two. Past roughly 2 fps at 2 MP the wire is the limit, and the fix is a faster interface. The same 4.15 MB frame that needs 1.87 s over SPI moves in milliseconds on the interfaces board-level cameras use:

GigE delivers about 110 MB/s of the 125 MB/s its line rate implies (1 Gbit/s ÷ 8), and USB3 about 380-400 MB/s after encoding and protocol overhead. Both are standard on board-level cameras, which is where this project's upgrade path leads: board level camera selection for embedded vision machines lists the selection criteria, the USB3 per-camera bandwidth budget sizes a single link, and the multi-camera GigE budget splits it when cameras share. If the module's sensor also offers a MIPI output, one MIPI lane changes the arithmetic again — the MIPI lane bandwidth explainer has those numbers.

The USB3 board cameras in the catalog are the direct replacement for a 2 MP SPI module that needs video rate.

The LS-BCM-0003 is a 3.1 MP USB3 board-level camera with a global shutter, rated at 120 fps. That is video rate in the same compact board format: about 226× the 0.53 fps of the 20 MHz SPI link.

For tight spaces, these GigE modules with M12 mounts carry frames over standard Ethernet instead.

Common mistakes

• Planning on clock ÷ 8. With the usual dummy clock the real figure is 11% slower: 1.87 s instead of 1.66 s for the 2 MP frame. Quote the 9-clock number in your design notes.
• Counting only the transfer. Cycle time is exposure + transfer + processing, and on most modules those run sequentially. On a 640 × 480 crop the wire time drops to 0.28 s, so a 10 ms exposure becomes about 3.6% of the cycle — budget exposure once the frame shrinks. The same addition sets the maximum frame rate on a hardware trigger.
• Buffering the whole frame. 4.15 MB against 128 KB to 1 MB of SRAM fails at run time, not at compile time — chunk it.
• Optimizing code against a wire limit. No software change beats clock ÷ 8 bytes per second. If the demand math says 124 MB/s and the link measures 2.2 MB/s, the interface is the decision, not the driver.

Before you commit the design

• Frame bytes computed from the wire format, not the megapixel rating: compressed and raw differ by roughly 10×, and every later number builds on this one.
• Clock below both ceilings with about 20% margin: under 50 MHz on a 125 MHz part and under the module's own maximum.
• One frame timed on your wiring, within 10% of clock ÷ 9 — 2.0-2.2 MB/s at this clock.
• DMA chunks proven: 8 KB per chunk gives 3.7 ms, so the refill must land inside 0.37 ms.
• Demand math on paper: frames per second × frame bytes against the measured rate, with the interface swapped if it falls short.

If the numbers say SPI cannot carry your frame rate, the camera finder filters board-level cameras by interface, resolution and frame rate, and the camera configurator builds the rest of the chain around the one you pick. If the project stays on SPI for stills, the systems guides on the topic page cover the rest of the acquisition chain.