转载：

% o. D$ [* n  \7 j/ [- h4 l/ D我用的I2C，库函数是3.0（今年4月的），例程参考了无数，手册也仔细研究了，包括勘误表，还仔细研究了一下所谓的4.0的例程（STM32F10x_AN2824_FW_V4.0.0），I2C的例程，不是SEE。但库函数和3.0的一样的，例程主要是增加了异常处理，增加了polling方式下某些关键地方关中断，而且要求I2c中断是最高优先级的，还是不稳定（不是不能用）。另外说一句，死等是调试下最好的方法，你应该感谢例程中的死等，否则好多问题一般人发现不了，一般测试都要死等（标志），没任何问题了，发布前加上超时判断，超时判断只是容错的处理方法而已。
    最后绕了一大圈，还是回到模拟了（半天搞定。），唯一的收获就是对I2C的细节和STM32又有了深刻的理解。
   所谓我认为stm32 i2c之所以受到这么多的关注，
1、是因为设计过于繁琐，对硬件不是很清楚的话很容易犯晕。
2、标志位设计有缺陷，这就说所谓的BUG，造成死循环或等待超时，参看勘误表。
3、读最后一个字节的时候尤其容易出现问题。
4、关于说不能用的有点绝对，那是你软件编程有问题，但问题还是比较大的，让你心里没底。
5、如果靠纠错或为了满足I2C模块正常工作，要做额外大量的工作，就得不偿失了，因为一般I2C很多时候是用来读EEPROM的。
# w. Z/ ]9 y# U# G6、I2C的协议和时序非常简单，因为是同步的，作为主设备的时候很容易实现模拟，不怕中断打断，不怕时钟节拍不固定，只要时序对就可以，这也是为啥SEEPROM采样I2C的原因，这种慢设，很容易在主程序中模拟。
" m* ]8 _: C; y- y- f4 r7、关于EEPROM应该是最没有争议的地方了，用了10几年，没发现过任何问题，即使有所谓的从设备拉低死锁总线的问题，（也是唯一听说过的问题），但我从来没测出过。处理方式呢，无非是复位从设备，或者检测到总线一直为低的时候，发送9个时钟节拍，就能解决。但这种问题用硬件I2C是不能解决的。
8、一般的ram设计芯片或多或少都会有BUG，很正常，因为arm是搭积木出来的，而且面向对象太广（万金油），设计比较繁琐。稳定要n年，知道bug先绕过就行了。
/ O+ {" D5 w6 B* b3 j5 Q9、补充一句，出现问题，不是在I2c总线时序上，主要是标志位上，也就是说ST自己给自己找麻烦了，如果你不查标志，算好时间，也没问题。或者说标志出问题了，也能正常读写的。不信你试试。
10、建议在批量工业产品慎用STM内部I2C。无论从代码开销上，还是执行效率，无论是花费的时间、精力，还是实际的运行效果，我看不出使用硬件I2C的任何好处（用STM32芯片）。
2 D9 o4 j7 ]9 f" V/ l4 x. c   仅供参考。
% [, F6 i" a" v+ H    讨论仅限于对I2C的认知，不回答程序bug之类问题，不管你用什么方式，还不能正常读写，只能说明你软件有问题，和ST没关系的，好好看I2C时序，好好看例程。
: Q6 {6 \5 C4 O- N5 Q1 \0 N. @. K    欢迎对我10条建议拍砖。
    要是ST有个民间的勘误表就好了，多少人会少走多少弯路啊。
4 U9 P5 m3 @/ |, L" y
& o* O! r8 _4 k

STM32L476   用HAL库  硬件I2C读6轴传感器表示没毛病。