1. I2S 协议基础：总线标准、数据格式与主从模式
各位好，我是老李。做音频驱动调试这么多年，我最大的体会是——I2S 协议是音频驱动的地基。WM8960 的延迟问题、时钟抖动、数据错位，十有八九都能追溯到 I2S 时序上。今天咱们就把这个地基打牢。
1.1 I2S 总线长什么样？
I2S（Inter-IC Sound）是飞利浦在 80 年代制定的数字音频总线标准。说白了，它就是让音频芯片之间能“说上话”的三根线：
- BCLK（位时钟）—— 每发一个 bit，BCLK 跳一次。采样率 × 位深 × 声道数，就是 BCLK 的频率。
- LRCK（帧时钟/左右声道时钟）—— 高电平左声道，低电平右声道，或者反过来。频率等于采样率。
- SD（串行数据）—— 数据就在这根线上串行传输。
嗯，这里要注意：有些芯片还会多一根 MCLK（主时钟），用来给内部锁相环提供参考。WM8960 就需要 MCLK，我踩过这个坑，后面会细说。
核心公式（记牢）：
BCLK = 采样率 × 位深 × 声道数
例如：44.1kHz × 16bit × 2ch = 1.4112 MHz
1.2 三种数据格式，你分得清吗？
I2S 协议本身定义了数据格式，但实际应用中还有左对齐和右对齐。我刚开始做驱动时，就因为这三种格式没搞对，音频出来全是噪声。你想想看，CPU 和 Codec 对数据的“对齐方式”理解不一致，能不出问题吗？
| 格式 | 数据与 LRCK 的关系 | MSB 位置 | 常见场景 |
|---|---|---|---|
| I2S 标准 | 数据在 LRCK 跳变后延迟 1 个 BCLK | 延迟 1 位后开始 | 飞利浦标准、大部分 Codec |
| 左对齐 | 数据与 LRCK 跳变同时开始 | 紧贴 LRCK 边沿 | 部分 DSP、老式 DAC |
| 右对齐 | 数据在 LRCK 周期末尾对齐 | LSB 对齐到 LRCK 边沿 | 日本厂商、部分消费电子 |
我个人习惯在调试时，先用逻辑分析仪抓 LRCK 和 SD 的波形，数一下数据从 LRCK 边沿到 MSB 的 BCLK 个数。数清楚了，格式就定了。
避坑指南： 我曾经在调试 WM8960 时，CPU 配成了 I2S 标准格式，但 WM8960 默认是左对齐。结果播放音乐全是“嘶嘶”声。后来花了半天才定位到是格式不匹配。所以，上电后第一件事：核对 CPU 和 Codec 的数据格式寄存器。
1.3 主从模式：谁说了算？
I2S 总线上，谁产生 BCLK 和 LRCK，谁就是主设备。另一个就是从设备。这个选择直接影响驱动配置。
- 主模式：自己产生时钟，从设备跟着你的节奏走。适合 CPU 做主导的场景。
- 从模式：接收外部时钟，CPU 被动接收数据。适合 Codec 做主设备，或者多个设备共用时钟。
WM8960 支持主从两种模式。我一般建议：让 CPU 做主设备，WM8960 做从设备。为什么？因为 Linux 的时钟管理在主模式下更可控，延迟抖动也小。
注意： 如果 WM8960 做主设备，CPU 做从设备，那么 CPU 必须能正确响应 WM8960 产生的 LRCK 中断。我曾经遇到过 WM8960 的 MCLK 频率不准，导致 LRCK 漂移，CPU 采到的数据错位。最后发现是 WM8960 的 PLL 配置有问题。
1.4 时序分析：波形里藏着真相
时序分析是调试的核心。我画了一张 I2S 标准格式的时序图，你一看就明白：
从图上你能看到：LRCK 跳变后，第一个 BCLK 周期数据线是空的，第二个 BCLK 才开始传 MSB。这就是 I2S 标准格式和左对齐格式最直观的区别。
1.5 调试时我必查的三个时序参数
在实际调试中，光看波形还不够。我总结了三个必须确认的参数：
- BCLK 频率是否准确？ 用示波器量一下，别信代码里配的值。我曾经遇到过 PLL 分频算错，BCLK 跑成了 1.8MHz，WM8960 直接不工作。
- LRCK 的占空比是否 50%？ 有些 SoC 的 I2S 控制器输出的 LRCK 占空比不是 50%，WM8960 可能识别不了。
- 数据建立时间和保持时间是否满足？ 特别是高速率（192kHz/24bit）下，BCLK 频率接近 12MHz，信号质量很容易劣化。
我的调试口诀：
一看格式对不对，二看时钟准不准，三看边沿有没有延迟。