先感谢版主的热心,感谢网友对我问题的回答,我也奉献点我经验,对刚接触ST32的同仁提供点看法。
查了查论坛,发现I2C是最火的(),我也凑个热闹。
先简单介绍一下,我在I2C上花的时间最多,近10天,占了整个开发时间的近1/3,也很是搓火。
我用的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的。
6、I2C的协议和时序非常简单,因为是同步的,作为主设备的时候很容易实现模拟,不怕中断打断,不怕时钟节拍不固定,只要时序对就可以,这也是为啥SEEPROM采样I2C的原因,这种慢设,很容易在主程序中模拟。
7、关于EEPROM应该是最没有争议的地方了,用了10几年,没发现过任何问题,即使有所谓的从设备拉低死锁总线的问题,(也是唯一听说过的问题),但我从来没测出过。处理方式呢,无非是复位从设备,或者检测到总线一直为低的时候,发送9个时钟节拍,就能解决。但这种问题用硬件I2C是不能解决的。
8、一般的ram设计芯片或多或少都会有BUG,很正常,因为arm是搭积木出来的,而且面向对象太广(万金油),设计比较繁琐。稳定要n年,知道bug先绕过就行了。
9、补充一句,出现问题,不是在I2c总线时序上,主要是标志位上,也就是说ST自己给自己找麻烦了,如果你不查标志,算好时间,也没问题。或者说标志出问题了,也能正常读写的。不信你试试。
10、建议在批量工业产品慎用STM内部I2C。无论从代码开销上,还是执行效率,无论是花费的时间、精力,还是实际的运行效果,我看不出使用硬件I2C的任何好处(用STM32芯片)。
仅供参考。
讨论仅限于对I2C的认知,不回答程序bug之类问题,不管你用什么方式,还不能正常读写,只能说明你软件有问题,和ST没关系的,好好看I2C时序,好好看例程。
欢迎对我10条建议拍砖。
要是ST有个民间的勘误表就好了,多少人会少走多少弯路啊。 |