如果你选择了STM32, 说明了你的项目的需求是比较复杂的,使用EMBEDDED OS 和大量地运用中断+DMA的编程模型是必然的选择, 如果你的项目中用STM32,而你用模拟的I2C的话, 说明了两点: 一是浪费了STM32; 二, 如果你的项目很复杂的话,你会发现在项目的开发后期,好象STM32也比8位机快不了多少, WHY!! ,但这不是STM32的问题,而是你没有最有效地利用上STM32.


 很多朋友在搞STM32的I2C接口编程时总是时不时“当在某处”(GOOGLE时你会发现这个问题很普遍), 一些朋友这时就会用软件来模拟I2C，然后,很快发现和I2C设备能很好地通信了(但当机还是可能随机出现), 这些朋友于是大骂STM32的I2C硬件接口是个”杯具”(呵呵,我有时也会突然想骂骂,但我知道,99.999%的原因还是自已对于STM32硬件接口的熟悉程度不够，或者说，是我没有扬STM32 I2C的长，而总是捉住他的短不发。）。     固然，STM32 I2C硬件接口有设计不完善的地方，例如下面就是我从STM32最新的Errata sheet中总结出的，关于STM32 I2C接口设计上的一些缺陷和如何避开这些缺陷的推荐程序模型： （1）把I2C的中断优先级提升到最高 （2）把发送多于2个字节的发送与接收封装成利用DMA收发的函数，而把对某I2C设备接收和发送一个字节的函数单独封装为一个POLLING （轮询）函数。 （3）在寻址某一I2C DEVICE时要先CHECK I2C BUS 是否BUSY，如果忙，则等待指定时间，如果还是忙就说明I2C BUS 挂了（原因99.9%是由于我们的I2C通信时序并不十分尊守I2C规约，或者我们所封装的I2C通信模块没有加上防守代码（出错恢复代码）），这时要调用一个专门的用于通知 I2C BUS上的所有device，让他们结束当前内部的工作，重新准备好（下雨了，收衣服啦）。如下面的我的I2C模块的FUN 切片：