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.

[参考译文] OPT3004:结果寄存器保存完整的 16‑位值

Guru**** 2905440 points

Other Parts Discussed in Thread: TLA2528, OPT3004

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

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1644016/opt3004-results-register-holds-the-full-16-bit-value

器件型号: OPT3004
主题中讨论的其他器件: TLA2528

您好、专家!

并按如下方式配置传感器:

  • 量程编号 (RN[3:0]):自动满‑标度模式 (1100b)
  • 转换时间 (CT):800ms (1b)
  • 转换模式 (M[1:0]):连续转换 (10b)
  • 锁存 (L):透明迟滞 (0b)
  • 极性 (POL):高电平有效 (1b)
  • 屏蔽指数 (ME):禁用 (0b)
  • 故障计数 (FC[1:0]):四个故障计数 (10b)

Cortex‑M33 微控制器上运行的 FreeRTOS 实现中、我每秒读取一次结果寄存器。‑、我会‑一个完整的 16 μ s 位值 (65535)、这会导致根据数据表产生无效或超出‑μ s 范围的读数、以及传感器在转换为照度时的测量能力。

您能帮助我了解为什么会出现这种行为以及如何避免这种行为吗?

提前感谢!

下图显示了 16‑位结果寄存器值(寄存器值)、通过 I2C 接口实现直接从传感器读取。

image.png

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

    您好 Ramon、  

    65535 = 1111 1111 1111 1111 b. 没有指数值应报告超过 1011 的状态。 在这个测试中、器件暴露在什么光照条件下?

    谢谢您、  

    Joseph Scherphorn

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

    您好、Joseph:  

    该器件暴露在 黑暗条件下(完全遮蔽的照明)。 这由结果寄存器一致报告值 5 (0.05lux)进行确认、异常值 65535 除外

    此外、根据下面随附的其他日志、该问题也会在 办公照明条件下发生、其中器件通常报告约 217 (2.17lux)的值。

    到目前为止、未发现异常读数与照明条件之间的相关性;行为似乎是 随机发生的

    您是否了解传感器偶尔报告此值的原因?

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

    您好 Ramon、  

    您能否提供逻辑分析仪屏幕截图、或者最好是此 i2c 事务的示波器屏幕截图? 这似乎是通信问题。  

    您在操作设备时多久会看到这种行为?

    谢谢您、  

    Joseph Scherphorn

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

    您好、Joseph:

    当然、下面是逻辑分析仪的屏幕截图、其中显示了系统正常运行时的 I2C 事务。

    逻辑分析仪报告的值 (0xD1) 也已捕获到日志中。

    这种行为似乎是随机发生的。 在日志捕获的 17 小时内(每秒采集一次样本)、发现了 7 次问题
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Ramon:  

    这有助于验证、但我认为如果没有看到您看到错误值的实际事务、我将无法找出根本原因。  

    这是共享总线上吗?  没有理由指数读数应始终高于 0xb_1011。 我的假设是其他东西上拉总线。  

    谢谢您、  

    Joseph Scherphorn

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

    您好、Joseph:

    很抱歉耽误你的时间。

    我可以重现值不正确的事务;我在下面分享了一个示例。 我还注意到 SCL 线路保持低电平约 79ms。 该总线与 TLA2528 ADC 共享。

    谢谢!

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

    您好 Ramon、  

    感谢您提供的所有信息、这对您很有帮助。 这些事务很奇、隔离 OPT3004 是否可行检查总线是否被其他器件拉至低电平?

    谢谢您、  

    Joseph Scherphorn  

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

    您好、Joseph:

    使用当前的系统实施来隔离 OPT3004 行为是不可行的。 但是、CPU 负载和任务调度可能会影响 I²C μ s 事务的时序。

    在由任务优先级驱动的 CPU 负载增加期间、通信时序可能会受到影响。 这可能会导致 OPT3004 达到其 28ms 超时、从而导致无效读取、在 SCL 线保持低电平后、SDA 线保持高电平。 因此、系统会将读取值解释为 0xFFFF

    感谢您的支持!