MIPI CSI2 V1.2协议摘要

协议原始文档

1、概述

• 原内容略。

• 额外补充——V1.x的差异：

  • V1.1：支持非连续时钟，以及更高效的错误检测和纠正机制。
  • V1.2：引入了虚拟通道的概念，增加了对更复杂应用场景的支持， 例如多摄像头配置和高速数据流管理。

2、术语

• 需关注的定义：
  • 虚拟通道（Virtual Channel）：本规范支持高达4个外设的多条独立数据流， 每个外设的数据流（是否一个外设能有多条，此处指其中一条？）就是一条虚拟通道。 这些数据流可互相交错，并以顺序报文的形式进行传输，且每个报文属于一个特定的外设或物理通道。
• 需关注的缩略词：
  • BER：Bit Error Rate，误码率。
  • CCI：Camera Control Interface，相机控制接口。
  • CSI：Camera Serial Interface，相机串行接口。
  • DI：Data Identifier，数据标识符。
  • DT：Data Type，数据类型。
  • ECC：Error Correction Code，纠错码。
  • FE：Frame End，帧尾。
  • FS：Frame Start，帧首。
  • LE：Line End，行尾。
  • LS：Line Start，行首。
  • LLP：Low Level Protocol，低级协议。
  • PF：Packet Footer，报文尾。
  • PH：Packet Header，报文头。
  • PI：Packet Identifier，报文标识符。
  • PT：Packet Type，报文类型。
  • SLM：Sleep Mode，休眠模式。

3、引用资料

略。

4、CSI-2概述

非常简单。略。

5、CSI-2各层定义

• 应用层：在更高的层次上对数据流进行编码和翻译， 主要是从像素值（pixel values）到字节（bytes）的映射。 这一层的产出是像素。

• 协议层：规定如何对多条数据流在发送端进行标记（tagged）和交织（interleaved）， 以便在接收端能正确地重构（reconstructed）。该层又可细分为3个子层：
  • 像素与字节的互转（Pixel/Byte Packing/Unpacking）层：
    • 发送端将（来自于应用层的）像素转成字节的操作叫打包。
    • 接收端将（来自于LLP层的）字节转成像素的操作叫解包。
    • 根据不同的图像格式，像素的位数可从6位到24位不等。
    • 对于8位像素，实际上可省略打包和解包操作。
  • 低级协议（Low Level Protocol）层：
    • 对SoT和EoT之间的串行数据建立位级别和字节级别的同步。
    • 最小数据粒度为字节。
    • 规定字节内部高低位的传输顺序。
    • 以报文的形式来组织数据。发送端会为数据加上报文头和（可选的）错误校验信息， 接收端在提取数据时则需要剥离报文头，以及进行差错校验。
  • 通道管理（Lane Management）层：
    • 发送端将数据分发到各个通道。
    • 接收端将各个通道的数据聚合，并重组成原始数据流。
• 物理层：描述传输介质（电导体）的电气特性，以及信号的时序关系。 这一层既有字节级（byte-level）的同步机制（synchronization mechanism）， 也有位级（bit-level）的同步机制。

6、相机控制接口（CCI）

• 基于I2C。要快速了解I2C，可参考这篇文章。

• 在CCI总线，接收端作为主机（Master），发送端作为从机（Slave）—— 这既与较新版的I2C协议文档淡化主从关系（已改用控制器、目标等名称）的描述不同， 也与物理层的同名术语毫无关系。

• CCI协议只是给出控制消息的通用格式，每款摄像头的消息内容由厂商自行定义。

• CCI比标准I2C多一个子地址（sub address），又叫索引——（index）。 索引可支持8位，也可支持16位，但仍以字节为单位进行传输。

• 至于数据，都是8位，但多个数据字节可合并成最终供上层使用的16位、32位等数据类型。

• （单字节寄存器的）读写时序：
  • 原文档将读操作分为4种，写操作分为2种，不利于记忆。
  • 由于每次读写之后，索引均会自增一次，再根据是否指定索引和何时发NACK， 读操作可简化成2种，写操作可简化成只有1种，如下：
    • 从指定位置读取（即随机读）：
      • 需要指定索引。
      • 共同前置时序为：
        START -> Slave Address -> 0 -> ACK -> Index -> ACK
        -> Repeated START -> Slave Address -> 1 -> ACK
      • 若只读1次就发NACK，则为原文档的单次随机读（Single Read from Random Location）；
      • 若读多次，除了最后一次发NACK，前面几次均发ACK， 则为原文档的随机顺次读（Sequential Read Starting from a Random Location）。
      • 注意：一旦发NACK，紧接着就应发STOP来结束操作，这是I2C协议的基本要求，下同。
    • 从当前位置读取：
      • 不需要指定索引。
      • 共同前置时序为（比随机读要简化好多，相当于从Repeated START开始）：
        START -> Slave Address -> 1 -> ACK
      • 若只读1次就发NACK，则为原文档的从当前位置读一次（Single Read from the Current Location）；
      • 若读多次，除了最后一次发NACK，前面几次均发ACK， 则为原文档的从当前位置顺次读（Sequential Read Starting from the Current Location）。
    • 从指定位置写入（即随机写）：
      • 需要指定索引。
      • 共同前置时序为：
        START -> Slave Address -> 0 -> ACK -> Index -> ACK
      • 若只写1次就发ACK/NACK和STOP，则为原文档的单次随机写（Single Write to a Random Location）；
      • 若写多次才发STOP（最后一次既可发ACK也可发NACK，前面几次均发ACK）， 则为原文档的顺次写（Sequential Write）。
  • 不支持从当前位置写入的操作，因为写操作是一种破坏性操作，最好要明确指定位置， 否则依赖于早前读写操作自增到达的位置并不保险，因为某些操作可能引起复位。
• 从机（即摄像头）地址：
  • 仅支持Raw Bayer格式的设备：0x36或0x37
  • 其他设备：0x3C或0x3D
  • 需要指出的是，尽管CCI规范对从机地址有以上规定，但实际上不少摄像头的地址支持定制， 不过默认值通常按规范来设置。
• 多字节寄存器：
  • 多字节寄存器地址应是第1个字节的地址，所以相邻两个寄存器的地址并不连续。
  • 虽然多字节寄存器位宽有16、32、64位之分， 但使用的索引宽度和每次传输的数据宽度仍与前面单字节寄存器的一样。
  • 高字节位于低地址，低字节位于高地址——所以会先传输高字节。
  • 第一个字节的地址是否与寄存器宽度对齐（类似于C语言的结构体内部字段对齐），取决于实现。
  • 不允许只访问多字节寄存器的部分字节。
  • 对多字节寄存器的访问时序类似于单字节寄存器的随机顺次读/写时序， 且接受数据的一方（不论主从）应该知道何时应发NACK，但有几点需要强调：
    • 对于写操作，是先写到临时缓冲区，要等到最后一个字节的最后一位传输完， 才能更新寄存器内容。
    • 对于读操作，在读取第一个字节的第一位时，所有字节的内容就应该反映到临时缓冲区， 然后再逐位传输到SDA线。
    • 以上涉及到临时缓冲区的描述，仅作为一种实现方案来举例，目的是更好解释读写一致性的行为和现象。 对于临时缓冲区的更新和清零条件，详见6.3.3.1
    • 6.3小节的所有图都应该加上寄存器地址（即首字节的索引值）， 并且最后一个字节跟的是NACK而非ACK。

7、物理层（PHY）

• 原文只是对物理层的一些核心要求进行列举。对于详细的D-PHY规范， 这篇文章可以作为一个阅读指引，至于C-PHY暂时不涉及。

• 原文还重点提到收发端对于时滞校准（Deskew Calibration）的一些设计要求， 尤其是建议周期性校准操作最好放到竖直消隐期或帧空隙。

8、重点：多通道的数据分发和聚合（通道管理层）

• 适用于想要更高带宽或想要避免高时钟速率（以降低电磁兼容性问题）的应用。

• 设计理念很简单，对于应用开发者而言，只要理解该理念，剩下的工作就是通过CCI配置好相关寄存器， 实际的数据分发和聚合工作就可交由硬件自动完成。通道管理层的核心理念有2个：
  • 缓冲：一次最多缓冲N字节，其中N为启用的通道数。
  • 负载均衡：采取公平轮流（round-robin）的策略进行分发。
• 发送端的逻辑结构（从上至下）：
  • 来自高层（即LLP层）的字节流
  • 通道分发功能单元（Lane Distribution Function，含缓冲器，即buffer）
  • （每条通道的 ）发送队列
  • 序列化功能单元（Serializer，统一表示成SerDes）
• 接收端的逻辑结构（从下至上）：
  • 反序列化功能单元（Deserializer，统一表示成SerDes）
  • （每条通道的）接收队列
  • 通道聚合功能单元（Lane Merging Function，含缓冲器，即buffer）
  • 投递给高层（即LLP层）的字节流
• 每条通道的收发时序（此处已属于物理层功能）：LPS -> SoT -> Bytes … -> EoT -> LPS

9、重点：低级协议（LLP）

• 特性概述：
  • 能传输任意形式的数据，即不关心有效载荷的格式。
  • 面向字节（byte orientated），基于报文（packet based）。
  • 同一链路上（即物理通道）最多支持4条虚拟通道交织（interleaved）。
  • 帧首、帧尾、行首、行尾信息有相应的特殊报文。
  • 定义了各种报文类型、像素深度和特定应用载荷数据格式的标识值。
  • 设置16位校验码用于错误检测。
• 报文格式（指位于LPS和SoT之后、EoT和LPS之前的内容）：
  • 长包格式（Long Packet Format）：
    • PH：报文头，32位。构成如下：
      • 8位DI（数据标识符）：
        • VC：虚拟通道，高2位，所以最多支持4条通道。
        • DT：数据类型，低6位，所以总共有64个类型，并且：
          • 分为8个大类。其中前2个大类用于短包，后6个用于长包。
          • 每个大类又细分为8个具体类型。
          • 详细内容见9.4、9.8小节和第11章。
      • 16位Word Count（字数）：
        • 实际上是Payload的字节数，因为此处使用的是8位字（8-bit words）。
        • 字节顺序：先传低字节，再传高字节。如无特殊说明，其他字段亦是如此。
        • 字节内的位顺序：先传低位，再传高位。如无特殊说明，其他字段亦是如此。
      • 8位ECC（纠错码）：
        • 对于PH除ECC自身的其他字段，能检测出发生在他们身上的2比特错误（2-bit errors）， 以及修正单比特错误（single-bit errors）。
        • 原理详见9.5节。
    • Payload：
      • 有效载荷字节流，长度不固定，但通常上层应用会对长度有所要求， 例如是4的整数倍字节。
      • 由于是字节流，所以字节之间的顺序在上一层就应该先定好。
      • 接收方不需要检查任何同步信号，仅需按预设的Word Count接收足够数量的字节即可， 所以此阶段可简化接收逻辑，并且不必关心具体的字节值。
    • PF：报文尾，16位。构成如下：
      • 16位Checksum（校验和）：其生成原理详见9.6节。
  • 短包格式（Short Packet Format）：
    • PH：与长包的PH一样的结构，但内部字段的含义和取值不尽相同，以下仅列出不同之处：
      • 16位百变字段：位置与长包的Word Count字段一样，但根据DT的不同， 可存放帧编号（帧同步是必需的）、行编号（行同步是可选的）或用户自定义内容。
• 报文间隙（指前一报文的EoT、空闲期LPS和当前报文SoT的总时长）：
  • 长度不固定。
  • 详见9.7、9.10小节。
• 图像帧格式：
  • 简单说明见9.11、9.12小节。
  • 详细说明见第11章。
• 数据交织（Data Interleaving）：
  • 按数据类型：见9.13.1小节。
  • 按虚拟通道：见9.13.2小节。

10、色彩空间

• RGB：采用IEC 61966标准的sRGB色彩模型。

• YUV：采用ITU-R BT601.4标准的YCbCr色彩模型。

11、数据格式

• 可分为YUV、RGB、Raw和用户自定义格式，详情可查阅原文档，不在此展开。

12、推荐的内存储存格式

• 主要是对传输的字节序、数据字节与内存地址的对应关系的设计建议，并与前一章有联系。详情略。

附录A：JPEG8数据格式（信息拓展）

略。

附录B：CSI-2实现方案举例（信息拓展）

略。

附录C：CSI-2接收端所推荐的错误处理行为（信息拓展）

对于调试工作有参考意义，可按需查阅。详情略。

附录D：CSI-2睡眠模式（信息拓展）

略。

附录E：用于原始数据类型的压缩方案（信息拓展）

略。

附录F：JPEG数据与其他类型数据的交织（信息拓展）

略。