打印

关于STM32 I2C的理解(欢迎讨论)

[复制链接]
39916|54
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
luckytoad|  楼主 | 2010-7-16 12:57 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
先感谢版主的热心,感谢网友对我问题的回答,我也奉献点我经验,对刚接触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有个民间的勘误表就好了,多少人会少走多少弯路啊。
沙发
香水城| | 2010-7-16 13:50 | 只看该作者
不管结论是否正确,但鼓励这种钻研的态度,加酷!

使用特权

评论回复
板凳
luckytoad|  楼主 | 2010-7-16 14:22 | 只看该作者
欢迎对我的结论提出异议,我负责解答。

使用特权

评论回复
地板
shizaigaole| | 2010-7-16 14:54 | 只看该作者
虽然费了几天周折。
400k速度,连续读写eeprom都没啥问题。

使用特权

评论回复
5
shizaigaole| | 2010-7-16 14:58 | 只看该作者
本帖最后由 shizaigaole 于 2010-7-16 15:02 编辑

唯一的一个问题是EV8-2中断的时候,
发送完stop需要等待EV8-2状态被改变,
即stop操作生效。

否则,第二次操作start,产生EV5中断以后就再也没有中断发生了。

使用特权

评论回复
6
shizaigaole| | 2010-7-16 15:01 | 只看该作者
但是如果把stop放在EV8事件的最后一个发送字节,
即DR寄存器空,移位寄存器非空的时候,
不需要等待stop操作也没有关系。

除了这一点意外,
其他的都很好。
没感觉到怎么难用

使用特权

评论回复
7
shizaigaole| | 2010-7-16 15:05 | 只看该作者
说实话,ST的产品参考手册做的很差。
但是相关应用文档和例子程序做的不错。

使用特权

评论回复
8
luckytoad|  楼主 | 2010-7-16 15:40 | 只看该作者
6# shizaigaole
程序简单,不会出错的,否则就不是STM的BUG,而是设计错误了。
我是做保护的,程序量很大,流程也比较复杂,所谓容易暴漏问题,建议你不做超时处理,异常中断打开,但不处理,如果允许2天没问题,那你就可以加上异常处理和超时处理,放心使用了。

使用特权

评论回复
9
luckytoad|  楼主 | 2010-7-16 15:42 | 只看该作者
另外就是你自己查标志,而不是查事件,出错的几率要小的多。因为有的事件是由多个标志组成的。但请标志严格按手册来。

使用特权

评论回复
10
luckytoad|  楼主 | 2010-7-16 15:46 | 只看该作者
我的模拟1M没出任何问题,试验和以下不延时都可以用的。延时值得是模拟时的DEALY,为了安全还是插入了5条语句。我的内部时钟是72M的。我在FM24c64 铁电以及SEEPROM 24C02上都模拟过,结果很放心

使用特权

评论回复
11
shizaigaole| | 2010-7-16 16:42 | 只看该作者
我来试试不做超时连续两天读EEPROM,看是否有问题。

“我是做保护的,程序量很大,流程也比较复杂,所谓容易暴漏问题”

不管怎样,还是要确定是STM32的问题,还是你自己的程序问题。

使用特权

评论回复
12
luckytoad|  楼主 | 2010-7-16 22:05 | 只看该作者
程序没问题的。也可说出现所谓的问题的时候,总线状态是没有异常的。
    但不管怎么说,如果I2C搞的这么费劲,出了这么多莫名问题,不管是不是st bug,和设计初衷是相悖的。
可以认为是个设计败笔。好像哪位老弟说的,当时ST的I2C设计师肯定喝多了,我到不这么认为。但水肯定是灌多了。

使用特权

评论回复
13
pigjiang| | 2010-7-17 10:26 | 只看该作者
说来惭愧,我没有楼主的钻研精神。
我一般是在例程上找一个IIC的库函数,然后根据芯片的数据手册,调整通讯速率和必要的延迟等待,直到稳定工作位置。

使用特权

评论回复
14
biao22ndg| | 2011-7-25 20:15 | 只看该作者
由于以前对IIC的使用都是基础的,突然接触如此多功能反而无法适应,最后模拟解决。

使用特权

评论回复
15
sunnyhey| | 2013-2-2 15:14 | 只看该作者
楼主最后是怎么实现的呢?可以发送我一份参考下吗?我的邮箱fly222yu@163.com,我的也是这样,发送完地址之后,等待EV5的时候,没有ACK信号,芯片自带的和模拟的都是这样,很是纠结啊。。。

使用特权

评论回复
16
shiyan1532| | 2013-2-2 16:40 | 只看该作者

使用特权

评论回复
17
拿起书本| | 2013-2-19 18:26 | 只看该作者
st和程序和例程做的确实很直观的,几乎都有注释的,不错,顶了

使用特权

评论回复
18
yangyuyaoems| | 2013-2-19 20:28 | 只看该作者
为什么我的IIC通信得到的结果全是0xFF呢?

使用特权

评论回复
19
dfsa| | 2013-2-20 09:26 | 只看该作者
鼓励钻研

使用特权

评论回复
20
xsgy123| | 2013-2-20 09:34 | 只看该作者
很有借鉴意义

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

0

主题

72

帖子

2

粉丝