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

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