• 状态 Resolved
  • 已锁定 已锁定
  • 回复 11 回复
  • 订户 0 订户
  • 视图 507 视图
  • 用户 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.

[参考译文] MSP430F5438：在读取 RTC 计数器时、可选择多数票决

admin
Guru**** 2555640 points
Other Parts Discussed in Thread: MSP430F5438, MSP430F5438A

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

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/597070/msp430f5438-alternative-to-majority-vote-when-reading-rtc-counters

器件型号：MSP430F5438

根据用户指南、当 RTC 与 CPU 异步时、应进行多数表决以确定计数器的正确读数。 然而、 正如 Jens-Michael Gross 在这里指出的、需要至少四个连续读数才能始终正常工作。 此外、必须假定 CPU 频率相对较高、足以在下一个 RTC 时钟到达之前运行全部四个读数。


另一种方法要简单得多，如下所示： 

u32 RTC_COUNTER (void)
｛
volatile u32 v1、v2；
V1 = RTCNT；
V2 = RTCNT；
而(1 < v2 - v1)｛
V1 = v2；
V2 = RTCNT；
｝
返回 v2；
｝

也就是说、连续读取、直至发现其中一个值等于或大于前一个值、然后将其返回。

这是可靠的吗？ 或者、v1和 v2是否有可能遇到相同的竞争条件、导致相同的 v1和 v2、同时两者都不正确(我认为这也与多数票决算法相关)？

谢谢！

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

    您好、Wenhao、

    首先、我需要提醒您、不建议在新设计中使用 MSP430F5438。 它已被具有相同功能和引脚的 MSP430F5438A 所取代。

    现在来谈谈您的问题。 正如 Jens-Michael Gross 所说的"如果您在计数器更新过程中读取寄存器、寄存器中可能会出现任何值(在数字到数字翻转时出现竞争状态)。" 这意味着、当您首次通过读取 RTCNT 填充 v1和 v2时、您可能会"错误"读取符合您的标准(1 < v2 - v1)但该值不正确的值。

    此外、如果在日历模式中使用 RTC、 《MSP430x5xx 和 MSP430x6xx 系列用户指南》的22.2.2.3节 介绍了正确读取寄存器的其他方法。 但是、从我收集的内容来看、您在计数器模式下使用 RTC 的情况是什么？

    此致、
    Caleb Overbay

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

    您好 Caleb、

    是的、我们在计数器模式下使用 RTC。

    但是、假设 CPU 的时钟比 RTC 快得多、同时与计数器硬件中的转换速度相比、它足够慢、在 v1中的大多数情况下、v2可能会遇到转换：

    • 如果 v1命中、则 v2正确、并且返回 v2始终合适；
    • 如果 v2命中、则 v1正确、如果条件符合、v2要么与 v1相同(就像 v2在转换前命中一样)、要么大于 v1 (就像 v2在转换后命中)、两者都是合适的。

    我错过了什么吗？ 谢谢你。

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

    您的逻辑似乎正确。 我相信您在上面详细介绍的方法应该会为您提供正确的结果。 出于好奇、您以多快的速度运行 CPU 和 RTC？

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

    您好 Caleb、

    我们以32768Hz 的频率运行 RTC、以几 MHz 的频率运行 CPU。

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

    与32kHz RTC 相比、您的 CPU 以几 MHz 的频率运行、您有足够的时间获取4个 RTCNT 读数以获得多数票决、如您参考帖子中描述的 Jens-Michael Gross。 当使用上面描述的方法、CPU 的运行速度比 RTC 源快得多时、v2和 v1可能会在 RTCNT 被更新时出现不正确的读数。 当 CPU 和 RTC 源的频率更接近时、上述方法最有效。

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

    您好 Caleb、

    [引用 user="Caleb Overbay"] CPU 的运行速度比 RTC 源快得多，v2和 v1可能读数不正确[/quot]

    在我看来、决定 RTC 计数器读取频率的 CPU 速度应与 RTC 计数器硬件的转换速度进行比较、后者应由 RTC 时钟的上升沿驱动。 因此、转换速度应该非常高并且接近固定(即使不受时钟边沿斜率的影响、更不用说时钟频率)。 无论如何、多数票决算法也会受到" v2和 v1都不正确"的影响、正如我在第一篇文章中提到的。

    [引用 USER="Caleb Overbay">]当 CPU 和 RTC 源的频率更接近时、上述方法最有效。 [/报价]

    相反，我的建议的唯一致命缺点是，它不能处理你刚才提到的情况。 当 CPU 运行速度不够快时、v2甚至在正常情况下也可以比 v1大两个或更多、这会导致 while 循环无结束。

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

    这是一个非常有趣的主题。 我一直在思考你的方法、它基本上就是 Jens-Michael Gross 描述的方法。 您将继续读取、直至获得两个相同的连续读数。 很难获得两个与初始读取相同的错误读数。 我认为您的算法应该适用于此应用。 如果我造成任何混淆、我深表歉意。 与同行一起回顾这些内容总是很好的！

    此外、正确的是、如果 MCLK 太慢、算法将失败。

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

    您好 Caleb、

    [引用 user="Caleb Overbay"]基本上是 Jens-Michael Gross 所描述的方法。

    我完全同意你的意见。

    [引用 user="Caleb Overbay"]在初始读取中，您很难获得两个完全相同的错误读数。

    首先、您能更详细地解释一下这种说法吗？ 对我来说不是很清楚，特别是首字母(抱歉，英语不是我的母语)。 其次、CPU 以数十 MHz 的频率运行、我希望这是"不可能"的、而不仅仅是"极不可能"的。 :-)

    [引用 user="Caleb Overbay"]如果我造成了任何混乱，我深表歉意。 与同行一起回顾这些内容总是很好的！ [/报价]

    非常感谢您的帮助。 这就是我第一次来这里的原因！

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

    我在汇编器中做了大部分工作、并将推荐以下方法(在这里、作为一个宏-更快)。 请记住、这个宏只适用于计数器模式："XT"注释表示 MCU 时钟周期的数量。


    //最短总持续时间：15个 MCU 周期
    //最长总持续时间：18个 MCU 周期
    M_RTC_READCNT 宏
        本地 locExit
        MOV &RTCNT12、R14 //第一次读取计数器低字
        MOV &RTCNT34、R13 // 3T 读取计数器高字
        MOV &RTCNT12、R12 //第三次读取计数器低字。
        CMP R12、R14       // 1T 低字的两个读数是相同的？
        Jeq locExit       // 2t 如果是：一切正常- R12和 R13已经保持正确的值
        MOV &RTCNT34、R13 // 3T 如果发生更改，则 RTCNT34的第一次读数可能不正确。
    LocExit (退出)：
        ENDM

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

    不。 您的代码只能处理同步情况。 当事情是异步的时、即使读取一个字节(例如 RTCNT1)也会给您带来不可预知的结果。

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

    acccess 是异步的、但不是计数器本身。 由于它还可以处理高达25MHz 的时钟输入、其内部总转换时间必须小于1/25MHz=40ns -您已经声明您在计数器模式下使用 RTC 模块、因此没有额外的计算工作、就像在日历模式下那样。

    单次读取需要3个 MCLK 周期、即使 MCLK = 25MHz、也意味着120ns。 因此、最坏的情况是、当计数器位恰好翻转时、读取访问恰好在该转换周期内。 通过两次读取 RTCNT12和其间的 RTCNT34来解决这个情况。 如果两个 RTCNT12读数导致相同的输出、则没有转换、并且 RTCNT34读数也正常-那么 R12和 R13保持正确的值、我们完成了。
    如果 RTCTN12读数不相同、那么转换可能发生在第1次或第2次 RTCNT12访问内。 这需要至少一个 RTCNT34的额外读取、因为不清楚是否发生了从 RTCNT12到 RTCNT34的翻转。 也许还应该添加 RTCNT12的另一个读数、但就是这样。 然后、这个版本将允许一个低至1：21的 RTC/MCLK 时钟比率