数据格式long_packet_header在 MIPI D-PHY 的长包Long Packet结构中Packet Header包头简称 PH就像是数据快递箱上的“物流面单”。它固定为 32 bit4个字节里面包含了接收端处理后续真实数据所需的所有关键信息。你提到的 DI、WC 和 VCX 正是这张“面单”上最核心的三个字段。我们可以结合它们的具体作用来逐一拆解️ DI (Data Identifier)包裹的身份标签DI 是包头的第一个字节8 bit它的作用是指明这个包裹里装的是什么东西以及该交给谁。它由两部分组成DT (Data Type数据类型)占据低 6 位。它告诉接收端有效载荷Payload里的数据是什么格式比如是 RAW10 图像数据、RGB888 像素流还是 YUV 视频数据VC (Virtual Channel虚拟通道)占据高 2 位。它用来标记这个数据包属于哪一个逻辑通道比如 VC0、VC1。在多摄像头或混合数据传输的场景中接收端会根据这个 VC 编号把数据分流到不同的处理流水线。 WC (Word Count)包裹内的货物数量WC 占用接下来的两个字节16 bit。它的含义非常直观就是“字数统计”。它明确声明了在这个包头PH之后、包尾PF之前到底有多少个字节Byte的有效数据。因为它是 16 位的所以最大可以表示 65535即 2的16次方 - 1个字节的数据长度。接收端的硬件电路会死死盯着这个数值读完指定数量的字节后就知道这一批货物的主体已经收完了。 VCX (Virtual Channel Extension)虚拟通道的扩充位VCX 位于包头的最后一个字节中它的作用是“扩容”。刚才提到DI 里的 VC 只有 2 位这意味着如果不加扩展系统最多只能支持 4 个虚拟通道00、01、10、11。但在一些复杂的工业或汽车电子场景中4 个通道不够用。于是协议在包头的 ECC错误校验码部分借用了高 2 位作为 VCX。组合使用将 DI 中的 2 位 VC 和这里的 2 位 VCX 拼在一起就组成了一个完整的4 位虚拟通道标识符VCID。这样一来D-PHY 的虚拟通道数量就从 4 个扩展到了16 个0~15能够从容应对更复杂的多路数据交织传输需求。为了让你看得更清楚这 32 bit 的 Packet Header 内部结构大致如下表格组成部分字段名称位数核心作用第1字节DI(Data Identifier)8 bit身份标签包含 6bit 数据类型(DT) 2bit 基础虚拟通道(VC)第2-3字节WC(Word Count)16 bit货物计数声明后面跟着多少个字节的真实数据第4字节ECC VCX8 bit质检与扩容6bit 纠错码(ECC) 2bit 扩展虚拟通道(VCX)简单来说当接收端的 LMF通道合并功能把分散在各个 Lane 上的字节拼回完整的包头后它会先看DI确认这是什么数据、该走哪条道再看WC准备多大的内存空间来接收后面的数据而VCX则确保了在超多通道的复杂环境下数据依然能被精准地识别和分流。short_packetVC_Lane完全不是哦VC虚拟通道和 Lane物理通道没有任何直接的对应关系。这是一个非常容易混淆的概念我们可以用两个生动的比喻来彻底区分它们️ 高速公路与车道Lane (物理通道)就像是一条高速公路上的实体车道比如 4 车道高速公路的左一、左二、右一、右二车道。它是实实在在的物理线路负责传输电信号。VC (虚拟通道)就像是行驶在这些车道上的不同颜色的汽车比如红色车队 VC0、蓝色车队 VC1。在 MIPI 协议中这些“红车”和“蓝车”可以同时混跑在同一条或几条“实体车道”上。接收端LMF收牌员把数据收回来后会根据数据包上的颜色标签VC ID把红色的货卸给 A 仓库蓝色的货卸给 B 仓库。 快递包裹与运输卡车结合你之前了解的 LDF发牌员概念Lane就是负责送货的大货车。如果你有 4 条 Lane就相当于有 4 辆并排开的卡车。VC就是包裹面单上的收件人代号比如“张三件”、“李四件”。LDF 发牌的时候根本不管包裹是寄给谁的不看 VC它只是机械地把所有包裹轮流塞进这 4 辆卡车里。等货物到了目的地接收端拆开包裹一看面单“哦这个 DI 字段写着 VC0这是给张三的那个写着 VC1是给李四的。” 为什么要把它们分开这种“逻辑”与“物理”分离的设计非常精妙主要解决了以下痛点混合数据同路传输你可以在同一组物理 Lane 上同时传输完全不同类型的数据。比如VC0 传摄像头的 RAW 图像数据VC1 传传感器的陀螺仪参数。它们在物理线路上交织在一起接收端靠 VC 就能完美把它们剥离出来。多摄共用接口如果手机有两个摄像头不需要拉两套独立的 MIPI 线。可以让两个摄像头的数据分别打上 VC0 和 VC1 的标签共用同一组 4-lane 物理接口传给处理器极大地节省了手机内部宝贵的布线空间和引脚成本。HDR 行交织在一些高端摄像头如索尼支持 DOL-HDR 的 Sensor中长曝光的一行数据和短曝光的一行数据会交叉着发出来。为了不让处理器搞混哪行是哪行Sensor 会给长曝光行打上 VC0短曝光行打上 VC1。这样即使它们在物理 Lane 上是穿插传输的处理器也能通过 VC 轻松重组出两帧完整的画面。所以总结一下Lane 决定了数据传输的“路有多宽、跑得有多快”而 VC 决定了这些数据“属于谁、该交给谁处理”。long_short_dt_vc 核心总结VC 与 DT 的关系VC虚拟通道逻辑上的“发货人”。在同一个逻辑事件流中比如一个摄像头拍一张照片无论是喊话的短包还是干活的长包VC始终保持一致。接收端靠它来精准分流数据。DT数据类型包裹里的“实际内容”。短包和长包的 DT绝大多数情况下完全不同因为它们分工极其明确——短包负责“指挥交通”长包负责“运输货物”。⚡ 数据传输规律并不只是死板的“一短一长”MIPI 的数据流像是一列有严格编组规则的火车遵循以下三个核心规律宏观框架由“帧级短包”定边界。绝对以帧开始短包FS, DT0x00开头以帧结束短包FE, DT0x01结尾。中间主体由“N个长包”填充。在 FS 和 FE 之间会塞入 N 个长包来传输像素数据。微观细节可能穿插“行级短包”。部分 Sensor 会在每一行图像前后插入行开始LS, DT0x02和行结束LE, DT0x03短包。常见的两种传输场景常规模式[FS短包]-[一堆长包]-[FE短包]带行同步模式[FS短包]-[LS短包]-[长包]-[LE短包]- ... -[FE短包] 短包的 DT (0x00 ~ 0x0F)指挥交通的控制指令短包不携带大块数据主要用于传输同步信号或简短控制信息0x00 (Frame Start)帧开始。标志着新一帧图像数据的传输正式开始。0x01 (Frame End)帧结束。标志着当前帧的所有数据已经发送完毕。0x02 (Line Start)行开始可选。标志着新的一行图像数据开始。0x03 (Line End)行结束可选。标志着一行图像数据传输完成。0x08 ~ 0x0F (Generic Short Packet)通用短包。用于传输用户自定义的简短控制指令如触发闪光灯、快门等应用层信令。 长包的 DT (0x10 ~ 0x37)运输货物的具体内容长包负责承载大块的负载数据根据数据格式的不同DT 被划分得非常细致0x10 ~ 0x17 (通用长包)0x10空包忽略内容0x11消隐数据0x12嵌入式数据常用于附带 Sensor 的曝光时间、增益等元数据 Metadata。0x18 ~ 0x1F (YUV 格式)涵盖 YUV420、YUV422 等不同采样格式及位深。0x20 ~ 0x27 (RGB 格式)涵盖 RGB888真彩色、RGB565常用手机屏显、RGB555 等格式。0x28 ~ 0x2F (RAW 原始数据)Sensor 最原生的 Bayer 阵列数据。0x2ARAW88-bit0x2BRAW10目前极常用0x2CRAW12 等。0x30 ~ 0x37 (用户自定义)完全开放给用户传输任何基于字节的自定义数据。通过这套严密的规则接收端的 ISP 只要读取包头的 VC 和 DT就能立刻知道这批数据“是谁发的”、“是控制指令还是像素数据”、“具体是什么格式的像素”从而进行精准的处理。long_pack_dt_0x12长包中的0x12嵌入式数据 / Embedded Data是 MIPI 协议中一个非常实用且特殊的“隐藏通道”。简单来说如果把传输图像的 RAW/YUV 长包比作“运送海鲜的冷链车”那么 0x12 长包就是跟在这辆车后面、专门用来“附带发货单据和温度记录的小货车”。它不运送实际的图像像素而是运送关于这张图像的元数据Metadata。以下是关于 0x12 嵌入式数据的详细拆解 0x12 里面到底装了什么这部分数据通常由摄像头 Sensor传感器自动生成紧跟在某一帧图像数据的前面或后面发送。里面包含的信息五花八门常见的有Sensor 的实时状态比如拍摄这一帧画面时的曝光时间、模拟/数字增益值。时间与同步信息精确到微秒的时间戳、帧号等。硬件配置参数镜头的对焦位置、光圈大小甚至是 Sensor 内部的温度读数。其他自定义信息厂商自己定义的一些调试数据或校验码。 为什么要用 0x12 传这些数据你可能会问“为什么不直接通过 I2C/SPI 总线去读取这些寄存器呢” 使用 0x12 嵌入式数据包有两个巨大的优势绝对的时序同步防“张冠李戴”如果通过 I2C 单独去读 Sensor 的曝光时间由于通信延迟你读到的可能是“上一帧”甚至“上上帧”的参数。而 0x12 数据包是和图像数据一起从 MIPI 高速通道发出来的它能保证这批参数绝对属于紧接着的那一帧图像严丝合缝。不占用额外的控制带宽对于高帧率比如 60fps、120fps的摄像头频繁通过低速的 I2C 总线去轮询状态会把总线占满。把状态信息直接打包进视频流里“顺路”带走效率极高。 实际应用场景举例手机的 3A 算法自动曝光/对焦/白平衡手机 ISP图像信号处理器在处理图像时需要知道当前这帧画面的曝光时间和增益具体是多少才能精准地计算下一帧该怎么调整亮度。通过解析 0x12 数据包ISP 就能拿到最准确的实时反馈。自动驾驶与机器视觉在自动驾驶中系统需要把摄像头拍到的画面与激光雷达、毫米波雷达的数据进行融合。这就要求每一帧图像都必须带有一个极其精准的硬件时间戳。这个时间戳通常就放在 0x12 嵌入式数据里确保多传感器融合时的时空对齐。工业检测与 HDR在一些复杂的工业场景或高动态范围HDR成像中需要记录每一行或每一帧的特殊配置以便后续的软件算法进行还原和校正。⚙️ 接收端如何处理 0x12在实际的开发中比如在 Linux 的 V4L2 驱动或 Android 的 Camera HAL 层处理 0x12 数据通常有两种方式剥离Strip很多传统的图像处理流程不需要这些元数据接收端的硬件或驱动会在收到 0x12 数据包后直接把它过滤掉只把后面的图像数据送入内存。提取Extract在需要高级功能的场景下驱动程序会识别出 DT0x12 的长包将其中的数据提取出来封装成特定的结构体交给上层的算法库去使用。总结一下0x12 就是 MIPI 视频流里的“黑匣子”它让图像数据不再是孤立的像素点阵而是带上了丰富的“身份信息”极大地方便了后续的 ISP 处理和系统调试。0x12 嵌入式数据的传输频率并没有一个绝对固定的标准它完全取决于摄像头 Sensor传感器厂商的寄存器配置。不过在实际应用中最常见的情况是每帧图像传输一次。我们可以根据具体的应用场景把它分为以下几种常见的模式 按帧传输最常见绝大多数普通的手机、安防或工业摄像头都采用这种模式。Sensor 会在每一帧图像数据开始前通常在FS帧开始短包之后插入一个包含该帧元数据如曝光时间、增益、时间戳等的 0x12 长包。频率与摄像头的帧率FPS完全同步。举例如果你的摄像头设定为 30 FPS那么 0x12 数据包就会每秒出现 30 次每次紧跟在对应的一帧画面前面。 按行传输特殊场景在一些高端的机器视觉、科学成像或者特殊的 HDR高动态范围模式下Sensor 可能会为每一行像素都附带独立的元数据。此时0x12 数据包会夹杂在每一行的LS行开始和LE行结束短包之间。频率极高。假设一帧图像有 1000 行30 FPS 的情况下0x12 数据包每秒就会出现 30,000 次用途通常用于需要逐行精准控制曝光或读取极高频传感器状态的场景。⏱️ 按需或低频传输有些 Sensor 支持通过 I2C 寄存器来配置 0x12 的发送策略。开发者可以将其设置为“每隔 N 帧发一次”或者仅在特定触发条件下才发送。频率不固定由软件配置决定。用途适用于对带宽极其敏感且不需要实时获取每一帧状态参数的低功耗场景。 如何确定你的设备是哪种频率如果你手头有具体的摄像头模组最准确的方法是查阅它的Datasheet数据手册或寄存器配置手册Register Map。手册中通常会有一章专门介绍 Embedded Data 或 Metadata 的配置选项里面会明确说明它是按帧发送还是按行发送以及如何在数据流中定位这些 0x12 包。
