UVC USB camera on an embedded board: driver-free support

You have an embedded development kit, a face-recognition task in near-infrared light, and a display to show the result. The question that decides the schedule is not which camera to buy but what plugs in and works: a USB camera that follows the USB Video Class (UVC) standard enumerates on the board's stock board support package (BSP) with no driver written, and the onboard HDMI output already belongs to the BSP's display stack. This guide gives you the decision, the one-command class check, the bandwidth arithmetic that picks the USB port, and camera choices that fit an embedded build.

The decision: one USB camera class is driver-free

A USB camera declares its class in its descriptors, and that declaration decides how much software you write.

• UVC (USB Video Class, interface class 0x0e). The kernel in a standard BSP already carries the uvcvideo driver. Plug the camera in, the driver binds, a /dev/video capture node appears, and your application opens it. Zero driver code.
• USB3 Vision. Industrial USB3 machine-vision cameras normally follow this standard instead of UVC. They enumerate as USB devices but stream through a userspace GenICam stack over libusb, so uvcvideo never binds. Still no kernel driver, but it is integration work, and the host needs its usbfs memory limits raised.
• Vendor-specific (interface class 0xff). Nothing binds until a vendor driver exists for your BSP. No prototype starts here.

For the face-recognition prototype, buy UVC. When the prototype grows into a machine that needs triggering and untouched pixel data, that is the moment for the USB3 Vision path — the board level camera selection guide covers the sensor side, and the interface migration plan shows how to change later without a rewrite.

One command proves the class

With the camera plugged in, run lsusb -v | grep -i bInterfaceClass. A UVC camera reports class 0e — 14 decimal, Video — on its control and streaming interfaces. Then confirm the bind: dmesg | grep uvcvideo shows the driver attaching and the device name it took. Last, ask what was negotiated: v4l2-ctl --list-devices finds the node, and v4l2-ctl -d /dev/video0 --list-formats-ext lists every frame size and rate the camera can put on the wire, with YUY2 for uncompressed frames and MJPEG for compressed ones.

A UVC camera creates several /dev/video* nodes, one per function; the capture node is the one that lists formats. The Linux camera device selection guide shows how to pick that node programmatically. From application code, cv2.VideoCapture(0) in OpenCV opens the same node. When a device sits in lsusb but your SDK never sees it, work the lsusb-not-detected plan first, and a camera that names itself with a generic UVC string usually needs its device entry reinstalled.

The bandwidth arithmetic that picks the port

Driver-free does not mean constraint-free: the port decides what the camera can send.

YUY2, the UVC uncompressed format, carries 2 bytes per pixel. Planning figures for the wire: USB 2.0 is 480 Mbps raw and sustains roughly 320 Mbps of payload; USB 3.0 is 5 Gbps raw and sustains roughly 3.2 Gbps.

Worked example — face recognition, 1920 × 1080 at 30 fps, uncompressed:

• Frame size: 1920 × 1080 pixels × 2 B = 4,147,200 B ≈ 4.15 MB
• Stream rate: 4,147,200 B × 30 fps = 124,416,000 B/s ≈ 124 MB/s
• On the wire: 124,416,000 × 8 / 1000000 ≈ 995 Mbps

Against the ports: 995 Mbps is 3.1 times what USB 2.0 sustains, so uncompressed 1080p30 fails there outright. On USB 3.0's 3.2 Gbps it is 31% of the budget, with room for a second stream. Stuck with USB 2.0, take fewer pixels or fewer frames: 1280 × 720 × 2 B × 15 fps = 27.6 MB/s ≈ 221 Mbps, which fits with 31% margin. MJPEG is the other escape, cutting 1080p30 to the tens of Mbps at the price of decode CPU and compression artifacts on the face detail your algorithm wants.

The same arithmetic scales to machine-vision cameras; the per-camera bandwidth budget math extends it to multi-camera hosts. Check the cable too: a USB 2.0 extension silently drops a USB 3.0 link back to USB 2.0 speed, which surfaces as exactly the frame drops the arithmetic predicted.

Near-infrared face recognition: sensor and light

Two things separate an IR-capable camera from a general webcam. First, no IR-cut filter: color webcams filter the near-infrared band out to keep colors honest, and at 850 nm a filtered camera sees nothing, so buy a mono camera specified without the filter. Second, manual exposure: the auto-exposure loop assumes visible scenes and wanders under constant infrared light, so lock exposure and gain once and let the illuminator set the level. To beat bright ambient light with pulsed illumination, the pulsed IR timing guide gives the exposure and duty-cycle arithmetic, and the phone-camera illuminator test confirms a board illuminator before any wiring.

One safety note belongs here: an 850 nm illuminator is invisible and your retina still absorbs it — run it at its rated current, within the IEC 62471 exempt group, and never where someone can stare into it at close range.

The HDMI display is already in the BSP

Onboard HDMI belongs to the BSP's display stack, not to the camera. The BSP ships the driver for its own HDMI port, your application draws through the standard graphics APIs, and the camera path never touches the display path — adding a USB camera adds no display driver work. If the station shows the live image on a second screen, the second-monitor set-ups without a frame grabber guide covers the options. When the prototype becomes a product, the host often moves to an industrial mini PC, and the same USB 3.0 and HDMI reasoning applies unchanged.

Cameras that fit the build

Three groups cover the cases. Compact board-level cameras mount inside the machine with no housing overhead, and the LS-BCM-0003 is a 3.1 MP USB3 board-level camera with a 1/1.8" global-shutter IMX252 sensor, a C-mount and 120 fps — the global shutter is what keeps a moving face sharp.

On the infrared side, infrared cameras split into near-infrared sensors for identity work and thermal modules for temperature screening. The LS-IRC-0016 is an LWIR thermal camera module on USB3 with 640×512 resolution, the screening half of that split:

A 640 × 512 thermal stream at 16 bits and 30 fps is 640 × 512 × 2 B × 30 = 19.7 MB/s ≈ 157 Mbps — light work for a USB 3.0 port.

Industrial USB3.0 area scan cameras normally follow the USB3 Vision standard rather than UVC, so they stream through a userspace GenICam stack instead of the uvcvideo driver, with the host's usbfs limits raised to match:

At full size, a 4000 × 3000 mono frame at 30 fps is 4000 × 3000 × 1 B × 30 = 360 MB/s ≈ 2.9 Gbps, 90% of usable and past the ceiling — hence one USB 3.0 port per camera. That is the USB3 Vision payoff: raw, uncompressed frames at rates no webcam was built to deliver.

When the driver-free answer is wrong

• The format list is shorter than the box promised. Many UVC webcams offer uncompressed YUY2 only at modest sizes and switch to MJPEG above that. Plan around what --list-formats-ext shows, not the box, before you commit the bandwidth budget.
• Faces smear when they turn. That is rolling shutter, not bandwidth — move to a global-shutter sensor for identity work on moving people.
• The device vanishes inside a container. Container runtimes do not pass USB nodes through by default; a CDI device spec hands the container exactly the capture node it needs.
• Two cameras swap names between boots. /dev/video0 ordering is not stable across plugs and boots; the device-path conflicts guide shows the stable naming set-up.

Bring-up checklist

• lsusb shows the camera, and bInterfaceClass reads 0e.
• dmesg shows uvcvideo binding at plug-in.
• --list-formats-ext lists your target size, format and rate — nothing assumed.
• Stream rate computed, under 70% of the port's usable payload rate.
• USB 3.0 cable and port, no hub, no USB 2.0 extension in the path.
• Exposure and gain locked with the illuminator on.
• Container deployments carry a CDI spec for the capture node.
• One known-good frame saved from the final node path.

Decisions, case by case

• Face-recognition prototype on a development kit: mono UVC camera without an IR-cut filter, on a USB 3.0 port, 1920 × 1080 YUY2 at 30 fps (995 Mbps, 31% of the port), exposure locked, 850 nm illumination inside IEC 62471 limits, output drawn on the onboard HDMI. No driver work anywhere.
• Embedded product needing triggers and raw pixels: a USB3 Vision camera through a GenICam stack, one camera per USB 3.0 port once a stream approaches the ceiling, usbfs limits raised.
• Temperature screening station: an LWIR USB3 module at 640 × 512 — light enough for any port, thermal data over the same USB 3.0 wiring.

Start in the camera finder, step through the configurator below, and if the port or class question is still open, ask us through the contact page.