企业官网建设流程全解析

做嵌入式视觉的项目，十有八九会撞上同一堵墙：主控选定了，MIPI CSI 接口数量却不够用。手里这块主控只有 2 路 MIPI CSI，产品需求却写了“4 路摄像头同时采集”，改主控等于推倒重来，硬件、驱动、结构全都得动。我这些年在这类问题上踩了不少坑，也把能用的路子基本试了一遍，这里把几条主流方案拆开讲清楚：MIPI 物理切换、虚拟通道、SerDes 解串器汇聚、FPGA 桥接，以及干脆绕开 MIPI 换 USB 或以太网的做法。

先说一个基本判断：接口不够通常是“需求变了”，而不是“主控选错了”。项目初期规划 2 路摄像头，后面因为视野范围、多角度检测、双目测距等原因变成 4 路甚至 6 路，这在工业视觉、智能汽车、机器人、安防项目里太常见了。与其重新选主控，更合适的思路是先搞清楚这些摄像头是不是真的需要“同时、全速、独立”工作。大部分场景里，接口不够都可以由链路复用或接口转换来解决。

这篇文章适合正在画原理图、或者已经卡在多路摄像头驱动调试上的嵌入式工程师看，也适合准备立项、想做方案选型评估的产品经理参考。我会尽量把每一条路子的原理、实现要点和坑都写细，最后附上选型对照和排查实录。

1. 接口不够之前，先算清一路 MIPI CSI 能装多少摄像头

1.1 MIPI CSI-2 的结构：通道与虚拟通道各管什么

MIPI CSI-2 是摄像头和主控之间的标准接口，物理上由 1 对差分时钟线和 1～4 对差分数据线组成，这一组线通常叫 1-lane、2-lane 或者 4-lane 链路。链路里跑的是串行差分信号，同一时刻只能传一份数据包。理解“同一时刻只能传一份”是看懂后面所有方案的关键：想用一条链路同时接多路摄像头，要么提高链路速度塞下更多流量，要么把多路数据在时序上交错起来，要么用虚拟通道在逻辑上分装。

虚拟通道（Virtual Channel, VC）是 CSI-2 协议自带的能力，包头里用 2 bit 表示 VC ID，所以一条物理链路上最多能区分 4 个逻辑流（VC0～VC3）。数据链路本身还是共享的，VC 只是给接收端一个“这笔数据属于通道几”的标记。主控端的 CSI 控制器收到数据后会按照 VC 把不同逻辑流拆给不同的驱动实体。

这里有一个常见误区：并不是传感器支持 VC，两个 sensor 就能直接并到同一组 MIPI 线上。两个传感器都输出主时钟，波形直接在线上打架，必须由一个中间的聚合器件统一调度，或者干脆由解串器重排时序。后面讲 SerDes 和 FPGA 方案时，聚合器件承担的就是这个职责。

1.2 带宽估算：不打草稿就上板，后面全是泪

在决定用哪种扩展方案之前，得先算清楚每路摄像头到底占多少带宽，以及主控 MIPI 链路还剩多少余量。带宽公式不复杂：

bit_rate = 水平像素 × 垂直像素 × 帧率 × 每像素 bit 数 ×（1 + 消隐开销）

消隐开销一般取 1.2～1.3，因为传感器输出还要带行消隐和帧消隐。我常用的几个结果直接记着：

• 720p@30 RAW10：约 276 Mbps，算上开销约 330 Mbps；
• 1080p@60 RAW12：约 1.49 Gbps，算上开销约 1.8 Gbps；
• 4K@30 RAW8：约 1.99 Gbps，算上开销约 2.4 Gbps。

对照 D-PHY v1.2 的常见速率，单 lane 跑 1 Gbps～1.5 Gbps 很稳，规范上限到 2.5 Gbps，但高速率对 PCB 走线、连接器、线缆的要求都会陡增。所以一条 4-lane 链路按实用速率算，大概有 4×1.5 Gbps = 6 Gbps 的预算，实际还要扣掉协议开销。在这个预算里，塞 4 路 720p@30 RAW10 没问题，塞 4 路 1080p@60 RAW12 就明显不够。这个结论直接决定了后续方案：带宽够的场景可以走“多路复用到一条链路”，带宽不够就只能换主控、做预处理降量，或者接受降低帧率。

1.3 主控接口数量的真实约束

主控的“接口不够”不全是引脚不够。SoC 内部 CSI 控制器数量、ISP 接收通道数、DMA 通道数，都会限制最终能同时采集几路视频流。典型情况：RK3588 有 4 路 MIPI CSI 接口，算多的；i.MX8M Plus 2 路，RV1126 2 路，很多低成本主控只有 1 路完整的 4-lane CSI。接口数量少，不代表摄像头总数只能等于接口数，只说明“直连主控的链路数”有限。

另一个常被忽视的约束是：同一个 CSI 控制器如果接了多路数据，驱动和 ISP 要能按 VC 或者按帧拆分流。Linux V4L2 框架下会体现为多个 sub-device 实体，很多主控虽然物理上有 4 lane 引脚，底层驱动只支持把整个链路当一个 video 节点用，想拆成多路就得改不少内核代码。所以选主控时，光看“支持几路 CSI”不够，还要看 SDK 对 multi-stream 的支持程度。

2. 方案一：MIPI 物理切换，适合“一次只看一路”

2.1 模拟开关实现分时复用

如果你这 4 路摄像头不需要同时出图，而是分时采集，那最简单的方案就是用 MIPI 差分模拟开关做 1 切 2，再级联成更多路。这类器件本质上是一组高速差分多路选择器，例如 TI 的 TS3DV642：6 个差分通道、6 Gbps 速率、2:1 切换，时钟 lane 和数据 lane 一起切，控制端一个 GPIO 就能选通路。

设计上非常省事：每个摄像头模组先各自走线到切换开关，开关的输出统一进入主控那一路 CSI。主控侧看到的始终是一个 CSI 接口，只是不同时刻上游接的是不同摄像头。软件上不需要动驱动，只要在切换后重新初始化对应 sensor 并重新设置分辨率即可。切换前建议先把当前 sensor 停止出流，再切开关，最后再启动目标 sensor，避免 MIPI 链路上残留的数据包把接收端搞出误帧。

2.2 实操要点与坑

这里有几个我从原理图阶段就踩过的细节。第一，TS3DV642 这类开关的带宽是够，但它的导通电阻和寄生电容会占掉一部分链路裕量，走线长度不要拉太长，输入端到开关、开关到主控的差分线尽量控制在 5～8 cm 以内。第二，串接的开关越多，链路裕量损失越大，级联超过两三级后很容易在高分辨率下花屏，实测下来分时方案最多做到 2 级级联做 4 切 1，再往上不如直接上解串器。

第三，模拟开关本身不提供眼图重定时，线缆一长信号就垮，所以只适合板上短距离复用。还需要注意开关的方向和使能：MIPI CSI 是单向的，传感器输出到主控输入，开关用的是 2:1 mux 而不是双向交换器，避免选到那种支持双向的 DSI 开关，被内部传输门延迟搞出问题。控制信号最好带 RC 滤波或者上拉，避免开机瞬间 GPIO 不定态导致开关抖动。

注意：物理切换方案只适合“分时采集”，千万别指望它同时出多路图。摄像头 A 和 B 同时都在跑，切到 B 时 A 的数据流被硬断，A 侧 sensor 会持续报错甚至卡死，恢复时大概率要复位 sensor。

2.3 最适合这个方案的场景

分时切换最适合的典型场景是：摄像头数量多但使用率低，成本敏感，对切换时间有数百毫秒到几秒的心理预期。比如智能货架的多工位扫码、工业检测里的多角度轮拍、巡检机器人按工位拍照，这种场景用开关就能解决，成本只有一颗芯片钱，主控接口占用也只有一路。还有树莓派这类接口少的开发板，如果只是想临时接多个 ov5647 摄像头模块做演示，用切换开关也比动辄换核心板划算得多。

3. 方案二：虚拟通道 VC 拆流：一条 CSI 当四路用

3.1 理解 VC 的真相与局限

前面说过，VC 只是包头里的 2 bit ID，它解决的是“接收端怎么区分逻辑流”的问题，不解决“多路信号怎么在同一条链路上共线”的问题。所以真正能利用 VC 把一条 CSI 当四路用的，通常是两种硬件结构：一种是传感器本身支持 VC 输出，且外部有聚合单元把它们交错成一路；另一种是解串器或 FPGA 把多路输入统一打包成带 VC 标记的 CSI-2 流。

拿解串器举例子：MAX9286 是 4 路 GMSL2 解串器，4 路同轴输入，输出是一个标准 CSI-2 端口，内部默认把 4 路 camera 映射成 VC0～VC3。主控的 CSI 控制器和驱动看到的是“一个物理端口 + 4 个逻辑流”，V4L2 media controller 里会对应 4 个 pipeline。这种情况下，硬件并没有省下来，只是把“接口数量不够”换成了“接口以内多路复用”。

3.2 用 VC 方案时驱动层注意什么

驱动层要做的核心事情是给每个 VC 创建独立的 video 节点，并把 sensor、解串器、主控 CSI 之间的 media link 配好。在 Linux V4L2 框架下，解串器通常注册成一个 sub-device，内部有多个 pad，每个 pad 对应一个 VC。Device tree 里需要把解串器的输出端点与主控 CSI 输入端点连上，再为每个 VC 分配独立的 link。大致结构像这样：

&csi2_dphy0 { status = "okay"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; csi2_dphy0_in: endpoint { remote-endpoint = <&max9286_out>; >