第四章 通信协议栈：物理层（MIPI/PCIe）、数据链路层、应用层协议设计
各位好，我是老张。今天咱们聊聊MTK8676多屏异构系统的通信协议栈。说实话，这块内容我当年刚接触时也头大，但搞懂了之后，你会发现它其实就是个分层协作的模型。
为什么需要分层？你想想看，如果所有通信逻辑都揉在一起，调试起来得多痛苦。我在项目中遇到过好几次，明明应用层代码没问题，但画面就是卡顿，最后发现是物理层配置出了岔子。所以，分层设计不是理论家的空谈，是实战中逼出来的。
4.1 物理层：MIPI与PCIe的选择
物理层是通信的基石。说白了，它负责把0和1变成电信号，在芯片之间传递。MTK8676支持两种主流方案：MIPI和PCIe。
MIPI DSI/CSI，我习惯叫它「显示专用通道」。它天生为屏幕而生，延迟低，功耗小。但缺点也很明显——带宽有限，单通道最多也就几Gbps。如果你只是驱动一块1080p的副屏，MIPI完全够用。
PCIe就不一样了。它是个通用高速总线，带宽可以做到几十Gbps。我记得有个项目，客户要求主屏4K 60fps，副屏同时跑2K 30fps，还得传触控数据。MIPI直接扛不住，最后上了PCIe Gen3 x4，问题迎刃而解。
核心选择原则：
- 副屏分辨率≤1080p，且数据量小 → 选MIPI（省电、简单）
- 主屏4K以上，或需要同时传多路数据 → 选PCIe（带宽足）
- 两者可以混用：主屏走PCIe，副屏走MIPI
⚠️ 我曾经踩过的坑：MIPI的差分对走线长度必须严格等长。有次PCB layout没注意，两根线差了3mm，结果屏幕直接花屏。后来我学乖了，每次打板前都让硬件工程师出等长报告。
4.2 数据链路层：打包与纠错
物理层只管传比特流，但传着传着可能就错了。数据链路层的任务，就是把比特流组织成「帧」，加上校验，保证数据完整。
在MTK8676上，我一般这样设计数据链路层：
// 帧结构定义
typedef struct {
uint8_t sync_header; // 同步头 0xAA
uint8_t frame_type; // 帧类型：0x01=视频，0x02=音频，0x03=控制
uint16_t payload_len; // 有效数据长度
uint8_t payload[1024]; // 有效数据
uint16_t crc16; // CRC校验
} __attribute__((packed)) data_link_frame_t;嗯，这里要注意。同步头我用了0xAA，为什么？因为它二进制是10101010，接收端容易锁定边界。CRC16我选的是多项式0x8005，这个在嵌入式里很常见，计算速度快。
我个人习惯在帧类型里留几个自定义位。比如0x04可以表示「紧急控制指令」，优先级最高。为什么？因为触控数据如果延迟了，用户体验会非常差。我曾经在车载项目中，就因为触控帧被视频帧堵住，导致用户滑动屏幕时反应慢了半秒，被客户骂惨了。
💡 避坑指南：我曾经把CRC校验放在payload后面，结果发现接收端要先收完整个帧才能校验。如果帧很大（比如4KB），内存开销就上去了。后来我改成「边收边校验」，每收一个字节就更新CRC，收完直接比对。这样内存占用小，速度还快。
4.3 应用层协议：让数据有意义
数据链路层保证了数据能正确到达，但到了应用层，我们得让数据「有意义」。比如，收到一串字节，你得知道它是画面数据还是触控坐标。
我设计应用层协议时，喜欢用「消息ID+属性+数据」的结构：
| 字段 | 长度 | 说明 |
|---|---|---|
| msg_id | 2字节 | 消息ID，如0x1001=画面更新，0x2001=触控事件 |
| attr | 1字节 | 属性位：bit0=是否压缩，bit1=是否加密 |
| timestamp | 4字节 | 时间戳，用于同步 |
| data_len | 2字节 | 数据长度 |
| data | 变长 | 实际数据 |
举个例子。副屏收到一个msg_id=0x1001的消息，它就知道：「哦，主屏让我更新画面」。然后看attr字段，如果bit0=1，说明数据是压缩过的，得先解压再显示。
你可能会问：为什么要加时间戳？我遇到过一个问题：主屏和副屏的时钟不同步，导致画面撕裂。加上时间戳后，副屏可以根据时间戳决定是否丢弃旧帧，保证画面流畅。
实战经验：应用层协议一定要考虑扩展性。我早期设计时只留了2字节的msg_id，结果后来功能多了，ID不够用。现在我都用4字节，前2字节表示模块（如0x10=显示模块），后2字节表示具体命令。这样最多支持256个模块，每个模块256条命令，够用很久了。
4.4 三层协作：一个完整的通信流程
光说理论没意思，咱们看个实际流程。假设主屏要传一帧画面给副屏：
- 应用层：主屏的应用层构造一个「画面更新」消息，msg_id=0x1001，数据是压缩后的JPEG流。
- 数据链路层：把应用层消息塞进payload，加上同步头0xAA、帧类型0x01、CRC16。然后交给物理层。
- 物理层：如果是MIPI，就通过DSI通道发出去；如果是PCIe，就通过DMA引擎发送。
- 副屏接收：物理层收到比特流，数据链路层校验CRC，解出帧。应用层根据msg_id调用对应的处理函数，解压并显示。
整个过程，从主屏应用层到副屏应用层，延迟能做到10ms以内。我实测过，PCIe方案延迟约3ms，MIPI方案约5ms。嗯，这个数据在车载和工业场景下完全够用。
💡 我的调试习惯：三层协议都加上调试日志。应用层打印「发送msg_id=0x1001」，数据链路层打印「发送帧，CRC=0x1234」，物理层打印「发送1024字节」。这样一旦出问题，看日志就知道是哪一层卡住了。我曾经靠这个办法，半小时就定位到一个PCIe驱动DMA配置错误的问题。
4.5 总结与建议
好了，这一章的内容就这些。总结一下：
- 物理层：MIPI适合小屏低功耗，PCIe适合大屏高带宽。可以混用。
- 数据链路层：帧结构要设计好，CRC校验不能省。边收边校验是实战技巧。
- 应用层协议：消息ID要留足扩展空间，时间戳解决同步问题。
最后说一句：协议栈设计没有银弹。你得根据实际场景去权衡。比如功耗敏感的设备，就别上PCIe；延迟敏感的设备，就别在应用层搞复杂的压缩算法。多想想你的产品到底要什么，再动手设计。
下一章，咱们聊聊多屏同步的时钟方案。那个更有意思，到时候见。