I2C程序出现的异常——STM32

在I2C程序中，很多时候使用while来判断状态是否发生改变。正常情况下，这个是很合适的。使用while，即做到了检测也起到了延时的作用，比单纯的计数延时要好的多。

但是如果不正常的时候，在while处的程序执行是否还在我们预期范围内，就很难说了。程序卡死在while处的情况会有吗？

首先，如果I2C链路连接有问题，肯定会出现问题的，这个时候由于while检测不到相应的状态改变，在这里卡死很正常。或许这也能帮助我们更快的定位到出错的地方。

但是，如果是链路通信正常，I2C还会检测不到状态的改变而导致while挑不出去的情况吗？

之前在一个论坛（见注1）上看到过一个关于I2C在高负载中断下接收出现异常的情况。但是通篇帖子并没有提到，当异常时程序是仅仅丢失数据，还是不在执行。按照帖子来猜测，感觉是仅仅丢失数据，如果程序卡住了，作者应该会提出来这个问题。但是没有，仅仅说了程序接收的数据不正常。

因为不知道他的I2C程序，是否仅仅使用while作为判断状态改变的依据，还是已经做了相关的超时处理什么的。既然程序中，有超出判断内的情况出现，最好还是将其消除。

对于仅仅使用while的语句，加上必要的超时处理。让程序的执行在判断的情况内。

按照正常理解，这里对于while出现卡住的问题，应该很难出现。如果在中断负载很重的情况下，这很难说。帖子中，作者最后说是硬件电路的问题，总线可能缺少一个并联电容。如果存在这样的问题，那么软件作相应的规避可能也是应该的。

同时这里提出这样一个问题，当软件运行时，最好的情况下是，一个函数不论输入是什么，都能保证输出时正确的，在可控范围内。这样一程序的整体性能，会是可控的。如果一个函数的输出正确与否，取决于输入，这样很可能造成一些可控范围之外的现象发生。如何做好出错处理，对于一个函数的输出也就十分重要。

尤其对于所做的嵌入式设备，因为它们更注重长期运行，不允许有程序卡死的现象出现，对于错误的容限要高一些。这里边对于数据的考虑与处理就要相应更全面。想到这里，发现似乎产品的应用环境越处于底层，对其要求就越高，因为有很多其它高层程序依赖于底层的输出，如果底层出现异常将导致整个系统的崩溃。系统级编码的代码质量要求标准高于应用级编码。即使同在应用级，处于底层的代码质量要求高于上层。

注：

1、http://electronics.stackexchange.com/questions/58653/i2c-read-write-failure-under-heavy-interrupt-load

I2C read/write failure under heavy interrupt load