Як часто я повинен запитувати RTC?

11

Я ще не використовував RTC, тому я не повністю впевнений у "нормальному" способі читання годинника в режимі реального часу. Є кілька різних підходів, про які я придумав, але сподівався на поради з цього приводу.

Ось способи, які я думав читати та використовувати час до цього часу:

Увімкніть дату та час живлення та збережіть в оперативній пам'яті, а потім за допомогою використання таймера переривання збільшуйте значення оперативної пам’яті щосекунди тощо. Код потім використовуватиме значення в оперативній пам’яті всякий раз, коли потрібно знати дату / час.
За допомогою переривання таймера запитуйте RTC щосекунди та копіюйте отриману дату та час у оперативну пам'ять. Знову ж таки, код використовував би значення в оперативній пам’яті всякий раз, коли потрібно знати дату / час.
Кожен раз, коли мені потрібно дізнатися час, запитати RTC і безпосередньо використовувати його відповідь.

Який був би найкращий підхід?

microcontroller rtc

— user9993
джерело

15

Найкращий підхід - це той, який відповідає вашим характеристикам при використанні мінімальної кількості ресурсів. Оскільки ми насправді не знаємо ваших потреб, "кращий" має для нас дуже мало значення.

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

Усі дуже хороші відповіді, я не можу вибрати відповідь!

— user9993

23

Я використовував би четвертий варіант.

Більшість мікросхем RTC мають можливість вивести імпульс на 1 секунду. Ви повинні підключити цей імпульс до ввімкненого переривання ввімкненого MCU.

Ви отримуєте час з чіпа один раз на початку вашої програми, а може періодично з цього моменту - можливо, раз на годину.
Потім сигнал переривання запускає процедуру переривання в MCU, в якій ви збільшуєте час на одну секунду.

Таке розташування дає точність до другої частини RTC без накладних витрат на активне зчитування RTC.

— Маєнко
джерело

5

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

— supercat

Або переконайтеся, що читання викликає лише ISR - у вас з’являється розрив на одну секунду, щоб зробити зчитування до початку наступного ISR.

— Маєнко

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

— supercat

... верхній 32 біт або нижній 31 плюс стан введення годинника мають сигнал тривоги, який може бути увімкнено і вимкнено в будь-який час без затримки синхронізації, і регістр тривоги, який може бути записаний у будь-який час, коли сигнал тривоги вимкнено, з семантикою того, що тривога виникає, якщо збільшується, коли сигнал увімкнено . Якщо мікросхема може приймати асинхронні відключення, а програмне забезпечення проводить подвійну перевірку опитування, коли це доречно, ніякої іншої апаратної синхронізації не потрібно, і програмному забезпеченню не доведеться вирішувати проблеми, викликані іншими формами апаратної синхронізації.

— supercat

9

3-й та 2-й більш життєздатні.

Третій підхід - це те, що я використовую в більшості випадків. Користь полягає в тому, що мені не потрібно турбуватися про дзеркальне відображення RTC в оперативній пам'яті. Потенційний недолік полягає в тому, що при допиті RTC через послідовну шину вводиться затримка. Якщо ви пишете дані раз на секунду, ця затримка, ймовірно, не матиме значення.

2-й підхід теж хороший. Підтримка дзеркального годинника може призвести до помилки збереження часу, якщо пристрій працює тривалий час. Дзеркальний годинник може відхилятися від RTC. Якщо ви читаєте RTC регулярно, то дрейф не накопичуватиметься.
Однак я б радив не здійснювати послідовне спілкування в режимі обслуговування переривань (ISR). Встановіть прапор у ISR та виконайте послідовну комунікацію в main ().

ps У всіх випадках я використовував DS1307.

— Нік Алексєєв
джерело

6

Деякі RTC (наприклад, MC68HC68T1 [який, мабуть, майже ніхто більше не повинен використовувати]) призупинять свій внутрішній підрахунок під час читання, щоб дати послідовну відповідь. Їх потрібно читати якомога рідше , щоб мінімізувати порушення. Прочитайте з них один раз, а потім скористайтеся тимчасовими перервами для оновлення значення часу, що зберігається в оперативній пам'яті MCU.

— Ігнасіо Васкес-Абрамс
джерело

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

— supercat

2

Мабуть, подвійне буферизація - це те, про що люди не думають, коли розробляють свої фішки.

— Ігнасіо Васкес-Абрамс

Якщо код перевіряє при опитуванні, щоб переконатися, що значення не змінилося, немає необхідності в подвійному буферизації. Для цільового годинника в режимі реального часу таке опитування, яке повторюється до зміни, буде працювати навіть у тому випадку, якщо перерва намагається прочитати RTC одночасно з кодом основного рядка. Деякі конструкції з подвійним буфером ускладнюють написання основного коду та коду переривання, які можуть безпечно співіснувати, і я ніколи не бачив такого, який би насправді вважав би "корисним".

— supercat

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 (5184000) циклів за 24 години між послідовними опівночі. Щоб це було корисно, потрібно витратити цілі 24 години, оскільки 60 Гц можуть переносити між півночі.

Ще однією чудовою орієнтацією на час було б використання GPS (точність 10 нс), якщо у вашому проекті вже було обладнання GPS.

Якщо замість того, що ваш RTC час надходить із зовнішнього джерела, наприклад, часу стільникової мережі (AT + CCLK? Виклик) або мережевого сервера часу з використанням NTP, ви можете використовувати значення RTC так, як "налаштування" не буде нічого. .

— tcrosley
джерело