我们已转向使用中断驱动型 I2C 实现、以避免在我们自己的 SensorHub 器件驱动程序代码和初始化例程内出现任何繁忙循环。
在转换为中断驱动的实现过程中、遇到了几个问题、尽管他们有解决方案、但他们仍担心我们会遇到一些计时和竞争情况。
1) 1)将 I2C 总线配置为大于100kHz 的任何频率(UCB0BRW = 10、SMCLK@2MHz)将导致在尝试仅读取2个字节时从总线上读取额外的字节。 当 UCTXSTP 在要接收的下一个到最后一个字节上被置位时、就会发生这种情况、但是、通过相关的中断服务、RF430FRL152H 会发现一个字节太晚。 如果在射频接口与电话或阅读器交互之前使用相同的中断驱动代码、则不太可能发生此问题。
2)同样、当工作频率高于~30kHz 时、STPIFG 标志和中断在最终 RXIFGx 和中断被处理前被处理。 这意味着、除非在 USCI_B0_Vector 中的 STPIFG 情况下跟踪此状态并且读取最终字节、否则会丢失一个字节。 这似乎不是两个字节读取的问题、但可以在3个字节及更大的字节上清晰跟踪。 行为因所需的字节数而异。
每个条件都已在运行 SensorHub 固件的 RF430FRL152HEVM 上复制、并使用 Maxim DS3231等支持顺序寄存器读数的器件。 任何此类器件都能做到、这只是一种现成的器件。 最初在 PT7C43390上看到的是实际问题。 后者更严重、因为从寄存器中读取的字节多于或少于预期会导致它挂起总线。
话虽如此、问题是 RF430FRL152H 是否通常遇到这些行为以及是否存在建议的解决方案。 我们试图避免发现上述解决方案只能进一步掩盖问题、而不是解决问题。
所有这些都使用单传感器器件读数进行了测试、与 TI 提供的示例 Android 应用的工作方式类似。
谢谢、Karl
