[参考译文] MSP430F6779：有关 RTCRDY 时间的问题

感谢您的提问、

指定的 MSP 团队成员将很快帮助您解决此问题。

你(们)好

我还有其他问题。

RTCHOLD 停止更新 RTC 的计数器、但是当 RTCHOLD 从0更改为1或1更改为0时、HTCRDY 是否改变？

当 RTCRDY 为0时、写入 RTCHOLD 是否不会导致问题？
(写入和读取、后续操作等)

当 RTCRDY 为0时、RTCHOLD 设置为1时 RTCRDY 是否发生变化？

当我想使用 RTCRDY 进行安全读取时、在 RTCRDY 从0更改为1后读取是否需要延迟？

此致、
da

您好 Da、

[引用 user="da"]询问有关 HTCRDY 时间的问题。

我不熟悉 HTCRDY。 我假设您是指 RTCRDY。

[引用 user="da]RTCRDY 在保留窗口期间变为低电平。
在手册中、保留窗口的时间为128/32768。
由于时钟为32768Hz、因此需要3.9ms。 此计算是否正确？[/quot]

我假设您使用的是日历模式。 您的计算似乎正确。

[引用 user="da">实际上、第一次测量为3.9ms、然后每秒可测量7.8ms。
有两种类型的时间、这是正确的吗？

用户指南确实提到了它是一个大约128/32768的保留窗口。 这可能会因描述的不同而有所不同。 结果是否每秒正确更新？ 请注意、请遵循推荐的实时 时钟寄存器读取方法。

此致、

James

>我不熟悉 HTCRDY。 我假设您是指 RTCRDY。

是的、这是 RTCRDY 的错误。

>用户指南确实提到了它是一个大约128/32768的保留窗口。
这可能会因描述的不同而有所不同。 结果是否正确更新
每秒？ 请注意、请遵循推荐的读数方法
实时时钟寄存器。

我很久没测量过、但是 RTC 运行正常。

执行一个程序、在 RTCRDY 为低电平时将 GPIO 设置为高电平。

第一个

第二次及后续时间

请回答以下问题。

RTCHOLD 停止更新 RTC 的计数器、但是当 RTCHOLD 从0更改为1或1更改为0时、HTCRDY 是否改变？

2.当 RTCRDY 为0时、写入 RTCHOLD 是否不会导致问题？
  (写入和读取、后续操作等)

3.当 RTCRDY 为0时、当 RTCHOLD 设置为1时、RTCRDY 是否发生变化？

当我想使用 RTCRDY 进行安全读取时、在 RTCRDY 从0更改为1后读取是否需要延迟？

此致、
da

[引用 user="da"]我长时间没有测量，但 RTC 工作正常。

听得好。

[引用 user="da"]

请回答以下问题。

RTCHOLD 停止更新 RTC 的计数器、但是当 RTCHOLD 从0更改为1或1更改为0时、HTCRDY 是否改变？

2.当 RTCRDY 为0时、写入 RTCHOLD 是否不会导致问题？
  (写入和读取、后续操作等)

3.当 RTCRDY 为0时、当 RTCHOLD 设置为1时、RTCRDY 是否发生变化？

[/报价]

设置 RTCHOLD 会暂停计数器并清除 RTCRDYIFG、即使它由 RTCRDY 置位也是如此。 将 RTCHOLD (1至0)复位、然后允许 RTCRDYIFG 由 RTCRDY 置位。 用户指南中的图24-1对此进行了说明。 RTCRDY 是否置1无关紧要、因为您希望在 RTCRDYIFG 置1时读取 RTC 寄存器。

[引用 user="da"]当我想使用 RTCRDY 执行安全读取操作时，在 RTCRDY 从0更改为1后读取是否需要延迟？

根据 用户指南中的第24.2.5节、"中断是根据 RTCRDY 位的上升沿生成的、导致 RTCRDYIFG 被置位。 此时、应用程序几乎有一秒钟的时间来安全地读取任何或所有实时时钟寄存器"。

MSP430F6779：我对 RTC 有疑问。

此致、

James

您好！

您能否单独就以下事项向我们提供意见？

RTCHOLD 停止更新 RTC 的计数器、但是当 RTCHOLD 从0更改为1或1更改为0时、HTCRDY 是否改变？

2.当 RTCRDY 为0时、写入 RTCHOLD 是否不会导致问题？
  (写入和读取、后续操作等)

3.当 RTCRDY 为0时、当 RTCHOLD 设置为1时、RTCRDY 是否发生变化？

当我读取 RTC 数据时、我了解建议由执行此操作
中断或检查并读取 RTCRDYIFG？
因此、设置 RTC 并可靠地读取它需要一秒钟的时间。

我询问了一个有关加载的问题、
更新 RTC 时间时发生错误。
将5：00：00写入4：59：59会得到5：59：59。
读取或写入可能有问题。

是否有推荐的方法来写入工作中的 RTC？

此外、我们现在经常更新 RTC。
我们更新 RTC 的频率如何？

此致、
da

您好！

[引用 user="da"]

您能否单独就以下事项向我们提供意见？

RTCHOLD 停止更新 RTC 的计数器、但是当 RTCHOLD 从0更改为1或1更改为0时、HTCRDY 是否改变？

2.当 RTCRDY 为0时、写入 RTCHOLD 是否不会导致问题？
  (写入和读取、后续操作等)

3.当 RTCRDY 为0时、当 RTCHOLD 设置为1时、RTCRDY 是否发生变化？

[/报价]

您是否在我之前的帖子中阅读过我的评论？ 我已经在那里回答了这些问题。

[引用 user="da"]

我询问了一个有关加载的问题、
更新 RTC 时间时发生错误。
将5：00：00写入4：59：59会得到5：59：59。
读取或写入可能有问题。

是否有推荐的方法来写入工作中的 RTC？

[/报价]

您可以在用户指南的第24.2.2和24.2.5节中了解如何读取或写入 RTC 寄存器。  为了可靠地更新到所有日历模式寄存器、在写入任一日历或预分频寄存器(RTCPS0、RTCPS1、RTCSEC、RTCMIN、RTCHOUR、 RTCDAY、RTCDOW、RTCMON 和 RTCYEAR)。

[引用 user="da">此外，我们现在经常更新 RTC。
我们更新 RTC 的频率如何？[/报价]

这取决于您需要为应用更新 RTC 的频率。 它还可能取决于第24.2.8节中讨论的温度补偿要求。 我建议尽量少给 RTC 写信、以防止时间发生变化。

此致、

James

您好！

>您是否在我之前的帖子中阅读了我的评论？ 我已经在那里回答了这些问题。

我重新读取它、但我不知道它是否是相应的答案。

上一帖子是否是下一个组合？
我的问题不是关于 RTCRDYIFG、而是关于 RTCRDY 的操作。
RTCRDY 是否不能用作 RTC 操作的参考？

此外、我检查了 RTCHOLD 和 RTCRDYIFG 的运行。
在答案中、当 RTCHOLD 被设定为0时、RTCRDYIFG 也变为0。
然而、当 RTCRDYIFG 为1时、即使 RTCHOLD 为1、RTCRDYIFG 也不会变为0。
(请参阅下图)

> 1. RTCHOLD 停止更新 RTC 的计数器、但是当 RTCHOLD 从0更改为1或1更改为0时、HTCRDY 是否改变？

=>设置 RTCHOLD 会暂停计数器并清除 RTCRDYIFG、即使它由 RTCRDY 置位。

> 2. 当 RTCRDY 为0时、写入 RTCHOLD 是否不会导致问题？
>(写入和读取、后续操作等)

=>复位 RTCHOLD (1至0)、然后允许 RTCRDYIFG 由 RTCRDY 置位。
用户指南中的图24-1对此进行了说明。

> 3. 当 RTCRDY 为0时、RTCHOLD 设置为1时 RTCRDY 是否发生变化？

=> RTCRDY 是否被置位无关紧要、这是因为当 RTCRDYIFG 被置位时、你想要读取 RTC 寄存器。

>我建议尽可能少地向 RTC 写入数据、以防止时间变化。

现在每一分钟都有问题吗？

RTCHOLD 被置位、执行并且停止时、RTCHOLD 和 RTCRDYIFG

此致、
da

我还有其他问题。

目前、在更新 RTC 时、RTCSEC 和 RTCMIN 不会改变。

更新时、在更新前检查 RTCRDY 并置位 RTCHOLD。
尽管概率很低、RTCSEC 和 RTCMIN 的值将是更新后值的之前值。

添加问题

目前、我们只能确认 RTCSEC 和 RTCMIN 的重新写入失败。
其他 RTC 寄存器 RTCHOUR 和 RTCMON 是否可能无法重写？

添加问题

目前，按年、月、二、周中某天的顺序重写 RTCSEC、RTCMIN 的重写失败。
月份或日期的重写是否可能失败？
书面顺序
1.年->好的
2.月->年
3.第->天-> NG
4.小时->好
5分钟->好的
6.第二->好的

此致、
da

根据 用户指南第24.2.2节中的注释、"为了可靠地更新所有日历模式寄存器、在写入任何日历或预分频寄存器(RTCPS0、RTCPS1、RTCSEC、RTCMIN、RTCHOUR、 RTCDAY、RTCDOW、RTCMON 和 RTCYEAR)"。

写入 RTCSEC、RTCMIN、RTCHOUR、RTCDAY、RTCDOW、 RTCYEARH、RTCYEARL、RTCAMIN、RTCAHOUR、RTCADAY、 和 RTCADOW 寄存器可能会导致不可预知的行为。

我怀疑您在写入 RTCSEC 和 RTCMIN 寄存器后正在读取它们、因此请确保您遵循《用户指南》中解释的有关读取 RTCSEC 和 RTCMIN 寄存器的指南。

此致、

James