📚 课程目录第1章 SDIO协议基础与吞吐量关系

SDIO 协议基础与吞吐量关系

面试的时候，很多候选人跟我讲他做过 SDIO 驱动。我一问，你知道 SDIO 协议里哪个字段限死了吞吐量吗？不少人就卡住了。说实话，SDIO 吞吐优化这件事，根子上的限制都在协议里。你写再多优化代码，如果协议层面没吃透，最后性能墙还是撞得头破血流。

我个人习惯把 SDIO 协议和吞吐量的关系拆成三块来理解：物理层能跑多快、数据层怎么组织、最大传输单元在哪里。今天我们就把这讲透。

SDIO 是 SD 卡协议的扩展，所以它的电气规格跟 SD 卡基本一致。目前主流设备支持的是 UHS-I 和 DDR50 模式。我列个表给你看。

传输模式	时钟频率 (MHz)	数据线宽 (bit)	理论最大速率 (MB/s)
Default Speed	0 - 25	1 / 4	12.5 (4-bit)
High Speed	0 - 50	4	25
SDR50	0 - 100	4	50
SDR104	0 - 208	4	104
DDR50	0 - 50	4 (双沿采样)	50

嗯，这里要注意一点。SDR104 虽然标着 208MHz，但很多 SoC 的 SDIO 控制器跑不到这个频率。我做过一个 Wi-Fi 模组的项目，主控号称支持 SDR104，实际经过 PCB 走线损耗后，跑到 150MHz 就开始出 CRC 错误了。所以你看规格书的时候，一定要留余量。

核心结论：协议本身给了你上限，但物理层能不能达到是两码事。面试官问这个，是想看你知不知道实际落地和理论值的差距。

SDIO 默认支持 1-bit 和 4-bit 两种总线宽度。说白了，1-bit 就是一根数据线来回跑，4-bit 就是四根一起跑。吞吐量直接差 4 倍。所以我在项目里第一件事就是确认初始化时有没有成功切到 4-bit 模式。

另一个坑是 块大小对齐。SDIO 传输以块为单位。如果每块是 512 字节，你发一个 513 字节的包，协议会自动拆成两块，第二块只装 1 个有效字节。浪费不？非常浪费。

我列一下常见的块大小和有效传输率对比：

我在项目里遇到过这种情况：产品经理说我们的理论带宽是 50MB/s，怎么实际才 30MB/s？后来一查，驱动里每次只读 32 字节，块大小设成 32 字节。把块大小改成 512 字节后，吞吐直接翻倍。这就是协议层面的优化红利。

SDIO 不是只传数据的。每笔传输前都得发命令、等响应。协议里把这些叫 CMD + Response 开销。我画一张图帮你理解这笔账。

你想想看，假设每笔数据传输前都要花 10 微秒发命令等响应。你传 4KB 数据只要 40 微秒，结果命令开销就占了 20%。这就是为什么小包场景下 SDIO 吞吐特别难看。

我个人习惯在分析性能瓶颈时，先算一下 命令占比。如果占比超过 10%，我就会考虑做批量传输或者合并命令。SDIO 协议支持 CMD53 做块传输，这个可以一次命令传多块，能省掉中间的命令开销。

SDIO 对单次传输的最大字节数有限制。不同的控制器实现不一样，但协议层面建议不超过 512 字节 或者 1024 字节。超过这个数，协议就得分片。

分片意味着什么？意味着更长的总线占用、更多的 CRC 检查、更多的命令交互。我在一个蓝牙模组项目里测过，单次传 2KB 和拆成 4 次 512 字节传，后者吞吐下降约 18%。

面试小技巧： 当面试官问「你怎么优化 SDIO 吞吐？」你可以先答协议层面的三个方向：切换到 4-bit + 高时钟模式、增大块大小到 512 字节以上、使用 CMD53 批量传输减少命令开销。这能体现你对底层的理解。

说实话，面试问 SDIO 协议吞吐，并不是要你背规格书。他更想听你讲：

我曾经帮一个团队救一个 SDIO 网卡项目。他们折腾了两个月，吞吐死活上不去。我一上逻辑分析仪，发现每次 DMA 传输之间插了一个 1 毫秒的轮询命令。去掉那个轮询之后，吞吐直接从 12MB/s 跳到 35MB/s。这种坑，不深入了解协议开销是发现不了的。

警告： 不要轻易把总线时钟调到超过规格书标称值。我在一个项目里试过超频 20%，刚开始稳定，但温度一上去就开始丢帧、CRC 错误。SDIO 的电气特性对信号完整性很敏感，过冲和振铃都会导致重传，而重传对吞吐的打击比降频还要大。

好了，我跟你把这协议基础和吞吐的关系理清了。物理层给你上限，数据层决定效率，命令层吃掉你一部分带宽。这三层理清楚，再去调驱动、改 DMA、优化中断，才有方向。不然就是瞎调。