Нужны ли часы реального времени (RTC) для систем реального времени? [закрыто]

Предполагая, что мы работаем над системой и оборудованием Linux реального времени, которые состоят из таймеров высокого разрешения, влияет ли RTC на своевременность системы в реальном времени?

Здесь говорится, что это уменьшает использование процессора и памяти, но есть ли способ как-то сравнить разницу?

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

Несколько других битов из статьи, чтобы установить, что это следует считать ненадежным:

Почти ничтожно. Порядка 1 сек в 100 лет

1 секунда за 100 лет составляет примерно 317 ppt (да, это части на триллион ). Вы не можете получить такую ​​стабильность часов с любой имеющейся в продаже технологией часов. Даже при достижении 1 секунды в год потребуется, по крайней мере, OCXO, который требует мощной, постоянно включенной печи, регулирующей температуру. Идея, которую вы могли бы получить с устройством, работающим от долговечной батарейки, смешна.

системы реального времени, такие как цифровые часы, система посещаемости, цифровая камера

Ни один из них не является тем, что можно назвать системами реального времени.

Системы реального времени - это то, что реагирует на внутренние или внешние события / стимулы в течение определенного времени, и это время обычно составляет милли или микросекунды. Ему нужен таймер малой точности, а не RTC.

И ответ на ваш вопрос - нет, это не повлияет на реальное время работы системы.

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

Легко или сложно, низко или высоко в статье, на которую вы ссылаетесь, является своего рода личным мнением. Это сложно и дорого, если вы никогда не делали этого раньше и не имеете четких системных требований и технического задания; и это легко и дешево, когда вы знаете, что вам нужно и какое устройство лучше всего использовать.

В большинстве систем единственным реальным преимуществом периферийного устройства RTC над другими формами учета времени является то, что измерения времени RTC не будут затронуты, когда остальная часть системы перейдет в спящий режим или - в некоторых случаях - будет полностью отключена. Многие периферийные устройства RTC на самом деле спроектированы таким образом, чтобы сделать их непрактичными для большинства целей, кроме записи приблизительного времени суток. Например, многие периферийные устройства RTC (вероятно, большинство, но, возможно, не большинство) ограничены временем сообщения с интервалом в одну секунду, и многие из них, по крайней мере, иногда требуют занятости в ожидании синхронизации при установке будильника или - в в некоторых случаях - даже просто пытаясь прочитать время. Как следствие, обычный способ использования RTC - просто скопировать его значение на более полезные часы при запуске, устанавливая его всякий раз, когда устанавливается «время стены»,

и любые четыре последовательных чтения будут гарантированно содержать два, которые соответствуют (и, следовательно, являются правильными), если между первым и последним не пройдет более 1/32768 секунды. Установка будильника может генерировать ложные события пробуждения, но последовательность:

• отключить прерывание от защелки
• установить время пробуждения до 0x7FFFFFFF тиков (около 9 часов) до настоящего времени
• сбросить схему пробуждения
• читать часы
• если вновь прочитанное время указывает на то, что время пробуждения достигнуто, действуйте соответствующим образом
• включить прерывание от защелки

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

Похоже, это проблема терминологии, связанной с использованием термина «в реальном времени».

Часы реального времени

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

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

Альтернативой часам реального времени было бы использование программного обеспечения и внутренних таймеров, управляемых системными часами. Такой подход работоспособен (оригинальный IBM PC работал таким образом), но не особенно стабилен; он также потеряет информацию о дате / времени в любой момент, когда операционная система завершит работу, зависнет или произойдет сбой.

Система реального времени

Когда термин «в реальном времени» применяется к компьютерной системе или приложению, он описывает систему, которая реагирует на события реального мира за очень короткое, детерминированное время - часто всего за несколько миллисекунд, иногда меньше, с определенным порядком. одновременных входов. Системы реального времени используются для таких вещей, как управление машиной - робототехника, симуляции и игры. Хотя приложение реального времени может использовать информацию о текущем времени и дате, приложение не «в реальном времени» только потому, что оно использует текущее время и дату.

Часы реального времени против таймеров с высоким разрешением

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

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

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

Обычно RTC может иметь таймеры, сторожевых собак и т. Д., Связанных с ним, что дает гарантированное или хорошее предположение, что с регулярными точными интервалами, которые даже могут оставаться в фазе с различными вещами, данные процедуры или код будут выполняться. Вы не можете легко получить это с обычными часами. Или вы должны быть очень осторожны в производстве, чтобы часы были точными. Вы можете видеть такие вещи, как аудио и что может не понадобиться использовать RTC вместо высокоскоростных системных часов.

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

Тогда есть критически важные и низкоэффективные приложения. Одна желательная вещь здесь является детерминированным и часто более низким решением сложности. Здесь RTC можно использовать, очевидно. Linux может предоставлять специальный доступ к связанным с ним прерываниям. Мне кажется, что для детерминированного реального времени вам требуются не только rtc, но и прерывания или доступ к ним.

Вам понадобятся часы реального времени, если вы полагаетесь на безопасную связь с другими компьютерами в Интернете (не обязательно на 100%, но если у вас нет ссылки на местное время, вам нужно доверять чему-то другому, и вы можете ' доверять сертификатам, если вы не знаете дату).

Так что нет, он вам не нужен для всех систем реального времени. Однако, в зависимости от вашего приложения, вы все равно можете выбрать RTC в качестве наиболее энергоэффективного способа получения исправления хорошего времени после нахождения в состоянии низкого энергопотребления.