4. I2C/SPI控制接口：Sensor寄存器读写原理与调试实战

好，咱们进入第四讲。前面几章我们把MIPI物理层和CSI-2协议层聊透了，但有个关键问题一直没细说——相机模组是怎么被“控制”起来的？

你想想看，Sensor上电之后，它不会自动输出你想要的帧率、分辨率、增益。你得告诉它：“哥们，现在开始用1920x1080，30fps，增益调到16dB”。这个“告诉”的过程，靠的就是控制接口——I2C或者SPI。

我个人习惯把MIPI数据通道比作高速公路，车流（图像数据）在上面跑得飞快。而I2C/SPI呢？就是这条高速路旁边的维修通道——虽然窄，但控制指令必须从这儿走。

4.1 Sensor寄存器读写原理

每个Sensor内部都有一张寄存器地图（Register Map）。说白了，就是一堆地址和值的对应表。你往地址0x300A写个0x10，Sensor就切换到30fps模式；往0x300B写个0x01，它就开始输出数据。

我刚开始做驱动时，总觉得这玩意儿跟单片机开发差不多。后来踩了个坑才发现——Sensor的寄存器访问有严格的时序要求。

典型的I2C写操作流程是这样的：

1. 主机发送起始条件（S）
2. 发送设备地址（7位或10位）+ 写标志（0）
3. 等待从机应答（ACK）
4. 发送寄存器地址（通常是16位，高字节在前）
5. 等待从机应答
6. 发送要写入的数据
7. 等待从机应答
8. 发送停止条件（P）

读操作稍微复杂一点——需要先写寄存器地址，然后重新发送起始条件，再读数据：

1. 发送起始条件 + 设备地址（写）→ 等待应答
2. 发送寄存器地址 → 等待应答
3. 发送重复起始条件（Sr）
4. 发送设备地址（读标志1）→ 等待应答
5. 读取数据字节 → 主机发送非应答（NACK）
6. 发送停止条件

4.2 高通平台I2C时序配置

到了高通平台上，事情就没那么简单了。高通把I2C控制器封装在QUP（Qualcomm Universal Peripheral）或者SPMI里面。你写驱动时，不是直接操作I2C寄存器，而是通过I2C客户端驱动来配置。

关键配置项有这么几个：

配置项	说明	典型值
clock-frequency	I2C总线时钟频率	100kHz / 400kHz / 1MHz
scl-gpios	SCL引脚对应的GPIO	根据原理图
sda-gpios	SDA引脚对应的GPIO	根据原理图
i2c-sda-hold-time-ns	SDA保持时间	300ns
i2c-scl-falling-time-ns	SCL下降时间	100ns

在设备树（DTS）里，配置大概长这样：

&i2c_4 {
    status = "okay";
    clock-frequency = <400000>;  /* 400kHz */
    pinctrl-0 = <&qupv3_se4_i2c_active>;
    pinctrl-1 = <&qupv3_se4_i2c_sleep>;

    sensor_main: sensor_main@10 {
        compatible = "sony,imx586";
        reg = <0x10>;  /* 7位设备地址 */
        /* 其他属性... */
    };
};

我记得有一次，项目上Sensor死活I2C不通。查了半天，发现是pinctrl配置错了——GPIO被复用成UART功能了。嗯，这种问题在硬件设计阶段最容易埋坑。

4.3 I2C速率与MIPI速率的关系

这个问题经常被新人问起：“I2C跑400kHz，MIPI跑1.5Gbps，它们之间有什么关系？”

说实话，没有直接的物理关系。I2C是控制通道，MIPI是数据通道，两者独立工作。但是——间接关系很大。

为什么？因为Sensor的初始化时间。你想想看，Sensor上电后，要通过I2C写入几十甚至上百个寄存器配置。如果I2C速率太慢，初始化时间就会很长。而系统对相机启动时间（Camera Open Latency）是有要求的——通常要求<500ms甚至<200ms。

我们来算一笔账：

• 假设要写入100个寄存器，每个寄存器16位地址+8位数据=3字节
• I2C协议开销：地址+控制位≈2字节
• 总共需要传输：100 × (3 + 2) = 500字节
• 400kHz速率下，每字节约10位（含ACK），传输时间≈500 × 10 / 400000 = 12.5ms

看起来还好？但别忘了，很多Sensor初始化需要等待内部PLL锁定、等待MIPI PHY稳定，这些时间加起来可能上百毫秒。所以，I2C速率越快，留给其他环节的时间就越充裕。

下面这张图展示了I2C控制与MIPI数据流的关系：

4.4 使用i2cget/i2cset调试Sensor

好了，理论说完了，咱们来点实战的。在Linux终端下，i2cget和i2cset是调试Sensor的瑞士军刀。

先看看怎么用：

# 查看系统上有哪些I2C总线
i2cdetect -l

# 扫描总线4上的设备
i2cdetect -y 4

# 读取Sensor设备地址0x10，寄存器0x300A的值
i2cget -y 4 0x10 0x300A w  # w表示16位寄存器地址

# 向寄存器0x300A写入0x10
i2cset -y 4 0x10 0x300A 0x10 w

这里有几个参数要注意：

• -y：跳过交互确认，脚本里用
• -f：强制访问，即使设备忙
• w：16位寄存器地址模式（大部分Sensor用这个）
• b：8位寄存器地址模式（少部分老Sensor用）

举个例子，IMX586的芯片ID寄存器是0x3000，读出来应该是0x586：

# 确认通信
i2cget -y 4 0x1a 0x3000 w
# 返回：0x0586  → 通信正常

# 软件复位
i2cset -y 4 0x1a 0x3001 0x01 w
sleep 0.1  # 等待复位完成

# 配置输出模式
i2cset -y 4 0x1a 0x3002 0x00 w  # 全分辨率
i2cset -y 4 0x1a 0x3003 0x10 w  # 10-bit输出

还有一个实用技巧——批量读写。如果有一长串初始化序列，手动敲i2cset太慢了。可以写个shell脚本：

#!/bin/sh
# sensor_init.sh
I2C_BUS=4
DEV_ADDR=0x1a

# 寄存器地址:值 列表
REGS="0x3000:0x00 0x3001:0x01 0x3002:0x10 0x3003:0x20"

for pair in $REGS; do
    reg=$(echo $pair | cut -d: -f1)
    val=$(echo $pair | cut -d: -f2)
    i2cset -y $I2C_BUS $DEV_ADDR $reg $val w
    if [ $? -ne 0 ]; then
        echo "Error: failed to write $reg = $val"
        exit 1
    fi
    echo "OK: $reg = $val"
done

嗯，这个脚本虽然简陋，但在项目初期验证Sensor基本功能时非常管用。等驱动写好了，这些操作就交给内核驱动去做了，但调试阶段——命令行永远是最直接的武器。