Почему чипы часов реального времени используют BCD

14

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

Почти все они не только хранят время как год-месяц-день-часы-минуты-секунды, но даже отдельные поля хранятся в BCD, а не в двоичном формате.

Есть ли какая-то основная причина для этого?

Существуют ли какие-либо микропроцессорные приложения, которые делают что-то более сложное, чем просто отображение часов, где формат BCD более полезен, чем двоичный, или где формат год-месяц-день-часы-минуты-секунды был бы более полезен, чем прямой 47-разрядный счет изменения состояния генератора?

Из того, что я могу сказать, кажется, что производители RTCC добавляют много дополнительных схем, чтобы сделать их чипы менее полезными; единственная причина, по которой я могу предположить, что модули RTCC в процессорах ведут себя таким образом, заключается в том, что поставщики процессоров используют некоторые уже существующие реализации BCD, а не производят свои собственные.

rtc Supercat
источник
2
Я не знаю ответа, но мне интересно, есть ли связь между BCD и 7-сегментным декодером ?
Профессор Мяу Мяу
@Prof. Мяу Мяу: славное имя. Наиболее практичным способом хранения чисел, которые будут отображаться на аппаратном уровне, является BCD. Существуют системы, в которых хранятся числа для отображения в других форматах, но во многих случаях они просто использовали ПЗУ для непосредственного сопоставления числа с его визуальным представлением (например, в игровом автомате «Танк» использовались 6-битные счетчики счета и 512). ПЗУ для преобразования каждого значения оценки в форму 8x8), но это, как правило, работало, только если максимальное числовое значение было довольно маленьким.
суперкат

Ответы:

12

Все RTC используют кодировку BCD?

RTC от Philips / NXP (как автономные, так и встроенные в чипы ARM7 или Cortex-M3) не используют кодирование BCD.

Что не так с BCD RTC?

По сравнению с плоским счетчиком единственными операциями, которые являются более сложными с разделенными часами BCD, являются вычисления разницы во времени (добавление секунд или вычисление прошедшего времени). Сравнение времени, например: «текущее время больше, чем время, установленное пользователем», также просто.

Что хорошего в RTC BCD (и вообще с разделенным полем)?

Разделение полей действительно хорошо, когда вы заботитесь о календарной дате. У человеческих календарей есть забавные вещи, такие как месяцы различной продолжительности и сверх того високосного года. Попробуйте сделать это в одиночном счетчике (вы можете получить бонусное очко за использование практически без энергии). Ох, и попробуйте поддерживать дни недели (весьма полезные для всех видов устройств, предназначенных для людей: от будильников до контроллеров обогревателей) с этим.

Подход BCD имеет одну дополнительную особенность: вы получаете прерывания «каждую секунду» или «каждые десять секунд» бесплатно, без необходимости выполнять какие-либо вычисления по времени или датам.

Для рекордного високосного года вычисление немного меньше в RTC NXP, так как он заботится только о делимом на 4 правило и не проверяет деление на 100 и 400. Если бы он сохранял счетчик года в BCD, это было бы тривиально и, скорее всего, сделано правильно.

Резюме

  1. Если вы хотите монотонные часы, используйте их. Вы можете купить PIC или AVR с «счетчиком RTC» (это просто асинхронный счетчик с автономным генератором 32 кГц). Просто помните, что просто отобразить дату будет сложно. :)

  2. Когда вам нужно отобразить время и дату и установить будильник на основе введенного пользователем времени и даты, используйте RTC. И помните, что когда пользователь изменяет текущее время и дату, ваши прерывания на основе RTC могут быть неточными.

JPC
источник
1
Я только начал использовать Gekko, который имеет 24-битный RTC, это почти то, что я хочу, за исключением того, что он не может держать время, когда процессор не работает. Я также смотрел на ST Micro ARM, который имеет глупый RTC-модуль BCD, который поддерживает прерывания только на одну секунду. Если бы чип ST никогда не оставался без электричества более трех лет, я мог бы скомпоновать предскаляры RTC для работы на скорости 32x, а затем использовать программные трюки для компенсации, получая, таким образом, временное разрешение 1/32 секунды для событий пробуждения, но время, сохраненное в RTC, не имело бы никакого значимого отношения к календарному времени и ...
суперкат
1
... поэтому необходимость преобразования из глупого формата RTC в приращения в 1/32 секунды была бы раздражающей, тем более что такое преобразование требовалось бы при каждом цикле ожидания / пробуждения. Думаю, мне любопытно, сколько людей используют показания RTCC без преобразования в единые секунды. Может быть , есть достаточно , чтобы сделать формат YMDhms стоит, но на мой взгляд , это гораздо полезнее для резервных YMDhms для человека I / O, а также использовать прямые секунд (или любой его фракции) для всего остального.
суперкат
1
@jpc: Я бы предпочел никогда не устанавливать время чипа RTC, а вместо этого сохранять «время с момента установки батареи часов» и сохранять разницу между этим временем и временем на стене. Я использовал этот подход в одном поколении продукта, который использовал отдельное PIC для хранения времени автономной работы от батареи (время на этом PIC было только для чтения) и использовал его на чипе с прямым счетчиком. Тем не менее, казалось несколько глупой идеей, чтобы RTC машины хранил бессмысленное значение в формате даты, хотя, если бы я использовал микросхему ST Micro, я мог бы просто сделать это.
суперкат
1
Кстати, серия STM32F100 использует 32-битный RTC (не BCD), но серия STM32F400 возвращается к кодированному RTC RCD. Вздох.
Марк Лаката
1
@FedericoRusso: разделенное поле имело бы некоторый смысл, хотя в большинстве приложений это скорее препятствие, чем помощь. Выбор BCD, тем не менее, кажется совершенно странным как выбор в комплекте с процессором , который не поддерживает BCD .
суперкат
3

Когда вы используете часы в конце, вам, скорее всего, будут интересны минуты и десятки секунд (для их отображения), а не просто общее количество секунд, минут и так далее. В случае, если вас не интересуют отдельные цифры, есть вероятность, что вам не нужны отдельные значения минут или секунд и что вы также можете использовать длинный двоичный счетчик, как вы предлагали.
Проще конвертировать из двоичного кода в двоичный в программном обеспечении, чем наоборот. А поскольку счетчики 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 - для компьютеров общего назначения, пусть ОС отслеживает время и делает «полезные вещи» с информацией о времени. К RTC обращаются только один раз для инициализации информации о времени ОС, а затем время обновляется прерываниями. Но для многих простых встроенных приложений гораздо более вероятно, что
Toybuilder
1
@Toybuilder: последнее - именно тот подход, который я использовал в последние несколько поколений электронных замков. Мое самое большое раздражение было отсутствие выбора импульсного выхода между 32 кГц и 16 Гц (так как я не доверял 1M подтягивающему устройству для надежной работы с выходом с открытым коллектором 32 кГц, единственный разумный выбор был 16 Гц), и небрежность PIC схема таймера.
суперкат
1
@FedericoRusso: Если бы у вас был счетчик времени с двоичным кодом, ему не пришлось бы переводить обратно в часы, минуты и секунды, за исключением, возможно, отображения, читаемого человеком. Один просто добавляет 3723 и все. При работе со значениями даты / времени YMD-HMS требуется отдельный код для увеличения и уменьшения, переход на летнее время - это кошмар, для которого производители микросхем, похоже, хотели бы добавить неработающую поддержку [как команду, которая вычитает единицу из числа часов, кроме случаев, когда это ноль, в этом случае он ничего не делает]. DST - тоже бинарная боль, но не такая отвратительная.
суперкат
3

Я подозреваю несколько причин:

Исторический - они делают это таким образом в течение некоторого времени. Если вы хотите, чтобы ваша новая деталь заменила какую-то другую, то она должна работать более или менее одинаково. Таким образом, вы держите с BCD.

Применение - если кто-то использует RTC от небольшого микро (что-то в 8-битном диапазоне, например, PIC низкого уровня), то работа с большим числом (например, с вашим 47-битным счетчиком) - большая боль в шее. Гораздо проще иметь дело с цифрами BCD, так как вам не нужно разбирать вещи.

Не так сложно - работать со счетчиками BCD не так сложно, и на самом деле я думаю, что это не намного больше, чем делать их двоичными.

Можно представить себе систему, в которой вы получаете отдельные счетчики часов, минут и т. Д. В двоичном формате вместо BCD (что позволяет избежать проблемы «разбивки 47-битного числа»), но это не намного проще, и вы собираетесь сделать некоторые конверсии при отображении вещи в любом случае.

Майкл Кон
источник
1
48-битное число будет 32-битным числом секунд и 16-битной дробью. Работа с 32-битными числами на 8-битном микро не так уж и плоха. Я могу себе представить, что на чем-то похожем на 6502, который мог бы прекрасно обрабатывать упакованные BCD, формат BCD в некоторых случаях может сэкономить несколько байтов, хотя дополнительная сложность обработки переноса между секундами, часами и минутами сведет на нет любое преимущество. Но, конечно, люди, которые встроили RTCC в ARM-чипы ST micro, не ожидали, что кто-то будет использовать 6502 для обработки данных, а не 32-битный ARM!
суперкат
1
@supercat - хотя и не сложно, 32-битная работа на 8-битном микро все еще является проблемой в <bleep>. А на чем-то вроде PIC (с ОЧЕНЬ ограниченным количеством команд, регистров и оперативной памяти) это еще более болезненно. Что касается чипа ARM - я готов поспорить, что он больше связан с историческим прецедентом, чем с чем-либо еще - все привыкли делать это таким образом, поэтому они продолжают делать это таким образом.
Майкл Кон
1
Интересно, какая часть людей, которые используют периферийные устройства RTCC, не конвертируют дату / время в счетчики секунд в стиле Unix?
суперкат
1
Суперкат: Все они? Какая польза от часовых меток в стиле Unix? OTOH ваш единственный вариант использования - это аварийные сигналы RTOS, которые лучше обслуживать с помощью обычного таймера или с простым прерыванием «второго приращения» от RTC.
jpc
1
@jpc: Что делать, если вы хотите определить, относится ли данная дата к летнему времени или определить, будет ли программа, которая запускается с определенной датой / временем и длится определенную продолжительность, перекрывать другую? Такие вещи легко с прямыми секундами, но сложнее с YMDHMS. Что касается использования обычного таймера, то, что я сейчас использую, это 1/16-секундный тик от чипа RTC, управляющего TMR1 и TMR3 на PIC; это дает мне пробуждение с точностью до 1/16 секунды, которое работает, даже когда основные тактовые частоты процессора остановлены, и я извлекаю из этого все время.
суперкат
1

Я согласен с Майклом Коном, что есть много исторического импульса.

В ранних MCU также было гораздо меньше места для кода и данных (например, 128 байт оперативной памяти). Поскольку информация о времени часто используется в целях взаимодействия с человеком, имело больше смысла сохранять данные ближе к формату, используемому для отображения / ввода от людей.

Некоторые более новые микроконтроллеры с большим количеством кода и пространства данных иногда используют аппаратные счетчики реального времени - эти устройства часто сохраняют двоичные числа тиков 32 кГц.

Toybuilder
источник
Я написал код для Atari 2600 (128 байт оперативной памяти) и знаю достоинства BCD. Такие вещи, как баллы, почти всегда вычисляются в BCD; номера уровней иногда бывают. Однако даже на 6502 я ожидал, что, если бы мне нужно было определить, были ли две даты / время в пределах пяти минут друг от друга, и определить, действительно ли действует летнее время, код для преобразования 32-разрядного счетчика секунд в YMDHMS быть столь же компактным, как и код, чтобы выполнять эти вычисления без таких преобразований. Что касается более новых процессоров, я видел некоторые с прямыми счетчиками 32 кГц, которые требуют, чтобы основной процессор был
активен
... но я заметил, что чипы с RTCC с отдельным питанием используют BCD YMDHMS.
суперкат
Более новые процессоры делают это, так как они дешевле и потребляют немного меньше тока (особенно важно, поскольку используемый полупроводниковый процесс оптимизирован для создания процессоров, а не RTC).
jpc
@jpc: Почему дешевле использовать BCD YMDHMS? Я бы подумал, что 47-битный счетчик только для чтения с компаратором в нижних 32 битах будет проще, чем все элементы анализа даты в чипе RTC. Если нет какого-либо мастер-фильма о схеме датирования BCD, который из-за какой-то загадочной давно забытой магии может быть использован в проекте для достижения более низких токов, чем это доступно современными методами, я не понимаю, почему BCD будет дешевле или использовать меньше тока?
суперкат
Я думал об ответе @Toybuilders, в котором он заявил, что у более новых процессоров есть только счетчики, а не полноценные RPC.
jpc
1

В случае, если кому-то интересно, я просто смотрю на серию ST 32F, и кажется, что, хотя новая серия 32L использует BCD RTC, 32F использует прямой 32-битный счетчик с настраиваемым прескалярным и предоставляет отдельный вход для батареи (ура! ). Я бы предпочел иметь более длинный прямой счетчик без настраиваемого предскалярного (так что я мог бы получить точность 1 / 256сек, но не тратить время на годы, не беспокоясь об обтекании), но если бы я установил прескейл на 1 / 64сек, таймер мог бы работать два года без переполнения. Не идеально, но не так уж плохо. Немного неэстетично, что если кто-то включит машину после того, как она слишком долго выключится (2,1 года), время / дата неоправданно уменьшатся на 2,1 года, но вряд ли это серьезная проблема (счетчик имеет флаг переполнения, но в во многих случаях это было бы ужасно полезно. Если машина была включена в течение двух лет до выключения и была включена три месяца спустя, ожидалось, что таймер переполнится; вопрос будет в том, переполнился ли он дважды, и я не знаю ни одного флага для этого.

Supercat
источник
0

Максим, кажется, делает то, что вы хотите с DS1372U . Требуется менее 1 мкА, стоит 1,7 доллара США и доступно (!) На DigiKey и Mouser. Единственная проблема заключается в том, что он не предлагает сигналы тревоги с точностью более 1 секунды, а самая низкая тактовая частота на выходе составляет $ \ приблизительно $ 4 кГц.

JPC
источник
1
Это немного дорого, и это не позволяет считывать приращения меньше секунды. Выход 4096 Гц был бы хорош, хотя было бы намного лучше, если бы он был низким для 1/65536 секунды и высоким для 15/65536. Выходы с открытым коллектором должны быть как можно меньше.
суперкат