不知不觉中已经有好几个月没有写点东西了，懒了就是懒了，说是忙着想把产品做得更好，都是借口，每天花一点时间来写点东西确实很不错，自己也坚持了很久很久，只不过今年以来，发现提高不是很大，能写的东西好少好少，以前专门研究一个方向，学习，完成工作，可以总结，而现在的事情，真的不好总结，额外的时间也没有完全用来学习，也没有追求更深入的掌握一些东西，一段时间测试，一段时间修bug，一段时间整理产品的细节，一段时间把握app的设计，总觉得没有非常好的把事情组织，做好。牢骚一大堆，还是进入正题吧。
上周的一个问题，又得重新看下i2c的一个问题，感觉玩了这么多的i2c设备，自认为应该没有啥问题的，同时挂了两个设备，一个是收音机模块，一个是eeprom，然后写了个小函数循环执行读写eeprom，大概20几次就出现了问题，不能继续读写eeprom了，示波器测试了下，发现i2c的sda被拉低了。然后把eeprom断电后，再上电，居然又可以用了。很奇怪的现象，总得解决吧。这个是用i2c控制器的时候遇到的问题。平时我都比较喜欢用linux自带的gpio模拟的i2c，那个超级好用，所有设备都没有出现过问题。
接着上网找了下原因，主要就如下吧，讲得比较详细，就贴一下了：
在正常情况下，I2C总线协议能够保证总线正常的读写操作。但是，当I2C主设备异常复位时(看门狗动作，板上电源异常导致复位芯片动作，手动按钮复位等等)有可能导致I2C总线死锁产生。下面详细说明一下总线死锁产生的原因。
在I2C主设备进行读写操作的过程中.主设备在开始信号后控制SCL产生8个时钟脉冲，然后拉低SCL信号为低电平，在这个时候，从设备输出应答信号，将SDA信号拉为低电平。如果这个时候主设备异常复位，SCL就会被释放为高电平。此时，如果从设备没有复位，就会继续I2C的应答，将SDA一直拉为低电平，直到SCL变为低电平，才会结束应答信号。而对于I2C主设备来说.复位后检测SCL和SDA信号，如果发现SDA信号为低电平，则会认为I2C总线被占用，会一直等待SCL和SDA信号变为高电平。这样，I2C主设备等待从设备释放SDA信号，而同时I2C从设备又在等待主设备将SCL信号拉低以释放应答信号，两者相互等待，I2C总线进人一种死锁状态。同样，当I2C进行读操作，I2C从设备应答后输出数据，如果在这个时刻I2C主设备异常复位而此时I2C从设备输出的数据位正好为0，也会导致I2C总线进入死锁状态。
方法
(1)尽量选用带复位输人的I2C从器件。
(2)将所有的从I2C设备的电源连接在一起，通过MOS管连接到主电源，而MOS管的导通关断由I2C主设备来实现。
(3)在I2C从设备设计看门狗的功能。
(4)在I2C主设备中增加I2C总线恢复程序。每次I2C主设备复位后，如果检测到SDA数据线被拉低，则控制I2C中的SCL时钟线产生9个时钟脉冲(针对8位数据的情况)，这样I2C从设备就可以完成被挂起的读操作，从死锁状态中恢复过来。这种方法有很大的局限性，因为大部分主设备的I2C模块由内置的硬件电路来实现，软件并不能够直接控制SCL信号模拟产生需要时钟脉冲
(5)在I2C总线上增加一个额外的总线恢复设备。这个设备监视I2C总线。当设备检测到SDA信号被拉低超过指定时间时，就在SCL总线上产生9个时钟脉冲，使I2C从设备完成读操作，从死锁状态上恢复出来。总线恢复设备需要有具有编程功能，一般可以用单片机或CPLD实现这一功能。
(6)在I2C上串人一个具有死锁恢复的I2C缓冲器，如Linear公司的LTC4307o如图2所示TC4307是一个双向的I2C
总线缓冲器，并且具有I2C总线死锁恢复的功能。LTC4307总线输人侧连接主设备，总线输出侧连接所有从设备。当LTC4307检测到输出侧SDA或SCL信号被拉低30ms时，就自动断开I2C总线输人侧与输出侧的连接.并且在输出侧SCL信号上产生16个时钟脉冲来释放总线。当总线成功恢复后，LTC4307会再次连接输人输出侧，使总线能够正常工作。
由于平台本身gpio口就很有限，所以控制eeprom的话，可能性不大，于是就大概给了9个clk，然后控制器也复位下，就解决了这个问题。