4. I2C/SPI控制接口移植：Codec寄存器读写接口的实现
好，咱们进入第四章。这一章聊的是Codec的“命门”——控制接口。
你想想看，语音算法跑在Codec上，你得配置采样率、增益、滤波器系数、路由开关……这些全靠控制接口来写寄存器。I2C和SPI，就是最常用的两种。接口没写好，算法再牛也白搭。
我个人习惯把控制接口的移植分成四块：速率适配、模式选择、缓存策略、调试方法。咱们一块一块说。
4.1 I2C速率适配：别让时钟成为瓶颈
I2C是个经典的总线协议。Codec这边，标准模式100kHz，快速模式400kHz，有些新片子支持高速模式3.4MHz。但问题来了——你的主控端能不能跑那么快？
我在项目中遇到过一件事：某款智能音箱，主控是Amlogic的芯片，Codec是TI的TLV320AIC3254。I2C配置成400kHz，结果写寄存器偶尔失败。抓波形一看，主控的SCL高电平时间不够，Codec不认。最后降到300kHz才稳定。
所以，速率适配的核心原则是：以Codec的规格为上限，以主控的实际驱动能力为下限。
速率适配三步走：
- 查手册：确认Codec支持的I2C速率范围（通常有min和max）。
- 测波形：用示波器看SCL/SDA的上升沿、下降沿、高电平宽度。主控的I/O驱动强度不够，波形会变“圆”，导致时序违规。
- 降速验证：先按100kHz跑通所有寄存器读写，再逐步提速。别一上来就怼400kHz。
小技巧：如果主控支持I2C时钟拉伸（Clock Stretching），记得在驱动里打开。有些Codec在内部处理时会拉低SCL，主控不响应拉伸就会丢数据。
4.2 SPI模式选择：CPOL和CPHA的排列组合
SPI比I2C快，但模式多。CPOL（时钟极性）和CPHA（时钟相位）组合出4种模式。Codec通常只支持其中1-2种，选错了，读回来的数据全是乱的。
| 模式 | CPOL | CPHA | 数据采样边沿 | 常见Codec举例 |
|---|---|---|---|---|
| 模式0 | 0 | 0 | 第一个边沿（上升沿） | WM8960, AK4962 |
| 模式1 | 0 | 1 | 第二个边沿（下降沿） | 少见 |
| 模式2 | 1 | 0 | 第一个边沿（下降沿） | CS42L52 |
| 模式3 | 1 | 1 | 第二个边沿（上升沿） | TLV320AIC3104 |
嗯，这里要注意：SPI模式必须在初始化时固定，不能在运行中切换。我见过有人把CPOL和CPHA放在结构体里，每次读写前重新配置——结果主控的SPI控制器重新初始化时，CS片选会抖动，Codec直接复位了。
避坑指南：我曾经在ADAU1761上踩过坑。它的SPI接口要求CS在传输期间必须保持低电平，但主控的SPI控制器在连续传输之间会自动拉高CS。解决办法是改用GPIO模拟CS，手动控制拉低拉高时序。
4.3 寄存器缓存策略：少读多写，减少总线开销
语音算法对实时性要求高。你每读一次寄存器，I2C/SPI总线就要占用几十微秒。如果算法循环里频繁读寄存器，音频流就可能断断续续。
我的策略很简单：在内存里维护一份寄存器缓存（Shadow Register）。
/* 寄存器缓存结构体示例 */
struct codec_reg_cache {
uint8_t *regs; /* 缓存数组，索引=寄存器地址 */
uint16_t num_regs; /* 寄存器总数 */
uint8_t dirty_mask; /* 脏标记位图，标记哪些寄存器被修改过 */
};
/* 写寄存器：先写缓存，再写硬件 */
int codec_write_reg(uint8_t addr, uint8_t val) {
cache->regs[addr] = val; /* 更新缓存 */
cache->dirty_mask |= (1 << (addr % 8)); /* 标记脏 */
return hw_i2c_write(addr, val); /* 实际写硬件 */
}
/* 读寄存器：优先从缓存读 */
int codec_read_reg(uint8_t addr) {
return cache->regs[addr]; /* 直接从缓存返回 */
}
/* 批量同步：在音频帧间隙调用 */
void codec_sync_cache(void) {
for (int i = 0; i < cache->num_regs; i++) {
if (cache->dirty_mask & (1 << (i % 8))) {
hw_i2c_write(i, cache->regs[i]);
}
}
cache->dirty_mask = 0;
}
这个策略的好处很明显：
- 读操作零总线开销：算法读寄存器状态，直接从内存取，不阻塞。
- 写操作可批量：多个寄存器修改可以攒在一起，在音频帧间隙一次性同步。
- 调试友好：缓存里的值就是“预期值”，和硬件实际值对比就能发现异常。
注意：有些Codec的寄存器是“自清零”的（比如中断状态寄存器，读一次就自动清0）。这种寄存器不能缓存，必须直读硬件。我的做法是在缓存结构体里加一个volatile_mask，标记哪些地址不走缓存。
4.4 调试方法：从波形到日志，三板斧
控制接口出问题，现象往往是“Codec不工作”或“声音异常”。怎么定位？我一般按这个顺序来：
- 抓波形：示波器或逻辑分析仪看SCL/SDA（I2C）或SCLK/MOSI/MISO/CS（SPI）。确认时钟、数据、片选时序对不对。
- 读回验证：写一个已知值到寄存器，再读回来对比。如果读写不一致，八成是时序或模式问题。
- 加日志：在驱动里加调试打印，每次读写都输出地址、写入值、读回值。配合缓存，能快速发现“谁把寄存器改乱了”。
我曾经遇到一个经典案例：某款Codec在初始化后，音频输出一直有爆音。查了半天，发现是某个增益寄存器在算法运行时被意外写入了0xFF。加日志后发现，是另一个线程的定时器回调里误调了同一个I2C地址。最后给I2C总线加了互斥锁才解决。
4.5 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以把它当作控制接口移植的“检查清单”。
这张图从顶层的控制接口出发，分支出I2C速率适配和SPI模式选择两条主线，中间穿插寄存器缓存策略，底部收束到调试方法。你移植任何Codec时，都可以按这个框架来检查——哪块没做到位，问题就可能出在哪。
最后提醒一句：控制接口的移植，最忌讳“想当然”。别觉得I2C/SPI是标准协议就随便写。每个Codec的时序容限、片选要求、寄存器自清零行为都不一样。老老实实看手册，抓波形，做缓存，加日志——这三板斧能解决90%的问题。