RTC в LPC, Проверка корректности. Опции

[alexander55]

Добрый день !
Вопрос следующий.
Каким способом при старте можно проверить, что часы реального времени в LPC не сбились ?

[Leen]

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

[alexander55]

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

Ну скажем, год 3310. Боюсь, что не доживу до этого.

[Leen]

Так а что подразумевается под "сбились"? Уход от реального времени вследствие погрешности (постоянной/переменной, скажем, температурный уход частоты) задающего генератора или обнуление из-за сбоя питания? Если обнуление - то запоминать. Тем более, если часы считают годы - если век не соответствует записанному в энергонезависимую память, то точно пропадало питание часов. Ну а если просто уход на +/- полкилометра - то имхо только сравнение с эталоном, а как еще?

[alexander55]

Так а что подразумевается под "сбились"? Уход от реального времени вследствие погрешности (постоянной/переменной, скажем, температурный уход частоты) задающего генератора или обнуление из-за сбоя питания? Если обнуление - то запоминать. Тем более, если часы считают годы - если век не соответствует записанному в энергонезависимую память, то точно пропадало питание часов. Ну а если просто уход на +/- полкилометра - то имхо только сравнение с эталоном, а как еще?

Ну например.
30 июня
при этом это
356 день года.

[Leen]

Ну например.
30 июня
при этом это
356 день года.

Хм. Ну если для вас сбой - это разница показанийй двух параллельных счетчиков - так это как раз проверить крайне просто. Можно контролировать по таблице длин месяцев (для простоты) - например, есть массив количества дней: в январе, в январе + в феврале (здесь и далее - год не високосный), по март, и т.д. Смотрим, какой месяц сейчас - берем соотв. число дней до этого месяца + кол-во дней из счетчика. Если нынче високосный год и февраль закончился - плюсадиним, сравниваем со счетчиком дней года. Вроде просто.
А вот отставание или опережение из-за плохонького китайского часового кварца - это да, это проблема. Нужен эталон (который может быть дороже всего остального - цезиевые часы с термостабилизацией, или какие сейчас самые точные), или просто человека заставить иногда поправлять время, ориентируясть на радио Маяк.

[alexander55]

Хм. Ну если для вас сбой - это разница показанийй двух параллельных счетчиков - так это как раз проверить крайне просто. Можно контролировать по таблице длин месяцев (для простоты) - например, есть массив количества дней: в январе, в январе + в феврале (здесь и далее - год не високосный), по март, и т.д. Смотрим, какой месяц сейчас - берем соотв. число дней до этого месяца + кол-во дней из счетчика. Если нынче високосный год и февраль закончился - плюсадиним, сравниваем со счетчиком дней года. Вроде просто.

Вот и вопрос. Насколько это универсально.

[Leen]

Вот и вопрос. Насколько это универсально.

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

[alexander55]

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

Вероятнее, банальное пропадание контакта от батарейки.

[Leen]

Ну если все-таки от пропадание напряжения, то они собьются синхронно, не так ли? Тогда смысл такой проверки нулевой - оба счетчика будут (после приведения к общей единице) иметь одно и то же содержимое. Тогда либо оператора-человека, либо второй ртс. Кстати, от пропадания контакта на батарейке есть неплохие ионисторы - 2,3 В х 40 Ф. Маленькие, всего 14х18х(40+12 на выводы)Хватит может и не до 3310 года, но надолго Тип К58-16. Вроде даже на 47 Ф уже выпускаются. Как раз думаю, не использовать ли

[abcdefg]

Добрый день !
Вопрос следующий.
Каким способом при старте можно проверить, что часы реального времени в LPC не сбились ?

Из моего опыта - только проверять валидность (диапазона) данных. Есть там один информационный бит, но при сбое (отключении батарейки) он то "слетал", то нет.

[vesago]

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

[alexander55]

Из моего опыта - только проверять валидность (диапазона) данных.

Я тоже склоняюсь к такому решению.

[GetSmart]

Из моего опыта - только проверять валидность (диапазона) данных. Есть там один информационный бит, но при сбое (отключении батарейки) он то "слетал", то нет.

какой?

[alexander55]

какой?

1. Срок изделия допустим 50 лет. Т.е. год в диапозоне 2007-2057.
2. День года должен соответствовать числу. Например: 31 декабря 2008 года - 366 день.
Это - то, что на поверхности.

[HEX]

Схожие проблемы, только часы внешние fm31xx.
Если часы ушли (по причине не точности), без дублирование это не определить.
Вот если сдохла батарейка или по каким то причинам прерывалось питания часов или чего то с кварцем часов, это надо отлавливать.
Запускаю часы только при операции "установить время", что бы можно было отловить когда часы показывают ерунду. При работе прибора, периодически сравниваю временя измеренное RTC и таймером. Например, запускаю таймер на 60 сек, за это время показания RTC должно увеличиться тоже на 59..61 сек (дискретность часов в 1сек точнее не дает померить). Кроме проверки корректности значений в регистрах часов еще полезно проверять что считанное значение из RTC больше или равно предыдущему, плюс проверять напряжение на батарейке (у fm31xx есть битик "Low Backup Flag")
Вообщем, если достоверность показания часов критична я думаю лучше ставить внешние часы:
- дублирование часы + программное время
- есть флаги достоверности времени, состояния батарии (например у MAX6916, MAX6917)
- дополнительные функции такие как сторожевой таймер, энергонезависимая/батарейная память и т.п

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

[Spb_Alex]

Можно взять дешевый GPS (от 17$), время определяется очень точно.

[GetSmart]

1. Срок изделия допустим 50 лет. Т.е. год в диапозоне 2007-2057.
2. День года должен соответствовать числу. Например: 31 декабря 2008 года - 366 день.
Это - то, что на поверхности.

Я спрашивал какой бит в RTC LPC ?

[abcdefg]

Я спрашивал какой бит в RTC LPC ?

Сорри, быстро ответить не смогу, т.к. сижу дома с температурой. К пятнице доберусь до работы, там можно будет поднять переписку с техсупотом филипса...

[alexander55]

Я спрашивал какой бит в RTC LPC ?

Я ничего не понял. Про биты я ничего не говорил.

[deadman]

Можно взять дешевый GPS (от 17$), время определяется очень точно.

Ага. Вот только есть гарантия, что он спутник увидит? (из подвала, например)

[GetSmart]

Я ничего не понял. Про биты я ничего не говорил.

Само собой. Потому как я у abcdefg спрашивал.