Camera interface for a microcontroller: why parallel DVP beats CSI

You have a microcontroller board and a camera plan: record a clip, stream frames over WiFi, run a presence check. One decision gates all of it — which camera interface can the chip actually receive? Most general-purpose MCUs expose a parallel camera port and no MIPI CSI-2 receiver, so the choice is made before you pick a sensor. Below is the receiver design behind DVP and CSI-2, the bandwidth arithmetic that sets the ceiling, and the thresholds that tell you when the MCU stays in the design and when the design moves up.

Two receivers, not two connectors

A parallel camera port works like a memory bus. The sensor drives 8 to 14 data lines together with a pixel clock and frame and line sync signals, and holds one pixel on the data lines for each clock. MCU camera-interface documentation describes exactly this: a configurable parallel interface of 8 to 14 data lines with a dedicated pixel clock input, latched by the camera peripheral — usually named DCMI, its clock line DCMI_PIXCLK — and moved to memory by DMA. Software configures the sensor over I2C; after that, hardware streams.

MIPI CSI-2 is a different machine. It serialises pixels onto one or more differential lane pairs and the receiver is a dedicated hardware PHY that deserialises, aligns the lanes and reassembles pixels. There is no sampling bits in software: if the chip lacks the PHY block, the interface does not exist on that board.

The two physical layers never interchange, and the DVP versus MIPI CSI-2 connector comparison shows why even the flex cables refuse to match. For the wider family of camera links beyond these two, the embedded camera interface comparison from CSI-2 to GMSL2 maps the rest of the options.

Why CSI-2 resists a microcontroller

Three properties keep CSI-2 off most MCU boards.

First, the signalling. Each lane toggles in the hundreds of megabits per second with sub-nanosecond edges, so the receiver must be a hard PHY block. No firmware upgrade adds one.

Second, availability. Parallel camera ports ship across most general-purpose MCU families; CSI receivers appear on a short list of newer parts. Those parts tend to come in fine-pitch packages that want length-matched lane routing and controlled-impedance board work. An 8-bit parallel bus, by contrast, routes happily on two layers.

Third, the payload. CSI-2 sensors output raw Bayer, and the debayering, white balance and gamma normally happen in an ISP block beside the PHY. Without an ISP, the MCU spends its cycles demosaicing instead of inspecting — the raw sensor output guide for cameras with no ISP covers what that means in practice. Bring-up adds its own class of failures in detection, lane order and clocking; even on Linux-class boards, a CSI camera that comes up not detected is traced through clock and lane checks before the first frame moves.

Bandwidth math: VGA monochrome at 30 fps on an 8-bit port

The inputs and where each comes from

This is the calculation that decides the interface, so fix the inputs first. 640 × 480 pixels (VGA) — the smallest resolution that still carries usable inspection detail on an MCU. 1 byte per pixel — 8-bit grayscale, the mode to run when the bus is 8 bits wide. 30 fps — an ordinary capture-and-store rate. An 8-bit bus — the low end of the documented 8-to-14-line range. A port ceiling of 24 MB/s — the middle of the few-tens-of-MB/s this class of port delivers, which is an 8-bit bus toggling at 24 MHz. Count MB as 10^6 bytes throughout.

The arithmetic and the check against the ceiling

Work it through step by step:

640 × 480 = 307,200 pixels per frame. 307,200 px × 1 B = 307,200 B ≈ 307 KB per frame. 307,200 B × 30 fps = 9,216,000 B/s ≈ 9.2 MB/s, which is 73.7 Mbit/s. 9,216,000 B/s ÷ 1 B per clock = 9.2 MHz of pixel clocks. The sensor keeps toggling the clock through line and frame blanking, so budget about 12 MHz and confirm the camera port and its DMA hold that rate while your application runs.

Check against the ceiling: 9.2 MB/s against 24 MB/s leaves a 2.6× margin, so the port fits with room for DMA to feed storage and a WiFi stack at the same time. Run the same frame at 60 fps and the stream doubles to 18.4 MB/s — still inside the ceiling, but the margin thins to 1.3×, and that is where contention with your own code starts to show.

The counter-case draws the line. 720p at 30 fps in the same 8-bit mono: 1280 × 720 = 921,600 px; × 1 B × 30 fps = 27,648,000 B/s ≈ 27.6 MB/s. That is 3.6 MB/s past the 24 MB/s ceiling, and no DMA tuning recovers it. So, on an 8-bit port with this ceiling: at or below 15 MB/s sustained, comfortable; 15 to 25 MB/s, workable with tight DMA and memory budgets; above 25 MB/s, change the receiver, not the firmware.

Where a microcontroller is the right host

With thresholds in hand, the fit is easy to state. Keep capture on the MCU when the stream sits at or below 15 MB/s — VGA-class mono at video rates, or smaller frames faster — and the vision task is presence, position within a tolerance, counting or a simple code read. The MCU gives you deterministic capture with hardware sync signals, low power draw and a small bill of materials. It is also the only one of the two hosts that lets you own the whole pipeline — registers, DMA, frame buffers, then your own algorithm — on a two-layer board.

Streaming to a network is a second budget, not the first. The radio link, not the camera port, usually caps a wireless stream first, and the bandwidth math for multiple WiFi cameras on one embedded board applies per link. Budget the sensor-to-MCU path and the MCU-to-radio path as two separate numbers, and expect the second one to bite first.

When to move up from the parallel port

Three triggers take the design off the MCU camera port: sustained pixel rate above 25 MB/s — 720p at 30 fps already needs 27.6 MB/s — colour processing that wants an ISP the chip lacks, or a sensor class that ships CSI-2 only. The question then changes from 'which interface does my MCU have' to 'which standard camera port does a host in this system already have'. A USB3 or GigE board-level camera is usually the answer: a USB3 camera plugs into any host with a USB3 port, and GigE runs on standard Ethernet for up to 100 m on one cable, with exposure control and trigger inputs built for inspection.

If the sensor you must use is CSI-2 only, a bridge keeps the rest of the design: CSI-2-to-USB hardware becomes the receiver and the budget moves to the USB link — sizing the MIPI CSI-2 to USB bridge data path shows that math. Industrial controllers and gateways often carry no camera receiver at all, and there the same comparison decides between CSI hardware and a USB camera; the CSI versus USB camera alternatives on a controller without a camera port page works through that exact case.

Catalog cameras that fit this upgrade path:

The LS-BCM-0003 takes the fast-mono case: 3.1 MP at 120 fps over USB3, global shutter. The MV-CB016-10GM-M-W takes the Ethernet case: a 1.6 MP global-shutter sensor behind an M12 lens mount on a GigE link. The MV-CB060-10UM-B takes built-in designs: 6 MP mono over USB3 on a bare board that mounts in your own housing.

All three sit in the board-level cameras range; when the format or resolution grows past them, area scan cameras continue the same USB3 and GigE families.

For a systematic shortlist before you commit, the board-level camera selection guide for embedded vision machines walks the full checklist, and reducing per-camera USB3 bandwidth shows what one USB3 port carries when the plan grows to several cameras.

Checks before you order the sensor

• Output interface first. Parallel DVP with an 8-bit mode. A 10-bit-only sensor costs you the doubled pixel clock from the tip above.
• Documentation and a driver. Pick a sensor with a public register map and existing driver code for your platform family. An undocumentable register set stalls the project whatever the interface.
• Pin budget. 8 to 14 data lines, pixel clock, frame and line sync, and an I2C control bus add up to roughly 15-20 GPIOs. Count them on your board before you shortlist a sensor.
• Memory. One VGA mono frame is 307 KB. Two frame buffers plus working space put most MCUs into external RAM, or into a smaller active window.
• Clock and DMA. The port must run about 12 MHz for the worked example and keep DMA flowing while your code runs.
• Comparing CSI-2 anyway? Estimate the lane rate before believing a headline fps — the MIPI CSI-2 frame rate estimation from lanes and data rate is the way to do it.

The decision, per case

• Mono capture at VGA or below, presence and count checks, learning the pipeline: parallel DVP port in 8-bit mode, sensor chosen by output interface first. The worked example is your sizing template, and anything under 15 MB/s sustained is comfortable.
• 720p or higher, 60 fps and up, or colour that needs an ISP: above 25 MB/s sustained the MCU camera port is the wrong receiver. Put a USB3 or GigE board-level camera on the same board, or move to a host with a CSI receiver if the sensor is fixed.
• CSI-2-only sensor and no receiver anywhere in the system: bridge to USB and re-run the budget on the USB link, or change the host. Do not try to receive CSI-2 in firmware.

Start the camera side from the camera finder or configure the system with the camera as the first step; the systems topic page collects the rest of the capture-pipeline guides. If your numbers land between the thresholds, ask us on the contact page — free expert support with every order.