2. 协议分层模型总览：物理层、协议层、应用层职责划分

刚接触MIPI CSI-2的时候，我看协议文档看了三天，脑子里还是一团浆糊。后来我带我的新人，第一件事就是让他把分层模型吃透。

我个人习惯把这三大层想象成一个物流系统——物理层是货车和公路，协议层是分拣中心和快递单，应用层是收件人手里的包裹。各管各的，又环环相扣。

2.1 为什么非得分三层？

说白了，就是为了解耦。你想想，如果摄像头模组换了一颗传感器，协议栈要重写，那谁受得了？

• 物理层只关心「怎么把0和1送过去」—— 差分电压、时钟恢复、阻抗匹配
• 协议层只关心「这一包数据是什么」—— 长包还是短包、哪个虚拟通道、数据对不对
• 应用层只关心「像素怎么拼成图像」—— RGB还是YUV、分辨率多少、帧率多少

我在项目中见过有人把协议层的CRC错误一路追到示波器上量眼图，折腾了一周才发现是DT（数据类型）配错了。嗯，分层边界没搞清楚，debug就像无头苍蝇。

2.2 物理层——信号的搬运工

物理层是整个CSI-2协议栈的地基。它不关心你传的是像素还是麦克风数据，它只管把比特流从发端搬到收端。

MIPI物理层目前主要有两种标准：D-PHY 和 C-PHY。D-PHY用差分对，一条lane一对线，时钟独立走。C-PHY用三线制，一条lane三根线，时钟嵌入在数据里。

我在调试D-PHY时踩过不少坑。有一次眼图张得不够开，量来量去发现是PCB上差分对的等长差了12mil。嗯，有时候物理层的问题就是怎么量都像协议层，但其实是信号质量到了临界点。

2.3 协议层——数据的翻译官

物理层把比特流送上来之后，协议层就要开始干活了。它回答三个问题：这是什么包？数据对不对？该给谁？

CSI-2协议层定义了两种包：长包（Long Packet） 和 短包（Short Packet）。长包带数据负载，比如一行的像素。短包只带包头，通常做帧同步、行同步用。

每个包都有一个包头（PH），里面包含了虚拟通道号（VC）和数据类型（DT）。DT告诉接收方这一包数据是RAW10还是YUV422，或者其他格式。

// CSI-2 长包结构示意（伪代码）
PacketHeader {
    DataIdentifier (VC[1:0] + DT[5:0])  // 虚拟通道 + 数据类型
    WordCount (16bit)                   // 数据负载长度
    ECC (8bit)                          // 包头纠错码
}

PacketData {
    payload[WordCount]                  // 像素数据
    CRC (16bit)                         // 数据校验码
}

我建议你在做协议层调试时，先抓一组ECC和CRC的计数值。如果ECC报错但CRC没报，大概率是物理层有偶发干扰；反过来，ECC全对但CRC狂报，那可能是发送端的包组装逻辑有问题。

2.4 应用层——像素的归宿

到了应用层，我们终于可以忘记差分信号、忘记包结构、忘记ECC了。应用层只关心一件事：怎么把字节流还原成一帧一帧的图像。

应用层定义了几件事情：

• 像素格式：RGB888、YUV422 8-bit、RAW10、RAW12……每种格式的比特排列都不同
• 帧结构：哪一包是帧起始（FS）、哪一包是行起始（LS）、哪一包是帧结束（FE）
• 虚拟通道复用：多路摄像头通过同一组物理通道传输，应用层根据VC号分发数据

举个例子，一个RAW10格式的像素，在内存里不是简单地每个像素占10个bit，而是5个像素打包成5个字节（每像素8bit）+ 5个像素的高位拼成另一个字节。我第一次配这个的时候，图像出来全是斜条纹——因为字节对齐搞错了。

2.5 三层怎么配合？

讲完三层各自的分工，最后串一个实际场景。假设一颗摄像头输出1920x1080 YUV422 8-bit，通过2-lane D-PHY传输：

1. 物理层：传感器端D-PHY将并行像素数据串行化，通过2对差分线+1对时钟线发送出去。接收端做时钟恢复、lane对齐、串并转换。
2. 协议层：接收端检测到SoT（Start of Transmission），开始拼包。解析PH得到DT=0x1E（YUV422 8-bit）、VC=0、WordCount=3840（一行1920像素×2字节）。校验ECC和CRC，无误后将payload送给上层。
3. 应用层：根据FS/FE包确定帧边界，按YUV422格式解析每个像素的Y、U、V分量，写入DMA缓冲区。一帧完整后送给ISP处理。

任何一个环节出问题，摄像头就出不了图。但只要你清楚问题发生在哪一层，debug就有了方向。