3. 摄像头模组与MIPI接口：Sensor输出接口类型、RAW10/RAW12/RAW16数据格式、MIPI CSI-2协议栈
好，我们进入第三章。这一章聊的是摄像头模组和MIPI接口的底层细节。说白了，就是Sensor拍完一张照片后，怎么把数据传出去。
很多工程师觉得这步很简单——Sensor输出，SoC接收，中间走MIPI线。但实际项目中，我见过太多因为接口类型选错、数据格式没对齐、或者协议栈理解不透导致的花屏、丢帧、带宽不够用的问题。嗯，咱们今天就把这些坑一个个填上。
3.1 Sensor输出接口类型
Sensor的输出接口，目前主流就三种：DVP、LVDS、MIPI CSI-2。我按出现的时间顺序给你捋一遍。
| 接口类型 | 信号方式 | 最大速率 | 适用场景 | 现状 |
|---|---|---|---|---|
| DVP | 并行（8/10/12 bit） | ~96 Mbps | 低分辨率、低帧率 | 基本淘汰 |
| LVDS | 串行（差分对） | ~1 Gbps/对 | 工业相机、老平台 | 逐步退场 |
| MIPI CSI-2 | 串行（差分对） | ~4.5 Gbps/通道 | 手机、平板、车载 | 主流 |
DVP接口，我2010年刚入行时还在用。那时候做功能机摄像头，DVP的并行总线一拉就是十几根线，PCB走线走到崩溃。而且DVP的时钟和数据必须等长，稍微差一点就采错数据。后来MIPI联盟推出CSI-2，大家终于解脱了。
LVDS呢？它比DVP好，差分信号抗干扰强，速率也高。但LVDS没有统一的应用层协议，各家Sensor厂商自己定义数据包格式，导致SoC端适配工作量巨大。我记得有个项目，换了一颗LVDS输出的Sensor，结果ISP的LVDS接收模块要重新写驱动，折腾了两周。
所以现在，手机影像系统几乎清一色用MIPI CSI-2。它把物理层、协议层、应用层都标准化了，Sensor厂商和SoC厂商按同一套规范做，兼容性就好很多。
核心结论：新项目选型，优先MIPI CSI-2。除非你做的不是手机，或者有特殊成本要求，否则别碰DVP和LVDS。
3.2 RAW10 / RAW12 / RAW16 数据格式
Sensor输出的原始数据，叫RAW图。RAW图每个像素的bit深度，决定了图像的动态范围和色彩精度。常见的有RAW10、RAW12、RAW16。
你可能会问：为什么不用8bit？8bit不是更省带宽吗？
嗯，8bit确实省，但手机影像现在追求的是高动态范围（HDR）。8bit只能表示256个灰度级，拍大光比场景时，亮部一片白、暗部一片黑。RAW10有1024级，RAW12有4096级，RAW16更是达到65536级。级数越多，后期拉曲线、做HDR合成的空间就越大。
我列个表，把三种格式的带宽占用算清楚：
| 格式 | 每像素bit数 | 200万像素（1080P）单帧大小 | 30fps带宽需求 | 典型应用 |
|---|---|---|---|---|
| RAW10 | 10 bit | ~2.5 MB | ~600 Mbps | 中端手机主摄 |
| RAW12 | 12 bit | ~3.0 MB | ~720 Mbps | 旗舰手机主摄 |
| RAW16 | 16 bit | ~4.0 MB | ~960 Mbps | 专业相机、计算摄影 |
注意，这里说的是原始带宽。实际MIPI传输时，还要加上包开销、帧头帧尾、ECC校验等，大概多出5%~10%。
我在项目中遇到过一个问题：某款Sensor标称支持RAW12输出，但实际配置时发现，它内部ADC只有10bit精度，RAW12是靠软件插值填出来的。这种“假RAW12”拍出来的图像，暗部噪声大得离谱。所以选Sensor时，一定要看ADC的真实bit数，别只看输出格式。
避坑指南：我曾经在选型时只看Sensor datasheet的“Output Format”一栏，结果被坑了一次。后来我养成了习惯——先查ADC精度，再确认输出格式。ADC精度决定了信噪比上限，输出格式只是打包方式。
3.3 MIPI CSI-2 协议栈
MIPI CSI-2协议栈分四层，从下往上分别是：
- 物理层（PHY）：D-PHY或C-PHY，负责电气信号、时钟恢复、差分传输。
- 通道管理层（Lane Management）：把数据分发到多个Lane上，或者从多个Lane合并回来。
- 协议层（Protocol Layer）：定义数据包格式，包括长包（Long Packet）和短包（Short Packet）。
- 应用层（Application Layer）：定义像素数据的排列方式，比如RAW10的打包格式、YUV的排列顺序。
我画了一张协议栈的结构图，帮你理解各层的关系：
这张图你多看几遍。我面试架构师时，经常让候选人对着这张图讲数据流。能讲清楚的人，MIPI这块基本没问题。
3.3.1 物理层：D-PHY vs C-PHY
物理层目前主流是D-PHY，C-PHY是后来推出的，速率更高但兼容性差一些。
| 参数 | D-PHY v1.2 | D-PHY v2.0 | C-PHY v1.0 |
|---|---|---|---|
| 每通道最大速率 | 2.5 Gbps | 4.5 Gbps | ~5.7 Gbps（等效） |
| 信号线数量 | 2根/通道（Data+Clk） | 2根/通道 | 3根/通道（无独立时钟） |
| 时钟方式 | DDR时钟（双边沿采样） | DDR时钟 | 嵌入式时钟（无时钟线） |
| 功耗 | 较低 | 中等 | 较高 |
| 手机应用 | 广泛 | 旗舰机开始采用 | 少量高端平台 |
我个人习惯，在带宽需求不超过10 Gbps时，优先选D-PHY。原因很简单：成熟、稳定、调试工具多。C-PHY虽然速率高，但嵌入式时钟对抖动更敏感，PCB layout要求也更高。我见过一个项目，C-PHY的通道眼图总是闭合，最后发现是电源纹波太大，折腾了两个月才解决。
3.3.2 协议层：长包与短包
协议层定义了两种数据包：
- 短包（Short Packet）：32 bit固定长度，用于帧同步（Frame Start/End）、行同步（Line Start/End）。不携带像素数据。
- 长包（Long Packet）：可变长度，包含包头（32 bit）、数据负载（像素数据）、包尾（16 bit CRC校验）。
一个典型的帧传输序列是这样的：
FS（帧开始短包） → LS（行开始短包） → 长包（第1行数据） → LE（行结束短包）
→ LS → 长包（第2行数据） → LE
→ ...
→ LS → 长包（第N行数据） → LE
FE（帧结束短包）这里有个细节：行开始和行结束短包不是必须的。有些Sensor为了省带宽，只在帧开始和帧结束发短包，行数据用长包连续发送。但这样一旦丢包，整帧数据就错位了。我建议在调试阶段，让Sensor把行同步短包打开，方便定位问题。
注意：我曾经遇到一个Bug，Sensor输出的帧序列里，FS和FE短包的数据类型（Data Type）字段写反了。SoC端按标准解析，结果把帧开始当成帧结束，直接丢弃了整帧数据。排查了三天才发现是Sensor固件配置错误。所以，拿到新Sensor时，先用逻辑分析仪抓一下MIPI波形，确认短包的数据类型是否正确。
3.3.3 应用层：RAW10打包格式
应用层定义了像素数据怎么塞进长包的数据负载里。以RAW10为例，每个像素10 bit，但MIPI传输是按字节（8 bit）对齐的。所以需要一种打包方式，把4个10 bit像素塞进5个字节里。
打包规则如下：
像素0: [9:2] → Byte0
像素0: [1:0] + 像素1: [9:4] → Byte1
像素1: [3:0] + 像素2: [9:6] → Byte2
像素2: [5:0] + 像素3: [9:8] → Byte3
像素3: [7:0] → Byte4你看，5个字节刚好装下4个10 bit像素，没有浪费。这种打包方式叫“4像素打包”，是MIPI CSI-2标准里规定的。
RAW12的打包类似，2个12 bit像素装进3个字节。RAW16最简单，每个像素直接占2个字节，不需要特殊打包。
我在项目中遇到过一个问题：某款ISP只支持RAW10的“4像素打包”方式，但Sensor输出的是“2像素打包”（2个10 bit像素装进3个字节，有浪费）。结果ISP解析出来的图像全是乱的。后来我让Sensor厂商改了固件里的打包模式，才对齐。
经验之谈：选Sensor和ISP时，一定要确认双方支持的RAW打包格式是否一致。MIPI标准里定义了多种打包方式，不是所有芯片都支持全部方式。最好在项目初期就做一次MIPI数据抓包验证，别等到调通I2C、点亮Sensor后才发现问题。
3.4 本章小结
这一章我们聊了三个核心点：
- 接口类型：MIPI CSI-2是手机影像的主流，DVP和LVDS基本退场。
- 数据格式：RAW10/12/16决定了图像质量和带宽需求，选型时要关注ADC真实精度。
- 协议栈：四层结构（物理层→通道管理层→协议层→应用层），每层都有坑，调试时建议从物理层开始逐层排查。