[参考译文] TM4C123GH6PM：I2C 卡在无限循环中

我很高兴听到它不是一个真正的鲨鱼:)幸运的是你可以冲浪！

我在代码中尝试从 ADS 1110重复提取两个字节、这是一个16位 ADC。  因此、每次调用上述函数时、我希望它以两个字节获取 ADC 的16位值、并将这些字节存储在缓冲区中。 可从以下位置获取 ADC 的数据表：

https://www.ti.com/lit/ds/symlink/ads1110.pdf

我的代码基于 TivaWare 外设驱动程序库用户指南第16章(I2C)中提供的建议：

http://www.ti.com/lit/ug/spmu298d/spmu298d.pdf

在本章的开头、有一个在对 I2C 主器件进行编程时建议的函数调用序列。 有两种接收数据的方法-轮询以检查主器件是否不再忙、或中断。 由于我的应用程序已经使用 UART 和计时器中断，我不想在上面添加 I2C 中断，所以我选择了轮询方法(因此我对 I2CMasterBusy()的调用)。 我不确定如何完成我的代码、因此我参考了在 google 上找到的以下论坛帖子：

https://e2e.ti.com/support/microcontrollers/other/f/908/t/314084

现在、我了解了 I2C 显然应该被连接以使其正常工作、但我也想说明连接不存在的情况-例如连接中断或 ADC 中断。 在这种情况下、我希望应用的其余部分继续正常工作(并且仅记录任何 I2C 错误)。

因此、考虑到所有这些因素、在不进入 while 循环的情况下、实施它的最佳方法是什么？ )

非常感谢、希望您有一个良好的飞行、

Ksawery

Kwasery、您好！

我认为 I2C 超时 API 不会有助于打破 while 循环。 我想这只是为了时钟拉伸的超时。

您需要在内部添加一个检查以查看相关内容。 如果您返回错误、例如 CB1在起始位中提到的错误、您可以检查内部错误以断开。 或者、您可以有一个由计时器设置的标志变量-该变量与 I2C 超时值不同、但可能更多的是您正本着这种精神所需的。  

此外、您可能还需要尝试使用以下内容

while (！(I2CMasterBusy (I2C0_BASE)))；

while (I2CMasterBusy (I2C0_BASE))；

而不是  

while (I2CMasterBusy (I2C0_BASE))； 

我记得、调整之前帮助了许多客户解决了 I2C 问题、尽管我认为其中的任何情况都不是因为 while 函数挂起、因此它可能不适用于您缺少从设备的情况。 解决数据传输问题的方法更多。 不过、或许值得看看这种快速调整是否可以解决问题。

您好、Ralph、

巧妙地将您(熟练)的声音添加到海报的主题中。  您的输入 RE："I2C 超时"是最有启发性的。

然而，我想补充一点， 这种“背靠背”(近)相同的调用的第一次(历史)出现，是为了：

• (！(I2CMasterBusy (I2C0_Base)))；

然后

• (((I2CMasterBusy (I2C0_Base)))；

您的'4C129'系列推出的附加速度的'修复'到达。   与我的团队一样、此海报采用了'4C123'。

我们发现，“即使这个机制”也证明“不”是100%的欺骗。

在我的办公室的某个位置、我们编写了代码、以便在多字节 I2C 从设备事务中实现(成功)。  如果时间允许-我将在这里发布...

现在添加： (出现 Young Chi。 员工比海豚(攻击)快！)   随后的代码在'4C123'上运行并与(贵公司的) ADS7924交谈。   (MCU 上的 ADC 通道"用完了"！)

无符号长整型
ads7924_conv (空)
｛

ROM_I2CMasterSlaveAddrSet (I2C1_MASTER_BASE、0x48、TRUE)；  //读取

//通道0转换开始：
ROM_I2CMasterControl (I2C1_MASTER_BASE、I2C_MASTER_CMD_BURST_Receive_start)；
while (ROM_I2CMasterBusy (I2C1_MASTER_BASE))｛｝

ulADC0_UP = ROM_I2CMasterDataGet (I2C1_MASTER_BASE)； //从 ADS7924读取的高4位

ROM_I2CMasterControl (I2C1_MASTER_BASE、I2C_MASTER_CMD_BURST_Receive_CONT)；

while (ROM_I2CMasterBusy (I2C1_MASTER_BASE))｛｝

ulADC0_lo = ROM_I2CMasterDataGet (I2C1_MASTER_BASE)；  // 从 ADS7924读取的低8位

//通道1转换开始：
ROM_I2CMasterControl (I2C1_MASTER_BASE、I2C_MASTER_CMD_BURST_Receive_CONT)；    
while (ROM_I2CMasterBusy (I2C1_MASTER_BASE))｛｝

ulADC1_UP = ROM_I2CMasterDataGet (I2C1_MASTER_BASE)；  //4个最高位

ROM_I2CMasterControl (I2C1_MASTER_BASE、I2C_MASTER_CMD_BURST_Receive_finish)； //此'Receive_Finish'(应)生成停止位。

while (ROM_I2CMasterBusy (I2C1_MASTER_BASE))｛｝
ulADC1_lo = ROM_I2CMasterDataGet (I2C1_MASTER_BASE)；  //最低8位

***请注意-此代码在'TELARISWARE Ver 9453！'下运行   然而-那些早期的'I2CMasterBusy'检查似乎发生在减去中间站的到达！  因此、他们应该"勾选！"  

这一个-生成了"停止"！  (即无粘滞)

StellarisWare 与重新品牌之间存在相当大的变化-因此-我们的投资者(前身)多年来一直转向重新品牌。

当我回到 Chi 时、我会让员工 找到其中一个较旧的板(带 LX4F231 MCU)、并能够确认(实际上)那些(现在可疑)在循环"逃脱了！"  我们实际上从 ADS7924读取了4个通道-我在这里压缩了代码以"方便查看"。

图解更浓-不是吗？

***在我返回办公室之前-“不是关键测试 A，范围附件至“DA/SCL”-“确定是否存在“停止！”   如果不出现“停止”-我的信念(认真地-谁在乎)是 “不存在停止”将“标记”代码 ... 不包括在(现在可怕的) 'I2CMasterBusy'循环中。

感谢您的回复。 我尝试向 while 循环添加错误检查、如下所示：

我假设、如果没有响应(既不是确认也不是确认)、至少该库会生成错误。 但是、如果主设备忙、I2CMasterErr 会记录所有错误：

因此、我仍然不确定如何处理此问题。 您的使用建议

while (！(I2CMasterBusy (I2C0_BASE)))；

while (I2CMasterBusy (I2C0_BASE))；

不幸的是没有帮助。

我还尝试通过将其添加到 TivaWare I2C.c 和 I2c.h 库文件来实现以下内容、但我不断收到链接器错误：

https://e2e.ti.com/support/microcontrollers/other/f/908/t/444151

如何修改库而不获取链接器错误？ 我非常确信我的自定义函数定义和声明是正确的、并且位于正确的位置。

非常感谢、

Ksawery   

赦免-我是否可以"重复" (显然)先前提出的"很少注意到的指导"？

[引用 USER="CB1_MOBIT"]重要提示： 将范围附件添加到"SDA/SCL"-以"确定是否存在"顶部！"[/QUERE]

MCU 手册规定：

• 'start'设置'CS'忙位
• "stop (停止)"将其复位

通过详尽的阅读(MCU 手册、示例代码)、没有发现其他机制。

"理论化"：

• 'I2C_MASTER_CMD_BURST_Receive_start'(参数) '阻止'Sltop'的发射
• "I2C_MASTER_CMD_BURST_Receive_CONT"(参数)  "阻止"停止"的发射
• 'I2C_MASTER_CMD_BURST_Receive_finish'(参数) '启用'停止' (因此应'退出'您的'挂起' while 循环。)

在"设置您的 I2C 无中断"目标中显示了"一种其他方法"。  我怀疑 在每次调用包含这些(上面列出的3个)参数的函数之后插入一个简单的延迟将使您的代码能够正常执行！   请注意- "delay" 可作为有问题的 while 循环的替换项。  (它们不是一起使用的。)  怀疑'finish'参数(可能)启用 while 循环的'escape'- 并且该循环(始终)将优于固定延迟-假设可以(正确)退出该循环。

每次 确认正确的结果时、我都会首先"延迟几秒"、然后系统地减少。  (我会在您的"最小值"上以~30%的延迟结束-这允许：温度、过程变化和 MCU 老化。)

感谢您的回复和努力帮助我解决此问题。 我最终实现了一个自定义超时计时器来指示主机超时并设置停止位。 当 I2C 线路断开连接时、我的应用现在可以正常工作、但我尚未在连接线路的情况下对其进行测试(计划在明天进行测试)。 今天我没有访问范围、因此我无法测试是否存在该站点。 我的 I2C 接收函数现在如下所示：

我仍需要微调 I2C 超时值、以确保它不会太短(或太长)。

非常感谢、

Ksawery

谢谢-谢谢。  希望了解一些有关该 "while 循环"的"PDL (视在)实施"(正如您所注意到的)的"内幕信息"。  

尤其是当这两 个"CMD-burst-receive Parameters"(START 和 CONTR)出现为"burst"(抱歉)时、停止生成。  (因此将 PDL 代码声明为 "while loop - permanent residence！")  我的团队发现"仅一句话"引用了开始和停止生成-包含在1K+页中！

由于我们的团队(根据多个客户需求)使用来自四家供应商的 ARM Cortex MCU (M0、M3、M4、M7)、因此(稍后)探讨(是否)如何解决(或不解决)此问题将会很有成效。  ("一种也只有一种技术"-这里的日常居民-证明存在局限性-不是吗？)

员工(最年轻的人)要求您考虑"其中一条或两条 I2C 线路变得开放"的结果。  您的诊断-要真正有效-必须考虑"所有这些事件！"   (想知道-如果和如何-飞利浦((2C 的发明人)"创建了这样的诊断和/或恢复方法。")

另请注意、某些从机(取决于其"工作负载")可能会"下拉"并保持时钟、从而(中断)您的计时器(以及我们的延迟)作为有效的"现已就绪"实施。

您好 CB1、

我认为您提出了一个关于从器件将 SCL 线保持在较低水平的时钟拉伸的好问题。  不过、I2CMasterLineStateGet API 可能可用于解决此问题。

在这种情况下、由于上拉电阻器而未将器件连接到总线的情况下、我可以想象 SCL 线路为高电平。 如果是这种情况、那么使用该 API 将为 SCL 返回高电平、并且超时可用于跳转。 然后、SCL 低电平的备用情况可视为时钟拉伸、并可开始进一步等待。

我认为这将是一个可行的解决办法，涵盖这两种情况。

您好、Ralph、

请原谅我的"运动"回应-今天不得不扮演销售员-有能力的年轻员工(几乎准备好接管)-我们花了90分钟-实现 了6.1英里！  (当然是'道山')  我们尝试了2个'额外'(东-西(平行)过境点-所有这些 都在'建设中！'   自我/他人注意-芝加哥有两个季节： "北极冬季和建筑！"  (请保持-我的心！)

我喜欢您的评论-但员工/我仍然感到烦恼、"该代码(曾经)是如何运行的？   尤其是  在遇到对"CMD_BURST-Receive"的这2个调用时？  这些调用中的任何一个都应该"将代码锁定在该"while 循环"的"副控制"中-它们不应该？   (由于"停止"被绕过-并且"仅停止"可以清除 I2CMCS 的"繁忙位"-启用 while 循环中的"退出"(可怕)...)

员工在这里寻求“进入记录”：“只有胡迪尼(*)可以摆脱那种“while 循环”的爪！”    (可能)

* 胡迪尼-著名的逃亡艺术家

感谢你的答复。 在我的情况下、ADC 不执行时钟扩展、因此我不必担心。

此致、

Ksawery  

今天早上好、"免施工、通勤"、前往(附近)办公室。

其中一名年轻员工(学院 青年)指出、我们这里的"三个人"已经"了解了使用有效的从属设备运行(原始 PDL 代码)的潜在价值-连接和执行！"   这至少会"确认或拒绝"'PDL 代码的正确性。"   我相信她是“大坑”的——而且我们(合理)今天“大坑” (哈！) ——她会“攻击该任务”。   (很高兴有一个员工："更好的外观、更年轻、更聪明"... 比自己更好。。。)

我们(所有人)是否会从"详细说明"中获益：(始终可疑)"I2CMCS 忙位？   

您好、Ksawery、

您的问题是否在 CCS 调试步进期间发生？ 如果您运行代码行、它是否仍然卡住？

-kel

您好、kel、

正常运行应用程序时出现问题。 如果没有自定义超时计时器、我将无法通过该行。

此致、

Ksawery

[引用 user="Ksawere">正常运行应用程序时会出现问题。 [/报价]

请本报告员与'当日 Crüe '(4强)一起注意、'始终不在从属方'似乎偏离了'正常！'的定义

如上所述(员额数少)：

"其中一名年轻员工(学院 青年)注意到、"我们三个人都在这里-已经"了解了使用有效的从属设备运行(原始 PDL 代码)的潜在价值-连接和执行！"   这至少会"确认或拒绝"'PDL 代码的正确性。" "

我的所有培训/经验"订单"、"从"高标准"开始-用例！"

• 首先在"正常和习惯"操作条件下验证(代码和硬件)。  (即从器件存在和功能)
• 只有这样-成功后-"打破"标准"-引入最"有限/温和"的变革(理想情况下一次只有一次一次)-然后再次系统地测试/验证

我在前面的文章中"强调" MCU 手册说、"START 设置 I2CMCS 忙位- STOP (显然是单独的)重置它！"  

作为3个'CMD_BURST_Receive'参数中的2个'Block the stop' (阻止 BUSY 位清除)-它使人们无法理解 'following wait loop'只能被原始 PDL 代码“转义”！

我的团队认为——(亚波尔站)仍然是“房间里的大象”——尽管—特别是——这一事实一直是，“向路边”！

尊敬的 CB1_MOBILE：

很抱歉、我的回复延迟了、因为一些基本电路组件还没有到货、所以我还没有能测试我的应用。

许多人感谢 Cassandra 为调查这一问题所作的努力。 因此、CMD_BURST_Receive_start 参数确实是导致问题的原因。 我假定(根据 Amit 的建议)此参数对于多字节传输至关重要。 能否使用海报最初提供的代码实现相同的2字节传输？ 即：

///------------------------------  接收---------------------------------------------------

I2CMasterSlaveAddrSet (I2C6_BASE、0x48、TRUE)；//将从地址设置为0x48、启动读取

I2CMasterControl (I2C6_BASE、I2C_MASTER_CMD_SINGLE_RECEIVE)；//接收

while (I2CMasterBusy (I2C6_BASE))；//等待事务结束

字节1 = I2CMasterDataGet (I2C6_BASE)；//从 FIFO 读取

I2CMasterControl (I2C6_BASE、I2C_MASTER_CMD_SINGLE_RECEIVE)；//接收

while (I2CMasterBusy (I2C6_BASE))；//等待事务结束

字节2 = I2CMasterDataGet (I2C6_BASE)；//从 FIFO 读取

大家好、'Cassandra、其他员工和 CB1'都很高兴您能回来。

在1K+页的 MCU 手册中、这句话是"真正需要的一切"。  (描述'I2C start as setting 'busy'和(仅限)'I2C stop' as Resetting 'busy'的句子。)   然后、我们注意到确实存在'I2C 错误函数-该函数旨在确保'I2C 停止'的传输。

我们相信(但尚未正式测试)这(过去)海报的准则、但我们相信它将会成功。

但是- Amit 也是如此-前提是 MCS 'Busy'的初始测试(已突出显示)已从代码中删除！

现在(两者都有) Cassandra 和我都注意到您对"Just One"(即"CMD_BURST_Receive_start")参数的识别为"wait-loop Hanging"(等待循环挂起)。   实际上-有两个！   (正如我们在上面的帖子所说的-相当清楚(和突出显示)！  你/他人(甚至 Cassandra 和我自己)必须 "离开"等待循环-遵循(两个)这些(同样是两个)邪恶参数！

(非常想念)*** Like Button ***已经消失了(在这里消失了-从这个(不好的认可/奖励空间)中追逐我的团队，您是否可以代表您(和这里的其他人)奖励我们的“明星”给她，“超越/超越努力”？   轻触绿色 (验证)似乎非常合适-并发送正确的消息-是否正确。

祝您好运-所有"等待退出"的变通办法/绷带/猜测都可能被丢弃-现在(真正的解决方案-早已确定-顺便说一下)和现在 正式和准确地验证-已经"淘汰"并 完成！

明白。 我应该能够在本周进行测试。

再次感谢您(和您的员工)提供的宝贵帮助！ 我已将帖子标记为已解决。

此致、

Ksawery

如果这里只有“SOUND”的话。   (然后您会听到我们(组合)最棒的猫王...  "谢谢您... 非常感谢" (用我们的"真"(好吧-有点假-诚意)  和(那)保持"对国王"的每一句话来表达)  

员工 和莫伊-确实要做-谢谢。   相当整洁的学习体验——希望能给许多人带来好处——特别是“攻击的方式”！  (即使是"持续要求...")

[编辑] 09：15 CST ... Crack (主要) gurl 员工请求您的'Subject Line edit' "I2C 停留在无限循环中(但不再如此)！"   不妨：

• 向读者保证您的线程取得成功-从而鼓励(增加)线程点击次数！
• 并正确记下您的线程的"良好解决状态"、始终对他人有价值

对这位记者来说、"好主意"(超出预期)-我必须提醒您-是(大大)编号过大...  (这也不是令人不愉快的...)