[参考译文] TM4C123GH6PM：I2CMasterBusy 卡住

谢谢、我以为可能会发生这样的情况、但我不知道如何摆脱 I2CMasterBusy 的状况。 那么、"位拆裂"到底意味着什么？ 我是否应该将引脚设置为1并循环、直到 SDA 线路被释放？ 或者、我是否需要定期在1和0之间切换引脚、直到线路被释放？

此致、

Ksawery

您需要使 SCL 引脚变为低电平、然后变为高电平。 最坏的情况是当从器件即将响应一个读取请求并且主器件被复位时。 在这种情况下、您需要9次切换 SCL (低电平然后高电平)、然后是一个停止条件(SCL 低电平、SDA 低电平、SCL 高电平、SDA 高电平)。 如果从器件执行时钟扩展或总线上有多个主器件、则会更加复杂一些。

谢谢、我将尝试此解决方案。 最坏情况是否也适用于所有其他情况？ 以下是我的代码的一部分：

// I2C 配置
SysCtlPeripheralEnable (SYSCTL_Periph_GPIOB)；
GPIOPinConfigure (GPIO_PB2_I2C0SCL)；
GPIOPinConfigure (GPIO_PB3_I2C0SDA)；
GPIOPinTypeI2CSCL (GPIO_PORTB_BASE、GPIO_PIN_2)；
GPIOPinTypeI2C (GPIO_PORTB_BASE、GPIO_PIN_3)； 

如果(！I2CMasterBusy (I2C0_BASE)
｛

... //读取 ADC

｝
否则//强制 ADC 释放 SDA 线
{
GPIOPinTypeGPIOOutput (GPIO_PORTB_BASE、GPIO_PIN_2)；
GPIOPinTypeGPIOOutput (GPIO_PORTB_BASE、GPIO_PIN_3)；

//模拟 SCL 时钟周期
对于(ucSCLCycle = 0；ucSCLCycle < I2C_RESET_CYCLLES；ucSCLCYC++）//I2C_RESET_CYCLES= 9
｛
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、0)；//SCL 线路低电平
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、GPIO_PIN_2)；//SCL 线路高
电平｝

//模拟停止条件
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、0)；//SCL 线路低电平
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_3、0)；//SDA 线路低电平
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、GPIO_PIN_2)；//SCL 线路高电平
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_3、GPIO_PIN_3)；//SDA 线路高电平

//将引脚重新配置为 I2C
GPIOPinConfigure (GPIO_PB2_I2C0SCL)；
GPIOPinConfigure (GPIO_PB3_I2C0SDA)；
GPIOPinTypeI2CSCL (GPIO_PORTB_BASE、GPIO_PIN_2)；
GPIOPinTypeI2C (GPIO_PORTB_BASE、GPIO_PIN_3)；
｝ 

此代码是否与 I2C 的标准速度(100kbit/s)兼容？

由于某种原因、我今天无法重现问题、因此我目前还无法测试我的代码。

此致、

Ksawery

好的、我终于设法重现了问题、但上述代码在第一次循环中不起作用-在线路不再繁忙之前输入了两次 else 条件、因此事件序列中仍然有问题。

此致、

Ksawery

谢谢你。 遗憾的是、我目前无法访问范围。 我添加了延迟、但我发现很难再次重现问题。 为什么2us 具体是一个良好的延迟？ 我将以标准速度使用 I2C。

如果我能够重现此问题、我将更新任何进度。

此致、

Ksawery  

 从 ADS1110 数据手册中、无需在标准模式和快速模式之间进行任何更改。 I2C 接口的工作频率最高可达400kHz。 2uS 低电平/2uS 高电平可提供250kHz 的频率、这应该是足够的时间。 如果延迟时间很关键、您可以使用1.25uS、然后仿真400kHz SCL。

谢谢、这很有道理。 我将更新任何结果。

此致、

Ksawery

我设法再次重现此问题、解决方案确实起作用、但是在释放 I2C 线路之前、仍会输入两次 else 条件。 也许我应该增加延迟以匹配100kbit/s 的速度？ 或者、我的代码中的事件顺序可能存在错误？ 我的代码现在如下：

否则、//强制 ADC 释放 SDA 线
｛
GPIOPinTypeGPIOOutput (GPIO_PORTB_BASE、GPIO_PIN_2)；
GPIOPinTypeGPIOOutput (GPIO_PORTB_BASE、GPIO_PIN_3)；

//模拟 SCL 时钟周期
对于(ucSCLCycle = 0；ucSCLCycle < I2C_RESET_CYCLLES；ucSCLCYC++）
｛
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、0)；//SCL 线路低电平
SysCtlDelay (100)；
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、GPIO_PIN_2)；//SCL 线路高电平
SysCtlDelay (100)；
｝

//模拟停止条件
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、0)；//SCL 线路低电平
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_3、0)；//SDA 线路低电平
SysCtlDelay (100)；
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_2、GPIO_PIN_2)；//SCL 线路高电平
GPIOPinWrite (GPIO_PORTB_BASE、GPIO_PIN_3、GPIO_PIN_3)；//SDA 线路高电平

//将引脚重新配置为 I2C
GPIOPinConfigure (GPIO_PB2_I2C0SCL)；
GPIOPinConfigure (GPIO_PB3_I2C0SDA)；
GPIOPinTypeI2CSCL (GPIO_PORTB_BASE、GPIO_PIN_2)；
GPIOPinTypeI2C (GPIO_PORTB_BASE、GPIO_PIN_3)；
｝ 

系统时钟以50MHz 运行。

此致、

Ksawery

[引用 USER="Ksawery">我使用 I2C 模块与 ADS1110 ADC 通信。 我的控制器是线路上唯一的主器件。    一切都正常、但偶尔会发生、当我将应用程序下载到控制器并进入调试模式时、或者当我重新启动器件时、I2C 线路将卡在  I2CMasterBusy 状态

不是，“把一把大的猴子扳手扔进这个 saga”——但你真的想部署“I2CMasterBusy ()”吗？

PDL 注：

16.2.2.11 I2CMasterBusy

指示 I2C 总线是否繁忙。
原型：bool I2CMasterBusy (uint32_t ui32Base)
参数：ui32Base 是 I2C 模块的基址。 说明：此函数返回 I2C 总线是否繁忙的指示。 此函数可在多主器件环境中用于确定 另一个主器 件当前是否正在使用总线。
返回：如果 I2C 总线忙则返回 true；否则返回 false。

您将您的应用描述为，“单从机连接到单个 MCU”-因此“I2CMasterBusy ()”可以证明正确的功能选择吗？   (即(另一个)主设备使用此总线的可能性有多大？)

相反-正如一个过去(非常相似)的线程所指出的那样-  

16.2.2.12 I2CMasterBusy
指示 I2C 主设备是否忙。
原型：bool I2CMasterBusy (uint32_t ui32Base)
参数：ui32Base 是 I2C 模块的基址。 说明：此函数返回 I2C 主设备正忙于发送或接收数据的指示。
返回：如果 I2C 主机繁忙、则返回 true；否则返回 false。

这种"I2CMasterBusy()"是否更适合您的"单主器件"I2C 应用？

请注意-过去曾有过建议-参数：'I2C_MASTER_CMD_BURST_SEND_START'和'I2C_MASTER_CMD_BURST_SEND_CONT'-阻止 I2C 停止位的生成-如果和何时 部署了"更合适的函数"(似乎)...   (即，您不会在出现上述任一(Devil)参数后使用 I2CMasterBusy()。)

感谢您的回复。 是的，我已经在我的应用程序中使用 I2CMasterBusy()了，该部分工作正常。 我不确定我是否应该在我的应用程序中使用 I2CMasterBusy()，因为我只有一个主函数，但我认为它也不会伤害。 现在我遇到了 ADC 有时可以使 SDA 线保持在低电平的问题，我不确定如果我继续运行应用程序而不进行 I2CMasterBusy()检查会发生什么情况。 我宁愿按照 Bob Crosby 的建议手动考虑这种情况。 据我所知、它不会导致应用程序出现任何问题。

此致、

Ksawery

当然、您有自己的权利-但如果我们采用"添加不需要的功能程序"-为什么要停止"仅此程序？"

"并非总是"更好-实际上、可能会"打开您的应用程序"以"意外后果"。   您报告(某些)随机情况的事实实际上是(可能)警告-"所有情况可能不好..."

你的开场白(第2句)清楚地描述了一个单身师父——这一事实(显然)“被人所用！”

生成额外的 I2C 时钟已成功(有时-但不是总是)恢复主从交换。   然而-简单 的'I2C Start' 通常'复位从器件'-再次启用数据交换-然而(也许)不包括您正在报告的'随机性'。   (在我看来-这/类似的技术-证明优于添加(不必要的)多主函数...)

好的、I2C 启动条件确实会"复位"从器件？ 在这种情况下，我同意不需要 I2CMasterBusy()。

嗯，我尝试删除 I2CMasterBusy()条件和“变通办法”代码，所有操作都很好，直到 ADC 在进入调试模式后再次保持线下。 I2C 启动条件对它没有影响-在硬复位之前、应用程序无法读取 ADC。 因此、我将坚持 Bob Crosby 提出的解决方案。

此致、

Ksawery

[引用 user="Ksawere"]一切工作正常，直到 ADC 在进入调试模式后再次保持线下。

然而，当只有一个“单个大师在演奏”时，使用一个旨在“多蒂大师”的功能似乎被误导了。

您进入"调试模式"(显然是(单独)会导致您的问题)的"原因、时间、地点和方式"可能需要进一步(例如、某些)进行真正的检查...   

是否应该(部分)关注/调查外部   从器件(ADC)"将其中一条 I2C 线路保持在低电平？"   这是(或应该是)您的关注点-这不是真的吗？   

通过避免这种分析-您不是、"推广(解决方案)"-而是避免恰当(正常/习惯)但 更有价值的"寻找原因"？   一定要来 "预防"总是远远超出- 任何/所有"希望"的问题...

Bob、

[引用 user="Bob Crosby"]当 IC2主设备在传输期间复位时，I2C 从设备在其当前状态下挂起

感谢您解决此问题。   但是-在哪里有这样的说法：'I2C 主设备'(即这个 I2C 总线上的唯一 MCU)已经被称为'在 I2C 传输期间复位？'   我(有限)的员工(学校已经回收了很多)也没有发现这种情况的"任何"证据！    这是一个关键/关键点-不是吗？  

现在、如果 I2C 事务都处于(两者)"高和持续速率"-也许这样- MCU 的复位(可能)可能会在进行中的传输(实际事务)期间发生。  然而、"根本没有事实证据支持此类交易(高利率/持续 I2C 交易！")

此外-我们的海报必须特别努力来达到这种条件(即故意"重置 MCU -而 I2C 交易正在进行中)-我的团队认为、事实证明"不大可能"发生。   还记得-海报指出多次发生"挂起"-除非他的 MCU 复位电路存在"极有缺陷"-在   这种特定情况下、"MCU 在 I2C XMSN 期间复位"作为"问题触发器"寄存器显示为"已获取"！

此外-对于此类"单 MCU /主系统"、'I2CMasterBusy ()'函数的使用仍然是'不正确'(从'Get-Go'开始是如此)-这是海报的现实。   (在直指"避免"的情况下-继续干扰！)

事实上、"您"在调查(通常)"所需的 SCL 时钟数"以"租用总线"方面所做的特殊努力证明了信息丰富且有帮助。   然而-大学生和 我"继续"认为"最有可能导致奴隶不适的原因的覆盖面"仍然"未知"、  并且没有开展任何调查活动。   (这里没有人认为这是"最佳实践"-显然值得(一些)时间和精力！)   

似乎、"将 MCU 复位为 ADC 的复位值(假设电压电平类似)会有助于"自行清除" ADC！   (如果它受到干扰/困扰。)   此外-在 MCU 和寻址外设之间的任何事务之前、必须保证足够的"时间通过"-在 MCU 复位后立即进行。   人们相信，“这一纪律”——以及删除(不适当的)“I2CMasterBusy ()”——提供(两者)一 个广泛而真实的解决方案——并且(可能)消除(至少大大减少)对“SCL 时钟的大量”的要求！

从"长期"-有时令人痛苦的经历-我认为、"很可能"导致此类"I2C 挂起的原因可能是：

"不必要/非法的脉冲"-直接耦合或在 SCL 信号线路上引起！"   这将导致" MCU-Slave"后续(或正在进行)事务变为"不同步"-可能触发从属方的"总线闲置"。   I2C 信号长度过长、PCB 布局不良、噪声源放置在离(尤其是) SCL 信号布线太近的位置、以及使用"值太高的上拉电阻器"(即 MCU 内部的(来自任何供应商)-上述任何/全部都是"经证明的、可能可疑的！"    

也许"额外的探究水平"(此处建模)更好地说明了"确定问题的"最可能原因"、并源于这一见解-发展卓越的、重点更突出的解决方案！

尊敬的 CB1：

感谢您的回复以及在尝试识别问题时所做的努力。 Bob Crosby、感谢您的澄清。 我可以确认问题很少发生、并且在将我的应用程序反复下载到控制器并进入调试模式时、我完全偶然发现了这一问题。 因此、正如您提到的、这可能会导致 SCL 线路上产生不需要/非法的脉冲。 我确信、在正常使用期间、问题不太可能发生(假设电路的其余部分(我不负责)正常工作)。 但是、由于我将把我的项目转交给另一个工程组(这纯粹是一个内部项目)、 对于那些只需要 IT 工作并且不熟悉应用细节的人、我不希望他们遇到任何意外问题(例如、他们必须手动重启器件的情况)。

考虑到我几乎完全不熟悉嵌入式编程、这是我在这个工作场所的第一个项目、现在我对这个变通办法感到满意-即使没有必要、它也证明可以在这些罕见的事件中工作。 也许，在未来有更多时间研究这个问题时，我可能会放弃使用 I2CMasterBusy()，但现在已经证明它是有用的。 如果您对该问题有任何其他见解、我很乐意将其考虑在内。

此致。

Ksawery

谢谢您-感谢您的周到回应。

作为一个活跃的论坛-首先是由'Luminary Micro Systems'(即 Stellaris 创建者)拥有/运行的论坛、现在已超过10年-以及超过25年的'Tech Wars'(包括共同创建-吸收过去的 Tech FiRM Public)-已经学习了'som'课程(也许)。   而且-希望-大部分知识、方法/(疯狂？) 精练的——可能会为他人服务——甚至在这里！

没有什么可添加的-但这些项目(可能)需要考虑：

• 任何高性能、分立式 ADC 始终"要求"设计良好的 PCB。   试验电路板几乎"保证"故障-评估板上提供大多数分立式(性能) ADC -始终是明智的选择。
• 当 MCU 和 ADC 板之间的"接线或布线"时、2个 I2C 信号连接应尽可能短且尽可能直接。   如果存在高频信号、高电流(通常大于5A)或(其他)噪声源-这些 I2C 连接应"最大限度地分离"。    
• 如果上述(电线/电缆)制导失败-部署"短电缆"可能会很有用-尤其是对于(更容易受到攻击) SCL 信号。   首先将电缆的屏蔽层接地至 ADC 的接地端-请勿(最初)将电缆的 MCU 端接地。
• 必须始终(适当)怀疑功率不足(尤其是在高数据速率下)。
• 如(之前的 POST)所述、通过连接(MCU 和 ADC 的复位引脚)(假设这两个引脚都兼容)、可以大大降低 MCU 复位"降级/中断"的能力。   此外-始终为(任何) MCU 外设留出足够的时间从复位状态恢复-并准备就绪。   供应商的 API 提供了一个"确切功能"、使 MCU 能够确认外设的"正常"。

对于"点"(就在上面)-" MCU 和 ADC 复位线路的连接"-您将保持沉默(如适用)。   多个"验证"已获得批准-但这项(相信)卓越建议似乎"逃避了您的通知"-我们是否可以问为什么？

任何认真的"迹象审核"都将检测到"多主控"I2C 函数的存在(不正确)-这无法证明您的优势-我不知道(如何更好)再次强调这一点...

CB1先生和 Bob 先生，你太好了，我的偶像，我完成了比赛，  现在正在研究你的答复。

谢谢王先生。   "mrrbo"就是这样-对于这位(简单)记者来说不是很好。

我会将您的好信转寄给我的假释官员-请注意(之前)伊利诺伊州州长和'CB1'- 希望"提前释放"。

你可能希望"下午"我、因为我在这里的时间非常有限-"去哪里欣赏"证明是一个很好的选择。。。"

尊敬的 CB1：

     你知道我的英语不是很好，但我能感觉到一些东西，你觉得好吗？

     祝君安好。