STM32的硬件I2C难弄的原因是通信不可控

bj2008wyou · 发表于 2015-12-28 22:23:32

本帖最后由 bj2008wyou 于 2015-12-29 00:57 编辑

虽然没弄过STM32的硬件I2C，但有弄过STM8S的主从I2C通信，二者在I2C上基本一样的。
STM8S的主从I2C通信很难调试，无法硬件仿真调试的，因为硬件仿真查看状态标志时实际上是在读取状态标志了，因此会出现一些状态标志清除问题导致I2C通信失败，具体表现为主机一直为busy，需要断电重来。即使不使用硬件仿真调试而看似调通了，实际上双机运行时还总是出现各种通信失败的问题，最后实在受不了了，主机用软件模拟I2C。

自从使用过瑞萨的RL78G13的硬件I2C后，二者对比发现STM32硬件I2C的败笔在通信的不可控性上，具体表现为：

（1）RL78的硬件I2C通信采用中断方式（查询方式还没试过），可选择在发送8个或9个（一般write选择9个，read选择8个）时钟后产生中断，伴随着主动拉低SCL，即使是此时正好有其它更高等级的中断在执行或是不允许嵌套中断且正有其他中断在执行，也依然主动拉低SCL。程序进入中断后先判断应答状态或先发送应答信号，有应答或发送应答后再人为地控制释放SCL继续通信，也就是说这个通信过程是可控的，因此中断等级可以是最低等级。

（2）STM32的硬件I2C是不可控的。作为主机时每发送一个字节后都是全发完9个时钟然后立马就释放总线，这意味着在读取时候如果I2C使用中断方式就必须使用最高等级，否则如果在第9个时钟时刻正好有更高等级的中断在执行，这个应答信号就被从机忽略了，因为第9个时钟已经发送但应答没来得及发送，然后就导致从机不发送数据而使主机（原话：“主机等一待直应答信号而”为错误的）一直为busy状态，I2C通信就挂了。但是对很多系统来说，设置I2C中断为最高等级是不合理的。如果是使用查询方式，读取期间第9个时钟期间也不能被打断，否则I2C通信同样挂。

这里我不是推崇日本的片子（公司使用瑞萨片子我才有机会接触的），只是做个比较为什么STM32的硬件I2C这么失败，遭受的吐槽最多的原因。
红色字体是后来添加的，蓝色字体是错误的，哎，第一次发不是求助帖都出问题，误导他人了。

不过这是我个人的观点，可能有错，有问题请指出，如果真有问题，请原子老师删除掉帖子吧