I2C调试经验总结

I2C真是个又简单又复杂的玩意儿，两根线实现半双工通信确实是一个很巧妙的设计，但是由于线路简单，就导致了通信过程的复杂，而通信过程的复杂又导致通信异常时问题难以排查。今天不讲I2C总线，也不讲具体的代码，来说说I2C通信遇到问题以后的排查思路。
首先是知识预备，至少得对I2C总线协议有一定的了解，尤其是它的电气特性方面，得真正的了解开漏对于I2C总线的意义，一个句简简单单的线与可说不清楚。开漏让是I2C一根数据线实现半双工的基础，毕竟如果是推挽输出，当主从机发生冲突时，假如主机发生高电平，从机发送低电平，不就短路了吗。而开漏的时候，两边就只能发送低电平，因为它的高电平由上拉电阻提供，两遍没有高低电平的矛盾就不会造成短路，它们的矛盾在于什么呢？如果总线物理连接是正常的情况下，那么主从机之间只存在低电平的矛盾，分析问题的时候着重关注哪里的低电平出了问题。
遇到I2C通信异常问题，先看最基础的部分，主从机物理连接是否有问题（可以拿万用表怼一怼），再看上拉电阻接没接，在确认物理连接及电路部分没问题再去找问题，别看这个很基础，但是确实很重要，有时候接线松松垮垮的，导致调试时过时不过，找了半天的问题，回头换根线或者换块板子就好了就有点尴尬。
在确认物理连接没问题后，再来开始正式找问题，先得对自己的I2C代码通信流程有一定的了解，然后用逻辑分析仪把I2C的波形抓出来。如果对通信流程有一定的了解，再去分析波形，就容易从波形上看出来到底是哪里的问题了。
I2C通信无非就是主/从发送、接收、应答、起始、停止有问题，波形上看是一目了然的。
总结一下我对I2C问题的分类：
1.I2C芯片问题，此类问题只有找芯片原厂分析，就比如STM32F103的I2C bug，有兴趣的可以往前翻翻，我写过一篇讲STM32F103 I2C问题的文章。
2.硬件连接问题，这类基础问题往往花费我们大量时间，检查工作做在事前非常重要。
3.软件问题，这类问题就多了，比如I2C引脚的配置正不正确，整个软件通信流程是否有问题，以及一些地方是否加了延时（有的从机时钟速度慢，主机结束通信后的下次通信需要等待响应）
最主要的还是对I2C协议的掌握，熟悉协议的话，只要不是硬件bug，大部分的问题都是了然于胸的。