• 状态 Resolved
  • 已锁定 已锁定
  • 回复 1 回复
  • 订户 0 订户
  • 视图 0 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM263P4-Q1：有关同时执行多个 I2C 通信时的操作

admin
Guru**** 2895030 points

Other Parts Discussed in Thread: SYSCONFIG

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1645808/am263p4-q1-regarding-the-operation-when-multiple-i2c-communications-are-performed-simultaneously

器件型号： AM263P4-Q1
主题： SysConfig 中讨论的其他器件

在与外部 EEPROM 进行 I2C 通信期间（执行 I2C_TRANSFER() 时）发生超时。 情况概述如下：

*正在使用 AM263Px MCU、SDK 版本 09.02.00。

* I2C3 用于与 EEPROM 通信。

*要启用超时, SDK 的 eeprom_write () 和 eeprom_read () 函数不用于与 EEPROM 的通信。 而是使用添加了超时设置的自定义函数。

*超时持续时间是根据从比特率和数据传输音量得出的估计通信时间来设置的。

*一个单独的任务是使用 I2C1 和 I2C2 与 EEPROM 以外的器件进行通信。

*所有 I2C1、I2C2 和 I2C3 设置的比特率都相同,中断被禁用。

*我们已经确认在与 EEPROM 进行通信时,I2C1 和 I2C2 通信（执行 I2C_TRANSFER()) 在一个单独的任务中发生。

*进行以下更改后,与 EEPROM 通信期间的超时不再发生:
**禁用 I2C1 和 I2C2 通信、或在与 EEPROM 通信期间显著延长超时时间。

根据上述情况、我们认为同步 I2C 通信产生的作用会延长通信时间。
请告诉我们这种现象的原因并提出相应的对策（例如，在同时进行 I2C 通信时估算通信完成前的时间的正确方法）。

预期响应日期：2026/5/17

  • 0
    TI__Guru**** 2895030 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好、Imaoka、

    设置中的关键细节是 中断被禁用、这意味着所有三个 I2C 实例 (I2C1、I2C2、I2C3) 都在 轮询模式下运行。 在轮询模式下、I2C 驱动程序在主动轮询硬件寄存器以完成每次传输的同时阻止 CPU [1][2]。

    由于 I2C1 和 I2C2 在单独的任务中进行服务、因此发生了以下情况：

    1. 您的 EEPROM 任务 I2C_transfer() 在 I2C3 上以轮询/阻塞模式启动。
    2. RTOS 调度器允许运行其他任务（处理 I2C1/I2C2）。
    3. 该任务也会 I2C_transfer() 在轮询模式下调用、这会 在轮询 I2C1 或 I2C2 完成时垄断 CPU 周期。
    4. 在此期间、I2C3 硬件外设继续其总线事务 、但软件无法为其提供服务（读取 FIFO，前进状态机，确认字节）、因为 CPU 占用了轮询另一个实例。
    5. 这会将 I2C3 传输的有效完成时间延长到远远超过理论比特率计算、从而导致超时到期。

    每个 I2C 实例 (I2C0–I2C3) 都是 独立的硬件 [3]、因此不会发生总线级仲裁冲突。 争用完全在 CPU/软件级别 —多个轮询传输竞争同一处理器。

    建议的对策

    选项 1（强烈建议）：切换到中断模式

    通过 Sysconfig [2]为所有 I2C 实例启用中断模式。 在中断模式下：

    • 当数据就绪或传输完成时、硬件会产生中断。
    • CPU 未被阻止轮询寄存器、因此多个 I2C 实例可以同时进行、而不会相互崩溃。
    • 传输完成时间将与基于比特率的理论估算非常接近。

    这是可实现并发多实例 I2C 运行的架构正确解决方案。

    选项 2：对 I2C 操作进行串行化

    使用互斥量或信标来确保一次所有任务中只执行一个 I2C 传输。 这消除了 CPU 争用、但降低了吞吐量。

    选项 3：调整任务优先级

    如果 EEPROM 任务的优先级高于 I2C1/I2C2 任务、并且启用了占先、则 EEPROM 轮询传输不会被中断。 但是，这仅在低优先级任务无法抢占时有效 — 验证您的 RTOS 调度配置。

    选项 4：延长超时（仅限权变措施）

    正如您发现的那样、延长超时时间是有效的、但这不是一个可靠的解决方案。 如果必须使用此方法、则超时应考虑以下因素：

    有效超时=（基于比特率的 I2C3 传输时间）
    +（来自其他 I2C 轮询传输的最坏情况阻塞时间）
    +边距

    其中、最坏情况下的阻断时间= I2C1 和 I2C2 上可以在 I2C3 传输窗口期间执行的最大传输持续时间之和。

    正确的估算方法

    当对多个并发 I2C 实例使用轮询模式时、理论传输时间公式为：

    T =(NUMBER_OF_BITS)/(BIT_RATE)

    不足。您必须添加最坏情况下的 CPU 不可用时间、即在返回为您的 CPU 提供服务之前、CPU 轮询其他 I2C 实例可能占用的最长时间。 这取决于任务优先级、其他实例上的传输大小以及调度行为。

    在 中断模式下、理论公式再次有效、因为硬件会独立于 CPU 可用性来推动完成。

    为了帮助完善这项建议、了解以下信息会有所帮助：

    • 处理 I2C1/I2C2 任务与 EEPROM 任务的 RTOS 任务优先级
    • 所有 I2C 实例是通过同一任务/线程还是不同的执行上下文提供服务
    • I2C1 和 I2C2 上的数据传输大小（用于量化最坏情况阻断）
    • 您的自定义超时实现是否考虑了操作系统任务切换开销
    • 特定的 EEPROM 器件时序（页面写入时间，时钟延展行为）

    有力支持

    1. I2C LLD API 指南 — AM263Px
    2. I2C HLD API 指南 — AM263Px
    3. SOC 模块 — I2C 基地址定义
    4. I2C HLD 模块 API
    此致、
    Zackary Fleenor