Как часто я должен запрашивать RTC?

11

Я еще не использовал RTC, поэтому я не совсем уверен в «нормальном» способе чтения часов реального времени. Есть несколько разных подходов, о которых я думал, но надеялся на некоторые советы по этому поводу.

Вот способы, которыми я думал о чтении и использовании времени до сих пор:

Получите дату и время при включении питания и сохраните его в ОЗУ, а затем с помощью прерывания по таймеру увеличивайте значения ОЗУ каждую секунду и т. Д. Код будет затем использовать значения в ОЗУ всякий раз, когда ему потребуется знать дату / время.
Используя прерывание по таймеру, каждую секунду запрашивайте RTC и копируйте полученные дату и время в RAM. Опять же, код будет использовать значения в ОЗУ всякий раз, когда ему нужно знать дату / время.
Каждый раз, когда мне нужно узнать время, запросить RTC и использовать его ответ напрямую.

Какой будет лучший подход?

microcontroller rtc

— user9993
источник

15

Наилучшим подходом является тот, который соответствует вашим требованиям при использовании минимального количества ресурсов. Поскольку мы на самом деле не знаем ваших потребностей, «лучшее» имеет для нас очень мало значения.

— Скотт Сейдман

Все очень хорошие ответы, я не могу выбрать ответ!

— user9993

23

Я бы использовал четвертый вариант.

У большинства микросхем RTC есть возможность вывести 1-секундный импульс. Вы должны подключить этот импульс к входу с поддержкой прерываний на MCU.

Вы получаете время от чипа один раз в начале вашей программы, а может, иногда, с тех пор - возможно, один раз в час.
Затем сигнал прерывания запускает процедуру прерывания в MCU, в которой вы увеличиваете время на одну секунду.

Эта схема дает вам точность второго RTC без лишних затрат на активное чтение RTC.

— Majenko
источник

5

При использовании этого подхода важно знать, какое значение тактового фронта представляет приращение, а также гарантировать, что любое чтение, которое выполняется в течение этого временного фронта, должно быть прекращено.

— суперкат

Или убедитесь, что чтение инициируется только ISR - у вас есть интервал в одну секунду для чтения до того, как будет запущен следующий ISR.

— Маженко

Когда бы ни было возможно, я предпочитаю устанавливать часы реального времени, чтобы они работали быстрее, чем один тик в секунду, и использовать их для синхронизации событий общего назначения, если разрешение RTC можно установить достаточно точно, чтобы соответствовать потребностям синхронизации событий; таким образом, не всегда может быть прерывание, возникающее на каждом такте RTC. Кроме того, при настройке будильника часто важно точно знать, какое время RTC находится в момент установки будильника, и опросить RTC, чтобы узнать, сместилось ли оно во время установки будильника. Я не знаю, почему производители 32-битных чипов не просто предлагают 47-битный счетчик с возможностью чтения ...

— суперкат

... верхние 32 бита или нижние 31 плюс состояние входа часов имеют сигнал тревоги, который можно включать и выключать в любое время без задержки синхронизации, и регистр сигналов тревоги, который может записываться в любое время, когда сигнал тревоги off, с семантикой, что сигнал тревоги возникает, если приращение происходит, когда сигнал тревоги включен . Если микросхема может принимать асинхронные пробуждения, а программное обеспечение дважды проверяет опрос, когда это необходимо, никакой другой аппаратной синхронизации не требуется, и программному обеспечению не придется обходить проблемы, вызванные другими формами аппаратной синхронизации.

— суперкат

9

3 и 2 более жизнеспособны.

Третий подход - это то, что я использую в большинстве случаев. Это преимущество в том, что мне не нужно беспокоиться о зеркалировании RTC в оперативной памяти. Потенциальным недостатком является то, что опрос RTC через последовательную шину вносит задержку. Если вы пишете данные раз в секунду, эта задержка, вероятно, не будет иметь значения.

Второй подход тоже хорошо. Обслуживание зеркальных часов может привести к ошибке хронометража, если устройство работает в течение длительного времени. Зеркальные часы могут отличаться от RTC. Если вы регулярно читаете RTC, то дрейф не будет накапливаться.
Однако я бы посоветовал не делать последовательную связь в самой программе обработки прерываний (ISR). Установите флаг в ISR и выполните последовательную связь в main ().

ps Во всех случаях я использовал DS1307.

— Ник Алексеев
источник

6

Некоторые RTC (например, MC68HC68T1 [который, по общему признанию, почти никто не должен больше использовать)) приостанавливают свой внутренний счет при чтении, чтобы дать последовательный ответ. Их следует читать как можно реже, чтобы минимизировать сбои. Прочитайте их один раз, а затем используйте прерывания таймера для обновления значения времени, хранящегося в ОЗУ MCU.

— Игнасио Васкес-Абрамс
источник

Такие конструкции поражают воображение. Чтение, которое происходит во время приращения, приводит к случайным данным, что будет легко обойти. Чтение пропущенных счетчиков - это проблема, которую нельзя обойти, если только не принять потерянные счетчики.

— суперкат

2

Очевидно, что двойная буферизация - это то, о чем некоторые люди не думают, когда проектируют свои чипы.

— Игнасио Васкес-Абрамс

Если при опросе выполняется проверка кода, чтобы убедиться, что значение не изменилось, двойная буферизация не требуется. Для встроенных часов реального времени такой опрос с повторением до изменения не будет работать, даже если прерывание пытается прочитать RTC в то же время, что и основной код. Некоторые конструкции с двойной буферизацией затрудняют написание основного кода и кода прерывания, которые могут безопасно сосуществовать, и я никогда не видел такого, который бы я действительно считал «полезным».

— суперкат

5

Я предполагаю, что RTC - это либо отдельный чип с собственным кристаллом, либо модуль, интегрированный с вашим микроконтроллером, который снова имеет отдельный источник времени (например, кристалл 32 кГц), чем основные часы. И источник времени для RTC является более точным, чем источник для микроконтроллера.

Чтобы определить, как часто вам нужно читать RTC, вам нужно выяснить, какую максимальную ошибку могут иметь ваши основные часы. Например, если основной кристалл определен в концентрации 20 частей на миллион, это равно 0,002%. Таким образом, часы, основанные только на основном источнике часов, могут отклоняться от 0,00002 * 3600 * 24 = 1,728 секунды в день.

Таким образом, если вы читаете RTC только два раза в день, а между тем увеличиваете время раз в секунду, используя прерывание по таймеру, вы никогда не будете выключены более чем на секунду - никогда не будете выключены более чем на секунду по сравнению с RTC, которое есть.

Если, как я предполагал ранее, ваш RTC - это либо отдельный чип с собственным кристаллом, либо модуль, интегрированный с вашим микроконтроллером, это не значит, что он правильный. RTC тоже может иметь ошибку. Например, если он использует кристалл 32 кГц с допуском 5 промилле (который чуть дороже, чем 10 промилле), он может быть отключен на 0,43 секунды в день или 13 секунд в месяц.

Чтобы обойти это, вам нужно будет настроить RTC, где вы записываете поправочный коэффициент обратно в регистр. Это позволит вам свести ошибку практически к нулю. Но, конечно, вам понадобится третий внешний источник синхронизации, который будет использоваться в качестве эталона при настройке. Чрезвычайно точным эталоном в США является линия переменного тока с частотой 60 Гц, которая гарантированно будет составлять ровно 60 * 60 * 60 * 24 (5 184 000) циклов в течение 24 часов между последовательными ночами. Чтобы это было полезно, вы должны рассчитывать на все 24 часа, так как 60 Гц может дрейфовать между ночами.

Еще одна отличная временная привязка - использование GPS (с точностью до 10 нс), если в его проекте уже есть оборудование GPS.

Если вместо этого ваше время RTC поступает из внешнего источника, такого как время сотовой сети (вызов AT + CCLK?) Или сервер времени сети, использующий NTP, то вы можете использовать значение RTC как есть, поскольку «настраивать» будет нечего ,

— tcrosley
источник