求助，改善i2c波形

mengqian · 发表于 2009-4-29 12:03:37

用的是mega16的板子，自己焊的核心板，两个板子通过i2c进行主从通信，单纯用avr的上拉，i2c的SCL信号变化比较缓慢，在每次start与stop之间会有一次毛刺，改用外部上拉，阻值为5K，SCL的信号有了明显改善，但是毛刺也明显增多，几乎每次发送数据都有，这两种情况下测的i2c的通信都不够稳定，怀疑是波形不够规整，尝试改变上拉电阻的阻值，在总线中串小电阻，都没有什么改善 PS：i2c用的普通导线外接，长度大概10cm,附上波形如下

加接外部上拉电阻的波形，有明显毛刺1 (原文件名:SCRN0194.JPG)

单纯使用avr内部上拉的波形，有明显毛刺 (原文件名:SCRN0195.JPG)

加接外部上拉电阻的波形，有明显毛刺2 (原文件名:SCRN0219.JPG)

加接外部上拉电阻的波形，有明显毛刺3 (原文件名:SCRN0224.JPG)

加接外部上拉电阻的波形，有明显毛刺（局部放大） (原文件名:SCRN0225.JPG)

mengqian · 发表于 2009-4-29 12:27:07

还需要说明的是用的avr的twi模块，而非i2c

holycat · 发表于 2009-4-29 15:33:00

浅见：
1、前几张图看不出有明显的毛刺。
2、只用内置上拉信号时虽上升的时间较缓，但能升到顶，看不出存在会造成出错波形。
3、问题是最后一张图里的毛刺（SCL?），会不会是软件bug？比如存在重新设置端口的语句。（即使没动该位，但若同一端口的其他位设置时，不小心也操作了该位，等等……）

mengqian · 发表于 2009-4-29 19:16:02

先谢谢仙猫，不过还是有很多地方需要说明一下：

1、前几张图看不出有明显的毛刺。

   前几张的毛刺放大图都和最后一张差不多，很多毛刺的峰值都已经达到了i2c通信的高电平值了，毛刺我在图上标注了下，又传了上来。

2、只用内置上拉信号时虽上升的时间较缓，但能升到顶，看不出存在会造成出错波形。

   上边的图中都有时间信息，大概估算了一下，这种情况下SDA 和SCL 信号的上升时间需要3us,即3000ns,已经远远超出了i2c总线规定的1000ns（这是标准模式下的最大值，快速模式下是300ns）。
   需要说明的是这种通信是能够持续一段时间的，多则一两个小时，少则几分钟，很随机。不明所以。

3、问题是最后一张图里的毛刺（SCL?），会不会是软件bug？比如存在重新设置端口的语句。（即使没动该位，但若同一端口的其他位设置时，不小心也操作了该位，等等……）

软件编写是按avr数据手册来的，几乎都是按照手册上的实例代码写的，并且仅仅是对i2c的测试，并没有调用其它功能模块，还有一点需要说明的是当我接了外接上拉电阻之后，毛刺明显增多，代码并没有改变，应该不是软件的问题吧。

放大了会很明显 (原文件名:SCRN0194-1.JPG)

使用内部上拉的毛刺标注 (原文件名:SCRN0195-1.JPG)

mengqian · 发表于 2009-4-29 19:59:25

PS: 3、问题是最后一张图里的毛刺（SCL?)
毛刺是SDA，调试中，毛刺都出现在SDA的波形中

dr2001 · 发表于 2009-4-29 20:30:00

根据IIC协议，SCL=0的时候，SDA是不管的，是否会发生跳变没限制。
协议只要求SCL=1的时候，SDA稳定。以及Start/Stop信号。

holycat · 发表于 2009-4-30 02:12:13

5楼说得对，SCL=0时的SDA怎么变都是无所谓的，关键是扩大图里的SCL毛刺怎么解释。
从未读AVR实例的具体代码，但为彻底排除软件问题的可能，建议暂时删掉除SCL、SDA以外的所有对PC口的操作试试。

holycat · 发表于 2009-4-30 02:17:07

【4楼】 mengqian：“毛刺是SDA，调试中，毛刺都出现在SDA的波形中”
——从前几张图看红线应为SCL，莫非最后一张图的测试笔掉换过了？假如红线是SDA就没问题，因为毛刺出现在SCL=0的区间。

mengqian · 发表于 2009-4-30 09:39:38

看了几位的回复很有启发，我实际测试了一下，目前最长的通信（单纯i2c主从通信）时间能够达到8个小时（因为要用JTAG，停止了测试，实际通信时间应该要比这个长），看来在SCL=0时SDA的毛刺是不会影响通信的。

仙猫：从未读AVR实例的具体代码，但为彻底排除软件问题的可能，建议暂时删掉除SCL、SDA以外的所有对PC口的操作试试。
大概看了下代码，没有对SCL、SDA以外的其它PC口的操作，不过也不能排除，我再去改改测测。

仙猫: ——从前几张图看红线应为SCL，莫非最后一张图的测试笔掉换过了？
我比较粗心，每次测没照顾颜色的一致性，存了好多图片就把差不多的给发上来了，造成了误导，失误失误O(∩_∩)O

155107149 · 发表于 2009-4-30 09:43:00

mark,对楼主的数字示波器流口水中。。。

mengqian · 发表于 2009-4-30 11:34:10

mark,对楼主的数字示波器流口水中。。。

呵呵，这可不是我的，是公司的，据说花了好几万呢，帮了不少忙啊，俺从软件向硬件的学习就指着它了O(∩_∩)O哈哈~

mengqian · 发表于 2009-4-30 12:42:56

其实调i2c主要是为了驱动液晶，液晶驱动是早就写好了的，只是驱动一段时间后会出现“死机”现象，就是液晶突然卡住不动了，（程序是让它一直不停黑白刷屏的）。用JTAG调试了一下发现此时i2c已经退出了总线，数据虽然写入了TWDR，同时也写TWCR让数据发送出去，可是TWCR的TWINT却始终无法置位，即数据一直无法发送出去。

需要说明的是程序是可以正常运行一段时间的，长则两三个小时，短则几分钟，曾经考虑是液晶DDRAM刷屏处理不过来，不过对着数据手册研究了半个多月也没有弄出个所以然来，自然开始怀疑硬件问题了。

驱动液晶同样采用的外接导线，长度大约10cm ，波形如下，这时i2c接的外部上拉电阻为5K，3.3V供电，3.3V上拉

(原文件名:SCRN0245-1.JPG)

局部放大图1 (原文件名:SCRN0242-1.JPG)

局部放大图2 (原文件名:SCRN0243-1.JPG)

需要说明的是SDA线的低电平无法拉低，大约在0.5V左右，倒也没有高于i2c规定的0.3VDD，然后是SDA SCL的上升时间，差不多1000ns（i2c标准模式下允许的最大时间1000ns），还有就是毛刺了（估计不会对通信造成影响），目前能够想到的导致i2c退出总线的就这两个因素了。

尝试改小上拉电阻，发现SDA SCL的上升时间有了明显的改小,可是SDA的低电平也有了明显的抬高，见下图

1K上拉电阻，5V上拉电压，此时加3.3V上拉电压i2c通信很快出错，故采用5V (原文件名:1K上拉电阻5V上拉电压.JPG)

250欧上拉电阻，3.3V上拉电压 (原文件名:250欧上拉电阻3.3V上拉电压.JPG)

250欧对应放大图，能够明显看出SDA的上升时间减小，SDA的低电平抬高 (原文件名:250欧电阻对应放大图1.JPG)

250欧放大图 (原文件名:250欧电阻对应放大图2.JPG)

个人得出规律，外部上拉电阻越大，SDA的低电平越低，相应SDA的上升时间也越长，硬件知识实在有限，想请教、下各位大侠，有没有什么方法对i2c进行滤波，在保证SDA的上升时间足够短的情况下尽量拉低SDA的低电平。

目前的主要问题是驱动液晶不稳定，不知道各位大侠们还有什么看法，谢谢指教

mengqian · 发表于 2009-4-30 19:04:37

自己顶(*^__^*)

holycat · 发表于 2009-4-30 20:12:53

不要随便加滤波，把bug掩盖起来是很危险的，宜先弄清原因再说。
情况看似存在冲突，能否把通信双方接口部分的电路贴出来看看？

mengqian · 发表于 2009-4-30 20:45:57

-----看到的晚了点，现在拿不到相机了，只能等放假回来了，谢谢仙猫，一有相机我就贴出来O(∩_∩)O~

mengqian · 发表于 2009-5-5 12:24:35

这是刚照的液晶硬件连接图，考虑到液晶是可以正常运行一段时间的，会不会是连线太简陋在通信的过程中产生了干扰呢，感应电容什么的，需要说明的是一般情况下，液晶刷屏频率越高，液晶“死机”越快，波形是上面发的，咨询了液晶的设计人员，说低电平拉不低是不会影响通信稳定性的

整体效果图 (原文件名:整体效果图.JPG)

硬件连接图 (原文件名:液晶硬件连接图.JPG)

局部放大图1 (原文件名:局部放大图2.JPG)

局部放大图2 (原文件名:局部放大图1.JPG)

液晶引脚连线 (原文件名:液晶引脚连线.JPG)

引脚连线放大图 (原文件名:引脚连线放大图.JPG)

mengqian · 发表于 2009-5-6 09:06:39

昨天用的I/O口模拟的，液晶一直没出现死机的情况，看来是i2c传输出问题了，可是avr的twi性能应该可以啊，要不就是电路对twi的影响了

mengqian · 发表于 2009-5-6 10:03:04

用I/O口模拟刚开始也出现过低电平拉不低的现象，找了下原因，发现模拟应答时将SDA对应的I/O口由输出设置为输入，这段是为了检测是否有应答而设置的，驱动液晶倒也用不到从机的应答（不考虑出错处理的情况下），将这段去了低电平拉不低的情况就消失了。

不知道twi拉不低是不是类似的原因，继续调试，不过用模拟的方式会出现负电平，不知道原因，猜想可能跟avr的硬件特性有关吧，哪位大侠了解，给详细说明下O(∩_∩)O~

IO模拟i2c (原文件名:IO模拟i2c.JPG)

IO模拟i2c放大图 (原文件名:IO模拟i2c放大图.JPG)

mengqian · 发表于 2009-5-8 17:00:40

又改用中断的方式通信，还是老问题，开始能正常通信，一段时间之后就死了，TWSR的状态要么是0x78,要么是0x00,单独主从通信也是会出现这种问题

seawind319 · 发表于 2009-5-8 17:22:46

MARK

steven · 发表于 2009-5-8 17:48:47

MARK TOO...

mengqian · 发表于 2009-5-19 11:58:36

做其它模块的时候因为电源不稳出了很多问题，开始怀疑TWI的供电，换了稳压模块，TWI通信依旧不稳定

holycat · 发表于 2009-5-19 12:25:12

贴了n多都是实物照片，咋就没有电路图呢？有具体电路图才好分析嘛。

mengqian · 发表于 2009-5-21 10:22:37

电路图来啦

mengqian · 发表于 2009-5-21 10:28:10

C1为1.0uF,尝试过0.1和0.01uF的，对波形、通信都没有改善 (原文件名:液晶连线图.JPG)

holycat · 发表于 2009-5-21 11:09:51

不要漫无目的地乱加电阻电容，这样很容易掩盖BUG。其实现在的问题所在似乎是比较明显的，即那个不高不低的半拉子电平肯定是哪儿出了毛病。
从那个异常电平出现的频度看，很像是1字节传送之后的'ACK'。
'ACK'本该是被发出确认的一方拉低的，而现在这个低电平似乎很弱，上拉电阻竟然也能轻易改变它的电平，从现象看很像是两个通信装置之间没有共地，有没这个可能呢？

mengqian · 发表于 2009-5-22 10:10:20

谢谢仙猫，我想根据你说的那个不高不低的半拉子电平肯定是哪儿出了毛病
再补充一些：

   1.低电平拉不低这个问题我专门问了这块液晶控制器的设计者，他说出现低电平拉不低的现象是有的，但是不影响通信的稳定性。
   2.改用IO模拟TWI也会出现低电平拉不低的现象，实测通信一直都很稳定。
   3.两个AVR 的TWI主从通信，（还是驱动液晶的那套代码）是不会出现低电平拉不低的现象的，可见低电平拉不低应该不是软件BUG,更多原因在液晶。

根据以上几点考虑，上拉电阻的配置会对通信低电平的电压值产生较大影响，但不是影响通信稳定的主要因素。之所以会出现液晶“死机”现象，我觉得主要在TWI上，毕竟模拟的一直没出过问题。到底是什么影响了TWI的稳定性，就不清楚了。

holycat · 发表于 2009-5-22 11:08:25

回【27楼】 mengqian 孟谦
-------------------------
既然能联系到液晶板的设计者，看来问题就好办了。你让他把接口电路亮出来，自己也可解决。

1、“他说出现低电平拉不低的现象是有的，但是不影响通信的稳定性。” ——恕俺直言，这不是技术者该说的话。电路正常工作的保障来自技术硬指标，不是设计者可以自己说了算的。常用逻辑电路中对低电平要求最高的是TTL，要求低电平＜0.8V，如果仅区区上拉2.5mA（图中可见用1k上拉时电平在5V的一半左右）输出已不能确保低电平，那种电路凭什么说算合格的？！（按严格的I2C规矩，拉3mA时不能高于0.4V。）

2、当然，实际器件的性能肯定要强过手册的保证值一些，因此实测时看到的bug会少些，但有限次的实测通过并无法排除问题存在的可能性，换个环境没准就完蛋了。

3、至此俺搅得，通信死机的原因明显在液晶模块——假如没猜错的话，由于主机收不到丛鸡的ACK，在那里死等着。不过从另一角度看，主机软件不该没有超时判断/重传功能。加上这个功能，即使出错“死了”的话，也还有自动复活的机会。

mengqian · 发表于 2009-5-22 13:31:31

回【28楼】 holycat 仙猫

你让他把接口电路亮出来上边发的图就是设计者给的接口电路，只是改成了AVR平台，将原来的5V改成了3.3V

1.我考虑液晶电路性能指标是否合格是有待商榷的，但是如果合理设置上拉电阻的阻值的话，TTL低电平虽然会拉不到0，但是绝对不会超过0.4V的规定值的，换种说法，液晶设计的可能不够稳定，但是我们外围硬件可以进行补救。

2.实测的硬件和软件环境（TWI驱动除外）和用TWI时是一样的：硬件连接没有改变，液晶上层驱动没有改变。
虽然次数有限，但是能够确保任何一次测试都没有“死机”，而用TWI则任何一次都必“死机”，一定程度上能够说明TWI有问题。

3.AVR的TWI设计的是一旦数据发送出去了，即使没有收到从机的应答，TWCR的TWINT位也会置位，现在的情况是数据写入TWDR后，写“发送命令”（TWCR = (1<<TWINT)|(1<<TWEN); ），TWINT位却始终无法置位，此时的TWSR的状态为0xf8或0x00,为不参与总线状态，而非无应答状态。这在正常的TWI通信中是不应该发生的一种状态。尝试发现错误后重新发送，但是此时数据已经发送不出去了。

holycat · 发表于 2009-5-22 13:57:27

上面的电路只是接口连接图，没有电路。奇怪的是他究竟用了什么器件，因为一般连最小的OC/OD门拉几十mA是不成问题的。

俺没实际玩过TWI，不清楚其中的细节，当然Atmel也缺可能有考虑不周的地方。但有一点是肯定的，即手册给出的动作都必须以满足其要求的电气指标为前提。现在既然逻辑电平都没能保证，就无法进一步说这个TWI控制器是好是坏了。

holycat · 发表于 2009-5-22 14:05:56

另外，当碰上TWI数据发不出去时，不知能否用重新初始化该口（或STOP一下再START）的办法激活它？

mengqian · 发表于 2009-5-22 16:51:54

回【30楼】 holycat 仙猫
不好意思，具体接口连接图和电路的区别不太清楚，不过实际是按这个连的，上拉是加到了AVR的引出脚上了。
刚接触AVR没多久，AVR的TWI性能不敢妄加评论，不过单纯使用AVR的内部上拉的话，SDA数据线的上升时间很长，已经超过了I2C的电气规定值了。见下图

两个AVR的TWI主从通信，使用内部上拉电阻 (原文件名:SCRN0165.JPG)

回【31楼】 holycat 仙猫
STOP一下再START这个是尝试过的，但是这个时候START就通不过了，AVR的START也是需要TWINT置位的，这个时候同样的TWINT无法置位。重新初始化的好像没有试过，不过感觉真要到这一步，倒宁可选择IO模拟了。中断发送的方式也试过了，也是同样的结果。

Joezhu · 发表于 2009-5-22 17:49:25

这个可能和硬件TWI模块有关。这个TWI比标准I2C的功能多一些，如多主机。有可能是在SCL低的时候做一些检测，这样即符合I2C的标准，又增加了功能。

mengqian · 发表于 2009-5-26 13:05:17

回【33楼】 Joezhu
增加功能应该不会影响稳定性啊，时间测试时我就挂了一块液晶，就算检测应该也不会检测到冲突或错误吧（液晶只收不发）。

capron · 发表于 2009-5-26 14:08:29

IIC速率是多少？如果高速通讯，建议外部上位1K电阻值。否则上升沿变圆。
有毛刺没关系，只要在协议的规定范围之外的电平都OK，还有，AVR内部有一定的硬件处理。
我还看到老外的洗衣机电路的IIC波形更不堪入目，都一样工作很稳定。

如果你一定非要IIC波形处理电路不可，给你介绍一只：PCA95187，它还有电平匹配能力。

mengqian · 发表于 2009-5-27 17:12:20

回【35楼】 capron

谢谢你的建议，我想TWI通信不稳定可能不是波形的原因，采用IO模拟是能够很好的解决不稳定的问题的，所以倒也不再琢磨改善波形的问题了，PCA95187我没用过，不过以后涉及到整流估计还能用的到吧O(∩_∩)O~

yingfu_758 · 发表于 2009-6-2 13:49:28

看了本帖，个人小思：
1、思考I/O模拟IIC和使用AVR 自带IIC总线控制的区别，我觉得最大的区别在于时间。
2、仔细观察有毛刺的波形，几乎都发生在第9个时隙上，也就是产生应答ACK/NACK的地方。
3、综合1，2点及所述实验，我较偏向于是软件对清中断的处理上，软件建议查几个地方：
      （1）主机寻址后清中断的位置。
      （2）主机发每一个字节之后清中断的位置。
      （3）主机发出stop信号之后清中断的位置。
      （4）主机发出每个start信号的条件。

mengqian · 发表于 2009-12-29 17:48:44

现在升级成stm32了，不过stm32的I2C同样很麻烦，调了一天都没任何动静，换成模拟的半小时之内就搞定了，之前看过很多网友评论stm32的I2C麻烦，个人也有同感，本来很简单的东西给搞的太复杂了，单纯发送的话用模拟的太方便了，速度上也能抬升（相对处理器自带的I2C），更不用担心运行到哪死哪的问题，有发有收的还没试过，不过应该也很方便，严重支持模拟I2C!!

佳哥517 · 发表于 2013-8-29 22:04:26

我也使用的是模拟iic

求助，改善i2c波形

阿莫论坛20周年了！感谢大家的支持与爱护！！