📺 B站 嵌入式孙老师：博主个人介绍
📘 博主书籍-京东购买链接*：Yocto项目实战教程
📘 加博主微信，进技术交流群： jerrydev
从一颗 Camera 到 16 路 GMSL：看懂自动驾驶摄像头的硬件链路
在普通嵌入式项目里，摄像头常常是这样接的：
Camera Sensor → MIPI CSI → SoC
但到了自动驾驶、机器人、多目感知系统里，经常会变成：
Camera Sensor → GMSL → Orin / Thor
这会让人产生一个疑问：既然 CMOS 本身就能输出 MIPI CSI，为什么还要多加 GMSL？GMSL 是不是比 CSI 更快？为什么 GMSL 最后又要转回 CSI？
核心结论其实很清楚：CSI 是摄像头到 SoC 的本地高速接口，GMSL 是把这路高速摄像头数据传远、传稳的车载 SerDes 链路。
一、CSI 是摄像头的“本地高速接口”
MIPI CSI-2 是嵌入式摄像头最常见的接口之一，MIPI 官方也将 CSI-2 描述为广泛用于嵌入式 Camera 和 Imaging 的接口，可支持 1080P、4K、8K 及更高分辨率图像应用。(MIPI Alliance)
普通摄像头模组的连接方式通常是：
┌──────────────┐
│ CMOS Sensor │
│ 例如 IMX585 │
└──────┬───────┘
│ MIPI CSI-2
▼
┌──────────────┐
│ SoC / ISP │
│ RK / Orin │
└──────────────┘
CSI 的优势是速度高、延迟低、适合直接进入 SoC 的 Camera Receiver 和 ISP。但它的短板也明显：它更适合板内、模组内、短距离连接，不适合在车内从车头、车尾、侧边拉几米线到中央计算平台。
二、lane 是 CSI 里的“数据车道”
CSI 并不是一根线传完所有数据，而是通过多条高速数据通道并行传输。每一条高速数据通道就叫 lane。
可以这样理解：
| 概念 | 类比 |
|---|---|
| MIPI CSI | 高速公路 |
| lane | 高速公路里的车道 |
| 4-lane CSI | 四车道高速 |
常见的 CSI D-PHY 4-lane 原理图信号会长这样：
CLKP / CLKN → Clock Lane
D0P / D0N → Data Lane 0
D1P / D1N → Data Lane 1
D2P / D2N → Data Lane 2
D3P / D3N → Data Lane 3
也就是说：
4-lane D-PHY = 4 条数据 lane + 1 条时钟 lane
D-PHY 和 C-PHY 都是 CSI-2 可搭配的物理层。D-PHY 更常见，有独立 Clock Lane；C-PHY 使用三线组和嵌入式时钟，目标是减少互连信号数量、提升效率。(MIPI Alliance)
三、为什么摄像头数据会这么大？
很多人容易把 Camera 输出和视频文件大小混在一起。实际上，自动驾驶和机器人场景里常见的是 RAW Bayer 原始数据流，不是 H.264/H.265 压缩视频。
以 4K 60fps RAW12 为例：
3840 × 2160 × 60 × 12 bit
≈ 5.97 Gbps
也就是说，一路 4K60 RAW12 摄像头，裸数据量就接近 6Gbps。
可以用一段代码估算：
def camera_bandwidth(width, height, fps, bits_per_pixel):
bps = width * height * fps * bits_per_pixel
gbps = bps / 1e9
mb_per_s = bps / 8 / 1e6
return gbps, mb_per_s
cases = [
("1080P30 RAW12", 1920, 1080, 30, 12),
("4K30 RAW12", 3840, 2160, 30, 12),
("4K60 RAW12", 3840, 2160, 60, 12),
]
for name, w, h, fps, bit in cases:
gbps, mbps = camera_bandwidth(w, h, fps, bit)
print(f"{name}: {gbps:.2f} Gbps, {mbps:.1f} MB/s")
输出大约是：
1080P30 RAW12: 0.75 Gbps, 93.3 MB/s
4K30 RAW12: 2.99 Gbps, 373.2 MB/s
4K60 RAW12: 5.97 Gbps, 746.5 MB/s
如果是 8 路、12 路、16 路 Camera，数据量会迅速进入几十 Gbps 级别。真正的瓶颈不只是接口，还包括 ISP、DDR 带宽、DMA、缓存、AI 推理算力和系统调度。
四、GMSL 是什么：不是摄像头，而是一套 SerDes 硬件链路
GMSL 全称是 Gigabit Multimedia Serial Link，是 ADI / Maxim 的车载高速串行链路方案。它不是 CMOS 传感器本身，也不是简单的软件协议，而是一套包含 Serializer、Deserializer、线缆、电源、控制通道和同步机制的硬件传输系统。
典型结构是：
┌──────────────────┐
│ CMOS Sensor │
│ 例如 IMX585 │
└────────┬─────────┘
│ MIPI CSI-2
▼
┌──────────────────┐
│ Serializer │
│ 例如 MAX9295 │
└────────┬─────────┘
│ GMSL
═════════╪══════════ 同轴线 / 屏蔽双绞线
│
▼
┌──────────────────┐
│ Deserializer │
│ 例如 MAX9296 │
└────────┬─────────┘
│ MIPI CSI-2
▼
┌──────────────────┐
│ SoC / Orin │
│ CSI Receiver │
└──────────────────┘
更压缩地说就是：
CSI → Serializer → GMSL → Deserializer → CSI
ADI 官方资料里，MAX9295D 的描述就是把单路或双路 MIPI CSI-2 数据流转换为 GMSL2 / GMSL1，并通过单线进行视频和双向控制数据传输；GMSL2 前向链路速率为 3Gbps 或 6Gbps。(模拟器件)
另一侧的 Deserializer 则做反向动作，例如 MAX96716A 官方描述为把双路 GMSL2 串行输入转换为 MIPI CSI-2 输出。(模拟器件)
所以，GMSL 的硬件角色很明确：
| 部件 | 位置 | 作用 |
|---|---|---|
| Sensor | 摄像头模组内 | 采集图像，输出 RAW |
| MIPI CSI | Sensor 到 Serializer | 本地高速图像接口 |
| Serializer | 摄像头端 | CSI 转 GMSL |
| GMSL Cable | 摄像头到主板 | 长距离高速传输 |
| Deserializer | 主机端 | GMSL 转 CSI |
| SoC | Orin / RK / Thor | 接收 CSI，做 ISP 和 AI |
五、为什么 GMSL 最后还要转回 CSI？
因为大多数 SoC 真正原生接收的是 MIPI CSI，不是 GMSL。
也就是说，Orin、RK3588 这类芯片内部通常有 CSI Receiver、VI、ISP、DMA、GPU/NPU/DLA 等模块，但不会直接把 ADI 的 GMSL PHY 做进 SoC。GMSL 是外围 SerDes 生态，最终需要通过 Deserializer 恢复成 CSI，再进入 SoC。
NVIDIA Jetson GMSL 文档中的参考结构也体现了这一点：传感器和 Serializer 配对，RAW 数据通过 CSI MIPI lanes 传输，随后进入 Jetson 的 GMSL Camera 框架。(NVIDIA Docs)
所以一句话概括：
CSI 是 SoC 能直接吃的数据入口；
GMSL 是中间那段长距离运输链路。
六、GMSL 解决的是“传远、传稳”，不只是“更快”
GMSL 不一定比 CSI 更快。很多时候，板级 CSI 本身带宽很高。GMSL 的核心价值不是单纯提高速度，而是解决车载摄像头的工程问题：
| 问题 | 直接 CSI | GMSL |
|---|---|---|
| 距离 | 短，适合板内 | 可跑几米到十几米 |
| 线缆 | FPC / PCB 走线 | 同轴线 / 屏蔽双绞线 |
| 抗干扰 | 一般 | 强 |
| 车载布线 | 不适合 | 适合 |
| 多摄聚合 | 困难 | 支持 Deserializer 聚合 |
| 控制通道 | 额外处理 | 可走反向控制通道 |
| 供电 | 额外供电 | 可配合 PoC 方案 |
MAX9295D 官方资料提到它支持超过 15m 线缆上的单线全双工传输，这就是 GMSL 相比普通 CSI 的典型优势之一。(模拟器件)
七、“16 路 GMSL”到底是什么意思？
当一个平台说支持：
16 路 GMSL Camera
它通常不是说 SoC 芯片内部有 16 个原生 GMSL 控制器，而是说整个平台或板级系统提供了 16 路 GMSL 摄像头输入能力。
NVIDIA DRIVE AGX Orin 官方 Camera Interface 文档明确写到，DRIVE AGX Orin 平台提供 16 路同时 GMSL Camera 输入，同时实际支持数量还会受分辨率、帧率、功耗模式、VI 和 ISP 时钟影响。(NVIDIA Developer)
典型硬件上可能是：
Camera 0 ─┐
Camera 1 ─┤
Camera 2 ─┤
Camera 3 ─┘
↓
Deserializer
↓ CSI
Camera 4 ─┐
Camera 5 ─┤
Camera 6 ─┤
Camera 7 ─┘
↓
Deserializer
↓ CSI
也就是多个 GMSL Camera 先进 Deserializer，再由 Deserializer 通过 CSI 输出给 SoC。
这个过程常常涉及 Virtual Channel。例如多个摄像头共享一组 CSI 输出时，可以通过不同 VC ID 区分不同 Camera 数据流。这样 SoC 看到的是同一物理 CSI 接口上的多路逻辑视频流。
逻辑可以理解为：
GMSL Camera 0 → VC0
GMSL Camera 1 → VC1
GMSL Camera 2 → VC2
GMSL Camera 3 → VC3
↓
Deserializer 聚合
↓
CSI 输出到 SoC
八、RK3588 为什么也能接 Camera，但和 Orin 不是一个定位？
RK3588 当然可以接多路摄像头，也可以外挂 GMSL Deserializer。准确地说，RK 不是“不能用 GMSL”，而是 没有原生 GMSL，通常需要外部 Deserializer 转成 CSI 再接入。
结构仍然是：
GMSL Camera
↓
Deserializer
↓ CSI
RK3588
但 RK3588 和 Orin / Thor 的系统定位不同：
| 对比项 | RK3588 | Orin / Thor |
|---|---|---|
| 定位 | 边缘 AI SoC | 自动驾驶 / 高端机器人 AI 平台 |
| 摄像头规模 | 2~4 路 4K 较常见 | 8~16 路高带宽 Camera |
| AI 生态 | NPU，模型需适配 | CUDA、TensorRT、DLA |
| 模型类型 | YOLO、OCR、小模型 | BEV、Transformer、多模型并行 |
| 内存带宽 | 中等 | 更高 |
| ISP / VI 能力 | 适合中等规模 | 面向多路高吞吐 |
| 成本功耗 | 更低 | 更高 |
所以，判断用 RK 还是 Orin，不是只看“能不能接摄像头”，而是看整条链路：
Camera 数量
× 分辨率
× 帧率
× RAW bit 数
× ISP 处理量
× AI 模型复杂度
× 实时性要求
如果是 2 路 1080P、4 路普通 Camera、轻量级检测，RK 很合适。
如果是 8 路以上 4K RAW、同步采集、BEV 感知、Transformer、多模型并行，Orin / Thor 更符合系统定位。
九、硬件原理图上应该怎么看？
看一套 Camera 硬件时，不要只看接口名字，要按数据流拆开。
1. Sensor 侧
重点看：
MIPI_DPHY_CSI_TX_D0P / D0N
MIPI_DPHY_CSI_TX_D1P / D1N
MIPI_DPHY_CSI_TX_D2P / D2N
MIPI_DPHY_CSI_TX_D3P / D3N
MIPI_DPHY_CSI_TX_CLKP / CLKN
如果有 D0~D3，就是 4 条 Data Lane。
如果还有 CLKP/CLKN，就是 D-PHY 的 Clock Lane。
2. Serializer 侧
重点看：
CSI 输入
I2C 控制
PWDN / RESET
REFCLK
GMSL 输出
PoC 相关电路
Serializer 的作用是：
MIPI CSI-2 → GMSL
3. Deserializer 侧
重点看：
GMSL 输入
I2C 控制
MIPI CSI 输出
Virtual Channel 配置
Frame Sync
Power / Reset
Deserializer 的作用是：
GMSL → MIPI CSI-2
4. SoC 侧
重点看：
CSI Port
CSI Lane 数量
VC ID
ISP Pipeline
VI / DMA
驱动中的 sensor mode
最终 SoC 看到的，仍然是 CSI 数据。
十、软件上怎么描述这条链路？
真实驱动会复杂很多，但抽象逻辑可以写成这样：
sensor {
output = "mipi-csi2";
lanes = 4;
format = "raw12";
resolution = "3840x2160";
fps = 60;
}
serializer {
input = "mipi-csi2";
output = "gmsl2";
link_rate = "6Gbps";
}
deserializer {
input = "gmsl2";
output = "mipi-csi2";
virtual_channel = 0;
}
soc_csi {
input = "mipi-csi2";
lanes = 4;
vc = 0;
}
如果是 4 路 Camera 聚合，逻辑会变成：
camera0 → serializer0 → gmsl link0 ┐
camera1 → serializer1 → gmsl link1 ├→ deserializer → CSI → SoC
camera2 → serializer2 → gmsl link2 ┤
camera3 → serializer3 → gmsl link3 ┘
camera0 = VC0
camera1 = VC1
camera2 = VC2
camera3 = VC3
从驱动角度看，常见问题不一定出在 Sensor，也可能出在：
Serializer 没配置好
Deserializer link 没 lock
CSI lane mapping 错
VC ID 错
I2C alias 错
RAW 格式不匹配
帧同步没配好
SoC ISP mode 不支持
这也是 GMSL Camera bring-up 比普通 MIPI Camera 更复杂的原因。
十一、CSI、GMSL、USB、GigE 的位置区别
不同 Camera 接口解决的问题不同：
| 接口 | 典型场景 | 特点 |
|---|---|---|
| MIPI CSI | 手机、嵌入式板卡、Sensor 直连 | 高速、低延迟、短距离 |
| GMSL | 自动驾驶、车载多摄 | 长距离、抗干扰、可聚合 |
| FPD-Link | 车载 Camera，TI 生态 | 类似 GMSL 的 SerDes 方案 |
| USB UVC | 普通摄像头 | 简单、即插即用、延迟和同步一般 |
| GigE Vision | 工业相机 | 网线长距离、多相机方便 |
| CoaXPress | 高端工业视觉 | 超高带宽、成本高 |
在自动驾驶里，选择 GMSL / FPD-Link 的原因通常不是“接口名字更高级”，而是车内真实工程环境需要：
长线束
抗 EMI
摄像头同步
低延迟
可靠连接
集中计算
多摄像头聚合
十二、完整链路总结
一个典型车载摄像头系统可以拆成三层：
采集层：
CMOS Sensor → MIPI CSI
传输层：
Serializer → GMSL Cable → Deserializer
计算层：
MIPI CSI → SoC CSI Receiver → ISP → DDR → GPU / DLA / NPU
总图如下：
┌──────────────────────┐
│ Camera 模组 │
│ │
│ ┌────────────────┐ │
│ │ CMOS Sensor │ │
│ └───────┬────────┘ │
│ │ MIPI CSI │
│ ▼ │
│ ┌────────────────┐ │
│ │ Serializer │ │
│ │ MAX9295等 │ │
│ └───────┬────────┘ │
└──────────┼───────────┘
│ GMSL
═══════════╪════════════ 同轴线 / 屏蔽双绞线
│
┌──────────▼───────────┐
│ 主控板 / ECU │
│ │
│ ┌────────────────┐ │
│ │ Deserializer │ │
│ │ MAX9296等 │ │
│ └───────┬────────┘ │
│ │ MIPI CSI │
│ ▼ │
│ ┌────────────────┐ │
│ │ SoC CSI RX │ │
│ │ Orin / RK等 │ │
│ └───────┬────────┘ │
│ ▼ │
│ ISP / DDR / AI │
└──────────────────────┘
最终可以把这些概念归纳成一张表：
| 名称 | 本质 | 作用 |
|---|---|---|
| CMOS Sensor | 图像传感器 | 采集光信号，输出 RAW 数据 |
| MIPI CSI-2 | 本地 Camera 接口 | Sensor 到 SoC 或 Serializer 的高速接口 |
| lane | CSI 数据通道 | 多 lane 并行提高带宽 |
| D-PHY / C-PHY | CSI 物理层 | 负责底层电气传输 |
| GMSL | 车载 SerDes 链路 | 长距离传输 Camera 数据 |
| Serializer | 串行器 | CSI 转 GMSL |
| Deserializer | 解串器 | GMSL 转 CSI |
| RK3588 | 边缘 AI SoC | 适合中等规模视觉应用 |
| Orin / Thor | 自动驾驶 AI 平台 | 适合多路高带宽 Camera + 大模型推理 |
结语
GMSL 和 CSI 不是替代关系，而是上下游关系。
更准确的理解是：
CSI 是 Camera 数据的本地入口；
GMSL 是 Camera 数据的长距离运输层；
Deserializer 再把 GMSL 恢复成 CSI 交给 SoC。
所以自动驾驶摄像头链路通常不是：
Sensor → GMSL → SoC
而是：
Sensor → CSI → Serializer → GMSL → Deserializer → CSI → SoC
当摄像头数量少、距离短、AI 任务轻时，直接 MIPI CSI 或 RK 平台就足够。
当系统进入 8 路、12 路、16 路高带宽 Camera，并且还要实时完成感知、融合、BEV、Transformer 推理时，GMSL + Orin / Thor 这类架构才体现出价值。
扫一扫
1457
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
