14

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

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

Чи є якась основна причина цього?

Чи є якісь мікропроцесорні програми, які роблять щось складніше, ніж просто показувати годинник, у якому формат BCD корисніший, ніж двійковий, або де формат року-місяця-дня-години-секунди був би кориснішим, ніж прямий 47-бітний підрахунок зміни стану генератора?

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

rtc

— суперкат
джерело

2

Я не знаю відповіді, але мені цікаво, чи є кореляція BCD з 7-сегментним декодером ?

— Професор М'яв Мев

@Prof. Meow Meow: приємне ім’я. Найбільш практичним методом зберігання номерів, які будуть відображатися в апаратному забезпеченні, є BCD. Є системи, які зберігають номери, які відображаються в інших форматах, але у багатьох випадках вони просто використовували ПЗУ для відображення прямо з числа на його візуальне зображення (наприклад, аркадна машина "Tank" використовувала 6-бітні лічильники балів та 512 байт ROM для перетворення кожного значення балів у форму 8x8), але це, як правило, працювало лише тоді, коли максимальне числове значення було досить малим.

— supercat

12

Чи всі RTC використовують кодування BCD?

RTC від Philips / NXP (як окремі, так і інтегровані в мікросхеми ARM7 або Cortex-M3) не використовують кодування BCD.

Що не так з BTC RTC?

У порівнянні з плоским лічильником, єдині операції, які складніше з розділеним тактовою частотою BCD, - це обчислення різниці у часі (додавання секунд або обчислення минулого часу). Порівняння часу на кшталт: "поточний час більший за час тривоги, встановлений користувачем" так само простий.

Що приємного в BTC (і взагалі розділених) RTC?

Розбиття полів дуже приємно, коли ви дбаєте про дату календаря. У людських календарях є кумедні речі, такі як місяці різної тривалості та понад ці високосні роки. Спробуйте це зробити за один лічильник (ви можете отримати бонусний бал за використання майже ніякої сили). Ну, і спробуйте підтримувати тижневі дні (досить корисні для всіх видів пристроїв, призначених для людей: від будильників до контролерів нагрівача).

Підхід BCD має ще одну додаткову особливість: ви отримуєте перерви "щосекунди" або "кожні десять секунд" безкоштовно, не роблячи жодних обчислень за часом та датами.

Для обчислення високосного року рекорду в RX-і NXP трохи не вистачає, оскільки він піклується про ділиться на 4 правило і не перевіряє поділ на 100 і 400. Якби він зберігав лічильник року в BCD, це було б тривіально і, швидше за все, зроблено правильно.

Підсумок

Якщо ви хочете монотонний годинник, тоді використовуйте його. Ви можете придбати PIC або AVR за допомогою "лічильника RTC" (це просто асинхронний лічильник з автономним осцилятором 32 кГц). Тільки майте на увазі, що просто відобразити дату буде складно. :)
Коли вам потрібно відобразити час і дату та встановити сигнали тривоги, грунтуючись на введенні користувачем часу та дати, використовуйте RTC. І пам’ятайте, що коли користувач змінює поточний час і дату, ваші переривання на основі RTC можуть бути неточними.

— jpc
джерело

1

Я щойно почав використовувати Gekko, який має 24-бітний RTC, і це майже те, що я хочу, за винятком того, що він не може тримати час, коли процесор мертвий. Я також дивився на ST Micro ARM, який має дурний модуль BCD RTC, який підтримує переривання лише на одну секунду. Якщо мікросхема ST ніколи не буде без живлення більше трьох років, я можу супроводжувати прекалери RTC для запуску з 32-кратною швидкістю, а потім використовувати програмні трюки для компенсації, отримуючи таким чином дозвіл на час пробудження 1/32 секунди, але Часи, що зберігаються в RTC, не мали б значущого відношення до календарного часу і ...

— supercat

1

... тому необхідність перетворення з нерозумного формату RTC на прискорення 1/32 секунди буде прикрою, тим більше, що таке перетворення буде потрібно для кожного циклу сну / пробудження. Мені здається, мені цікаво, скільки людей використовують зчитування RTCC, не перетворюючись на єдині секунди. Може бути, достатньо, щоб зробити формат YMDHMS вартим, але на мій погляд, набагато корисніше резервувати YMDHMS для вводу-виводу людини та використовувати прямі секунди (або будь-яку їх частину) для всього іншого.

— supercat

1

@jpc: Моя схильність насправді полягала б у тому, щоб ніколи не встановлювати час мікросхема RTC, а натомість зберігати "час з моменту встановлення батареї годин", а також зберігати різницю між цим та настінним часом. Я використовував такий підхід в одному поколінні продукту, який використовував окремий PIC для збереження резервного часу від батареї (час, коли цей PIC був лише для читання), і використовував би його на мікросхемі з прямим лічильником. Однак це здавалося дещо тужливою ідеєю, щоб RTC машини зберігав безглуздо значення, відформатоване датою, хоча, якщо я використовую мікросхему ST Micro, я можу просто зробити це.

— supercat

1

До речі, серія STM32F100 використовує 32-бітну секунду RTC (не BCD), але серія STM32F400 повертається до коду RTC, кодованого BCD. Зітхнути.

— Марк Лаката

1

@FedericoRusso: розділене поле має певний сенс, хоча це більш сприятливо, ніж перешкода, ніж допомога в більшості програм. Вибір BCD, однак, здається просто дивним, як вибір для комплектації з процесором , який не має підтримки BCD .

— supercat

3

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

— stevenvh
джерело

2

Як часто програма не хоче нічого робити з датою та часом, крім відображення її? Мені здається, що набагато частіше хотіти робити такі речі, як обчислити час, деяку відстань у майбутньому, або визначити, скільки часу минуло після якоїсь конкретної події тощо. Що простіше обчислити: дата та час 45 секунд після 28 лютого 2000 23:59:52 або 5097582 + 45 (остання величина, якщо вважати епоху опівночі 01 січня-2000)? Як щодо визначення того, чи минуло 5 хвилин між 28 лютого 2000 23:59 та 01 березня 2000 00:03 (проти 5097540.0 та 5184180.0)

— суперкарт

1

RTC з 48-бітовим лічильником на 65,536 долі секунди та модулем порівняння тривоги, який покривав нижній 24 біт або близько того, був би надзвичайно зручним для систем з низькою потужністю, оскільки він може бути використаний як основа для планування ОС незалежно від процесор прокидається і спить. Якщо щось сталося через 4 секунди, система могла б відзначити значення RTC, коли подія повинна відбутися. Якщо через 2 секунди процесор виявиться, що робити нічого, він може встановити сигнал RTC і перейти до сну. Коли подія повинна відбутися, система прокинеться.

— supercat

@supercat - для комп’ютерів загального призначення нехай ОС відстежує час і робить "корисні речі" з інформацією про цей час. RTC проводиться лише один раз для ініціалізації інформації про час ОС, а потім час оновлюється перериваннями. Але для багатьох простих вбудованих застосувань набагато ймовірніше

— Toybuilder

1

@Toybuilder: Останнє - це саме той підхід, який я в кінцевому підсумку використовував в останні кілька поколінь електронного блокування. Мої найбільші роздратування - це відсутність будь-якого вибору імпульсного виходу між 32 кГц і 16 ГГц (оскільки я не довіряв 1 М підтягуванню для надійної роботи з 32 кГц відкритого колекторного виходу, єдиним розумним вибором був 16 ГГц), і неохайність PIC таймерна схема.

— supercat

1

@FedericoRusso: Якщо у вас прямолінійний лічильник часу, не потрібно було б перетворювати назад на години, хвилини та секунди, за винятком, можливо, для читаного людиною відображення. Один просто додає 3723, і все. Під час роботи зі значеннями дати / часу YMD-HMS потрібен окремий код для збільшення та зменшення, літній час - це кошмар, для якого виробники чіпів, схоже, хочуть додавати розбиту підтримку [як команда, яка віднімає один від кількості годин, за винятком випадків, коли це нуль, в цьому випадку він нічого не робить]. DST - це також біль у бінарних, але не настільки жахливий.

— supercat

3

Я підозрюю кілька причин:

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

Застосування - якщо хтось використовує RTC від невеликого мікрофона (щось із 8-бітового діапазону, як, наприклад, PIC низького класу), то робота з великою кількістю (наприклад, вашим 47-бітовим лічильником) - це великий біль у шиї. З МОЖЛИМИ простіше розібратися з цифрами BCD, оскільки вам не доведеться працювати над розбиттям речей.

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

Можна уявити систему, де ви отримаєте окремі лічильники годин, хвилин та інше у двійковій формі замість BCD (таким чином, уникнути проблеми "розбиття 47-бітного числа"), але це не так вже й простіше, і ви збираєтеся робити деякі перетворення під час відображення речі.

— Майкл Коне
джерело

1

48-бітне число буде 32-бітним числом секунд і 16-бітовим дробом. Робота з 32-бітовими номерами на 8-бітовому мікрофоні не так вже й погана. Я можу собі уявити, що на чомусь схожій на 6502, який міг би обробляти упакований BCD, формат BCD в деяких випадках може заощадити кілька байтів, хоча додаткова складність обробки між секундами-хвилинами може компенсувати будь-яку перевагу. Але, безумовно, люди, які вбудували RTCC в AR мікросхеми ST micro, не очікували, що хтось використає 6502 для обробки даних - не з 32-бітним ARM, що сидить прямо там!

— supercat

1

@supercat - хоча це не важко, виконувати 32-бітну роботу над 8-бітовим мікрофоном все ще є біль у <bleep>. І на щось подібне до PIC (з ДУЖЕ обмеженими інструкціями та реєстрацією та оперативними просторами) це ще біль. Щодо чіпа ARM - я збираюся обміняти, що це має більше спільного з історичним прецедентом, ніж будь-що інше - всі звикли робити це саме так, тому продовжують робити це так.

— Майкл Коне

1

Цікаво, яка частина людей, які використовують периферійні пристрої RTCC, не перетворюють дати / часи в лічильники секунд у стилі Unix?

— supercat

1

supercat: Усі вони? Яку користь використовують часові позначки в стилі Unix в годиннику? Інакше ваш єдиний випадок використання - це тривожні сигнали RTOS, які краще подавати за допомогою звичайного таймера або з простим перериванням "другого приросту" від RTC.

— jpc

1

@jpc: Що робити, якщо ви хочете визначити, чи відповідає дана дата в літній час, або визначити, чи перекриє програма, яка запускається в певну дату / час і триває певну тривалість? Такі речі прості за секунди, але важче з YMDHMS. Що стосується використання звичайного таймера, то, що я використовую в даний час, є 1/16-секундна галочка від чіпа RTC, що веде TMR1 і TMR3 на PIC; це дає мені точне пробудження на 1/16 секунди, яке працює навіть тоді, коли зупинена основна тактова частота процесора, і я отримую з цього весь час.

— supercat

1

Я погоджуюсь з Майклом Коне, що історичного моменту дуже багато.

Ранні MCU також мали значно менше місця для коду та даних (наприклад, 128 BYTES ОЗУ). Оскільки інформація про час часто використовується для взаємодії з людьми, було більш доцільним зберігати дані, найближчі до формату, який використовується для відображення / введення людей.

Деякі нові MCU з більшою кількістю коду та даних іноді реалізують апаратні лічильники реального часу - ці пристрої часто зберігають двійкові підрахунки кліків 32 кГц.

— Іграшковий будівельник
джерело

Я кодував Atari 2600 (128 байт оперативної пам'яті), і я знаю чесноти BCD. Такі речі, як бали, майже завжди обчислюються в BCD; цифри рівня іноді є. Навіть на 6502, однак, я б очікував, що якщо мені потрібно буде визначити, чи були дві дати / рази протягом п’яти хвилин один від одного та визначити, чи діє літній час, код для перетворення лічильника 32-бітних секунд у YMDHMS бути приблизно таким же компактним, як код, щоб робити ці обчислення, не роблячи таких перетворень. Щодо новіших процесорів, я бачив деяких із прямолінійними лічильниками 32 кГц, для яких основний процесор вимагає бути живим ...

— supercat

... але чіпи, які я помітив, у яких RTCC з окремим живленням використовується BCD YMDHMS.

— supercat

Нові процесори роблять це, оскільки вони дешевші і використовують трохи менше струму (особливо важливо, оскільки напівпровідниковий процес оптимізований для виготовлення процесорів, а не RTC).

— jpc

@jpc: Чому дешевше і нижче струм використовувати BCD YMDHMS? Я думаю, що 47-розрядний лічильник для читання з компаратором на нижньому 32 біті був би простішим, ніж усі матеріали для аналізу дати в чіпі RTC. Якщо не існує якогось головного фільму ланцюга дат BCD, який через деяку таємницю давно забутої магії може бути закладений у дизайн, щоб досягти менших струмів, ніж це доступно сучасними методами, мені не зрозуміло, чому BCD буде дешевшим або використовувати менш струм?

— supercat

Я думав про відповідь @Toybuilders, в якій він заявив, що новіші процесори мають лише лічильники, а не повномасштабні RPC.

— jpc

1

У випадку, якщо когось цікавить, я просто дивлюся на серію 32F ST і, здається, в той час як новіша серія 32L використовує BCD RTC, 32F використовує прямий 32-розрядний лічильник з налаштованим доскаралом і забезпечує окремий вхід для батареї для нього (ура! ). Я б швидше мав довший прямий лічильник без настроюваного підказка (тому я міг би отримати точність 1/256 сек., Але зберігати час на роки, не турбуючись про обгортання), але якби я встановив придурок на 1/64 сек, таймер міг би працювати два роки без переповнення. Не ідеально, але не дуже погано. Трохи неестетично, що якщо хтось вмикає машину після того, як вона була вимкнена занадто довго (2,1 і більше років), час / дата непомітно відкинеться на 2,1 роки, але навряд чи це велика проблема (лічильник має прапор переповнення, але в багато випадків, які не були б дуже корисними. Якщо машина була включена протягом двох років до вимкнення живлення, і вона була включена через три місяці, таймер, як очікується, переповниться; питання полягає в тому, чи переплив він двічі, і я не знаю жодного прапора для цього.

— суперкат
джерело

0

Максим, здається, робить саме те, що хочеться з DS1372U . Він потребує менше 1 мкА, коштує 1,7 доларів і доступний (!) На DigiKey та Mouser. Єдина проблема полягає в тому, що він, здається, не пропонує тривогу з точністю більше 1 секунди, а найнижча тактова частота виходу - $ \ приблизно 4 кГц.

— jpc
джерело

1

Це трохи дорого, і це не дозволяє будь-який спосіб зчитувати з кроком менше секунди. Вихід 4096 Гц був би непоганим, хоча було б набагато приємніше, якби він був низьким на 1/65536 секунди і високим на 15/65536. Виходи з відкритим колектором повинні бути якомога меншими.

— supercat

Чому тактові мікросхеми в режимі реального часу використовують BCD

Чи всі RTC використовують кодування BCD?

Що не так з BTC RTC?

Що приємного в BTC (і взагалі розділених) RTC?

Підсумок