我应该多久查询一次RTC?


11

我尚未使用RTC,因此我不太确定读取实时时钟的“正常”方式。我曾想过几种不同的方法,但希望对此有所建议。

到目前为止,以下是我想到的阅读和使用时间的方法:

  1. 获取开机时的日期和时间并保存到RAM,然后通过使用计时器中断每秒增加RAM值等。然后,只要需要知道日期/时间,代码就会使用RAM中的值。
  2. 通过使用计时器中断,每秒查询RTC并将接收到的日期和时间复制到RAM。同样,该代码将在需要知道日期/时间时使用RAM中的值。
  3. 每当我需要找出时间时,查询RTC并直接使用它的响应。

哪种方法最好?


15
最好的方法是在使用最少资源的同时满足您的规范。由于我们并不真正了解您的需求,因此“最佳”对我们而言意义不大。
Scott Seidman

所有非常好的答案我无法选择答案!
user9993 2015年

Answers:


23

我将使用第四个选项。

大多数RTC芯片都可以选择输出1秒脉冲。您应该将该脉冲连接到MCU上的允许中断的输入。

  • 您可以在程序开始时从芯片中获取时间,有时甚至从那时开始-每小时一次。
  • 然后,该中断信号触发您的MCU中的中断例程,在该例程中,您将时间增加一秒。

这种安排使您可以精确 RTC的秒数,而无需主动读取RTC的开销。


5
使用这种方法时,重要的是要知道哪个时钟沿代表一个增量,并确保应该放弃在该时钟沿期间进行的任何读数。
超级猫

或确保读数仅由ISR触发-在触发下一个ISR之前,您有一秒钟的时间来进行读数。
Majenko

如果可以将RTC分辨率设置得足够好以满足事件计时的需要,我更愿意将实时时钟设置为每秒运行超过1个滴答声,并将其用于通用事件计时。因此,可能并非总是在每个RTC滴答中都发生中断。此外,在设置警报时,准确知道设置警报时的RTC时间通常很重要,并轮询RTC以查看在设置警报时它是否移动了。我不知道为什么32位芯片供应商不仅仅​​提供具有读取功能的47位计数器...
超级猫

...高32位或低31位加上时钟输入状态,具有可以随时打开和关闭而没有同步延迟的警报,以及可以在发生警报时随时写入的警报寄存器off(关闭),从语义上讲,如果在启用警报时发生增量,则会发生警报。如果芯片可以接受异步唤醒,并且软件在适当的时候进行了双重检查轮询,则不需要其他硬件同步,并且软件也不必解决由其他形式的硬件同步引起的问题。
超级猫

9

第三和第二更可行。

在大多数情况下,我会使用第三种方法。这样做的好处是,我不必担心在RAM中镜像RTC。潜在的缺点是通过串行总线查询RTC会导致延迟。如果您每秒写入一次数据,则此延迟可能无关紧要。

第二种方法也很好。如果设备长时间运行,则维护镜像时钟可能会导致计时错误。镜像时钟可能与RTC偏离。如果您定期阅读RTC,则漂移不会累积。
但是,我建议不要在中断服务程序(ISR)本身中进行串行通信。在ISR中设置一个标志,并在main()中进行串行通信。

ps 在所有情况下,我都使用DS1307。


6

某些RTC(例如MC68HC68T1 [承认几乎没有人可以再使用])将在读取时暂停其内部计数,以提供一致的响应。必须尽可能少地阅读它们,以最大程度地减少干扰。从它们读取一次,然后使用定时器中断来更新存储在MCU RAM中的时间值。


这样的设计使人为难。在增量产生随机读取的情况下,将很容易解决问题。读取导致计数丢失是一个无法解决的问题,除非接受丢失的计数。
超级猫

2
显然,双缓冲是有些人在设计芯片时不会想到的东西。
伊格纳西奥·巴斯克斯

如果代码在轮询时检查以确保值未更改,则无需双重缓冲。对于片上实时时钟,即使中断试图在与主线代码同时读取RTC的情况下,这种重复直到更改的轮询仍然有效。一些双缓冲设计使编写可以安全地共存的主线和中断代码变得很困难,而且我从未见过我真正认为“有帮助”的代码。
超级猫

5

我将假设RTC是具有自己晶体的独立芯片,或者是与您的微控制器集成的模块,该模块又具有与主时钟不同的时间源(例如32 kHz晶体)。RTC的时间源比微控制器的时间源更准确。

为了确定需要多长时间读取一次RTC,需要弄清楚主时钟可能出现的最大误差。例如,如果将主晶体指定为20 ppm,则等于0.002%。因此,仅基于主时钟源的时钟每天可能会漂移0.00002 * 3600 * 24 = 1.728秒。

因此,如果您每天仅读取RTC两次,并且在两次之间使用计时器中断增加时间,那么您永远不会离开一秒钟以上-与RTC相比,永远不会超过一秒钟。

正如我之前假设的那样,如果您的RTC是具有自己晶体的独立芯片,或者是与您的微控制器集成的模块,那并不意味着它是正确的。RTC也可能有错误。例如,如果使用公差为5 ppm的32 kHz晶体(比10 ppm的晶体稍贵),则每天可能会偏离0.43秒,也可能每月偏离13秒。

为了解决这个问题,您需要调整RTC,在其中将校正因子写回到寄存器中。这样做将使您几乎将错误降至零。但是,当然,在进行调整时,您将必须有第三个外部时钟源作为参考。在美国一个极其精确的参考是60Hz的AC线,这是保证恰好在连续午夜之间的24小时期间60 * 60 * 60 * 24(5184000)周期。为了使此功能有用,您必须在整个24小时内计时,因为60 Hz可能会在午夜之间漂移一些。

如果一个人的项目中已经装有GPS硬件,那么另一个出色的时间基准将是使用GPS(精度为10 ns)。

如果相反,您的RTC时间来自外部来源,例如蜂窝网络时间(AT + CCLK?呼叫)或使用NTP的网络时间服务器,那么您可以按原样使用RTC值,因为没有任何可“调整”的内容。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.