]@poly Воля ваша верить или нет. Я сам в лёгком шоке. Это уже третьи часы. Не с одними таких проблем не было. Платы едентичные. Лампы тоже. Прошивка одна. Но факт есть факт. Завтра поменяю ардуино.единственное не могу понять почему видно как перебирает лампы. Такого на других часах не было. Такое ощущение что перебор идёт не на 50герц а меньше.
ARDUINO Часы на ГРИ v2. Обсуждение проекта
- Автор темы Methanol
- Дата начала
Возможно, всё и объясняется тем, что не Atmega328p там. Народ жалуется в отзывах, что даже blink.ino мигает светодиодом заторможено. Не потому, что процессор плохой, а потому, что он другой. При правильной настройке да в умелых руках процессор способен творить чудеса.
Обычно в лоте продавца есть ссылка на файл с настройками для Arduino IDE - надо их скачать, установить и настроить правильно на плату.
Года 3 назад я взял себе платку на AVGA328P от WAVGAT для экспериментов, но так руки и не дошли...
В общем, http://arduino.ru/forum/apparatnye-voprosy/obzor-klona-megi328-lgt8f328p .
Обычно в лоте продавца есть ссылка на файл с настройками для Arduino IDE - надо их скачать, установить и настроить правильно на плату.
Года 3 назад я взял себе платку на AVGA328P от WAVGAT для экспериментов, но так руки и не дошли...
В общем, http://arduino.ru/forum/apparatnye-voprosy/obzor-klona-megi328-lgt8f328p .
Добрый день. Собрал часы на индикаторах ин-14, lamptest работает, цифры перебирает. Проблема только в том, что при прошивке выставляет время не такое же как на компьютере, а какое-то случайное, иногда на 10 минут меньше, иногда на несколько часов. Попробовал поменять модуль часов (использую микро версию), такой же результат. Если отключить питание на 10 минут, то после включения часы показывают неправильно установленное время + 10 минут. Т.е. модуль часов вроде работает. Какой-то необъяснимый глюк. Никто не сталкивался с подобной проблемой?
Какой вариант программы прошивается? Нет ли там чего-нибудь про настройку часового пояса?
При компиляции программы в прошивку попадает время компиляции - и именно оно считается стартовым на первый запуск, прописывается в RTC. При последующих стартах время должно браться уже с RTC, если RTC на батарейке/аккумуляторе/ионисторе. Если при отключении питания отсчёт времени не останавливается, то эта часть работает.
Дальше надо выставить время, используя кнопки и инструкцию на конкретный вариант программы часов. Может, этого и хватит, и всё будет работать правильно.
При компиляции программы в прошивку попадает время компиляции - и именно оно считается стартовым на первый запуск, прописывается в RTC. При последующих стартах время должно браться уже с RTC, если RTC на батарейке/аккумуляторе/ионисторе. Если при отключении питания отсчёт времени не останавливается, то эта часть работает.
Дальше надо выставить время, используя кнопки и инструкцию на конкретный вариант программы часов. Может, этого и хватит, и всё будет работать правильно.
Получил на емейл от зарубежного комьюнити вот такое сообщение. Ниже привожу перевод. Судь в том, что уже было не раз замечено странное поведение чипа DS3231, а именно, чем чаще к нему обращались за чтением/синхронизацией времени, тем больше он отставал... Оснований сомневаться в этом у меня нет. Факт проверенный. Вопрос в другом. Связано ли это с микрокодом самого чипа? Манипулируют ли китайцы с микрокодом? Вообщем, вопросов больше чем ответов. Напишите, что думаете по этому поводу и какие практические рекомендации можно из этого извлечь: к примеру, реже синхронизировать время или повысить частоту шины I2C?
-----------------------------
Привет SergejEU,
fogg ответил в теме форума "Замедляет ли частое чтение DS3231 RTC ???":
У меня есть еще один интересный вопрос, связанный с вопросом, заданным ТО: будет ли частое считывание RTC замедлять работу часов?
Я купил несколько часов реального времени DS3231, и все они кажутся довольно точными, но сильно различаются по точности: от 0,01 до 4 ppm. В любом случае, у меня есть один, который я проверял в течение 2 недель, и он отклонился от сигнала DCF77 примерно на 500 мс, что соответствует 0,5 ppm. Теперь я использовал его в эксперименте, где я обрывал чтение регистра 0x00 в середине передачи I2C, чтобы посмотреть, можно ли вернется ли программное обеспечение к первоначальному состоянию. Состояние по SDA восстановилось, но часы сильно замедлились! (I started the recovery after 3 minutes and the RTC was 45 seconds behind.) Я начал восстановление через 3 минуты, а RTC отставал на 45 секунд. И этот эффект был воспроизводимым! с другим DS3231 я мог видеть тот же эффект замедления в 1/4 времени от начала передачи I2C до финиша.
Таким образом, может быть что-то в том, что подозревает TO: частые (или длинные) чтения могут замедлить часы.
Бернхард
-----------------------------
Привет SergejEU,
fogg ответил в теме форума "Замедляет ли частое чтение DS3231 RTC ???":
У меня есть еще один интересный вопрос, связанный с вопросом, заданным ТО: будет ли частое считывание RTC замедлять работу часов?
Я купил несколько часов реального времени DS3231, и все они кажутся довольно точными, но сильно различаются по точности: от 0,01 до 4 ppm. В любом случае, у меня есть один, который я проверял в течение 2 недель, и он отклонился от сигнала DCF77 примерно на 500 мс, что соответствует 0,5 ppm. Теперь я использовал его в эксперименте, где я обрывал чтение регистра 0x00 в середине передачи I2C, чтобы посмотреть, можно ли вернется ли программное обеспечение к первоначальному состоянию. Состояние по SDA восстановилось, но часы сильно замедлились! (I started the recovery after 3 minutes and the RTC was 45 seconds behind.) Я начал восстановление через 3 минуты, а RTC отставал на 45 секунд. И этот эффект был воспроизводимым! с другим DS3231 я мог видеть тот же эффект замедления в 1/4 времени от начала передачи I2C до финиша.
Таким образом, может быть что-то в том, что подозревает TO: частые (или длинные) чтения могут замедлить часы.
Бернхард
@SergejEU, хм, интересная информация... Тогда думаю нужно будет пожертвовать генерацией мелодий в угоду счёта времени на таймере 0, если его настроить на секундное прерывание, то счёт времени будет достаточно точный и не будет убегать так как с использованием миллис... А РТС использовать для хранения времени на случай отключения питания (ну или синхронизироваться, но например раз в сутки).
а миллис, вы думаете, не на таймере0 считается?
Вы поглядите, как миллис устроено. То что вы предлагаете - ровно то же самое.
Проблема , как мне кажется, тут в другом
а) большое количество прерываний, нужное на динамическую индикацию - вызывает пропуски системного таймера
б) код подсчета секунд не идеален, иногда пропускает
Дружище, я конечно всё понимаю, но по всей видимости это Вы не видели как работает миллис...
Поясняю - мы получили вместо 1000 прерываний в секунду всего одно, и тем самым на фоне остальных прерываний мы уменьшим в разы накопленную ошибку.
зато когда ошибается миллис - он ошибается всего на 1 мс. А в вашем варианте, если эта ошибка все же случится - то она будет сразу на секунду. В итоге получается то на то.
Но в общем-то нет смысла спорить. Добавить такой таймер, как вы хотите - дело пяти строчек в коде. Давайте попробуем.
@SergejEU, я довольно много экспериментировал с DS3231 и не поддерживаю выводы о влиянии чтения на точность времени внутри DS3231. Для этого у меня есть несколько аргументов. В частности, в разработке COVID от @adm503 мы использовали тактирование частотой 8кГц от DS3231 - штатный режим работы без запросов. При отладке кода я полностью отключал подсчёт по внутреннему таймеру Ардуино, только таймер на прерываниях от SQW, пытался читать время каждые сутки, час, минуту и даже секунду. Так получилось, что в моей плате, предоставленной мне для отладки, мне попался как раз глючный DS3231 (не настолько, как у многих в этой ветке, но заметно отстающий, примерно на 10 секунд в сутки). Так вот эта ошибка сохранялась ровно такой независимо от частоты и способа чтения. Более того, даже в выключенном состоянии (когда запросов вообще нет, как и не работает выход тактирования, модуль работает от стабильного батарейного питания) ошибка была именно такой, как и в рабочем режиме в часах.
В приведённой выдержке из ответа нет утверждения влияния количества запросов к DS3231 на его точность. То, что содержится в качестве ответа, - это попытка реанимации DS3231 после нештатной блокировки шины I2C. Программные методы выхода из этого режима существуют, но даже они предполагают возможное разрушение информации в регистрах, немудрено, что после этого время может измениться.
@Sergo_ST, от millis() зависит множество библиотек, используемых в часах (например, Wire). Придётся их либо полностью переписывать, либо отказываться от их функционала.
В приведённой выдержке из ответа нет утверждения влияния количества запросов к DS3231 на его точность. То, что содержится в качестве ответа, - это попытка реанимации DS3231 после нештатной блокировки шины I2C. Программные методы выхода из этого режима существуют, но даже они предполагают возможное разрушение информации в регистрах, немудрено, что после этого время может измениться.
@Sergo_ST, от millis() зависит множество библиотек, используемых в часах (например, Wire). Придётся их либо полностью переписывать, либо отказываться от их функционала.
Не обязательно ломать миллис
на первом таймере висит динамическая индикация. А на втором что?
то есть вы этот проект полностью переписали с нуля, без библиотек? Или я неправильно понял, к чему это высказывание...
Если мы говорим про конкретно этот проект - в нем библиотеки есть и предлагать от них отказаться имеет смысл, если вы готовы выложить проект без них.
На данный момент нет ещё, пока занимаюсь приложением, позже напишу и саму прошивку. Пока только готова улучшенная динамическая индикация и протокол обмена данными с приложением.
@Sergo_ST, как вариант. Но в данных проектах используется много таких библиотек. И вряд ли кто-то будет ради некоторой точности переписывать относительно простой код часов на собственные библиотеки. Я не говорю о, допустим, использовании своих запросных частей к периферии, я говорю о базовых библиотеках. И там какой-то вариант millis или micros использовать придётся, программно их вряд ли можно все заменить.
Кстати, что такое "вдт"?
По таймерам:
Кстати, что такое "вдт"?
По таймерам:
- таймер 0: обеспечивает работу millis и micros, стандартная частота;
- таймер 1: работа DC/DC преобразователя и ШИМ точек в часах (31кГц);
- таймер 2: ШИМ подсветки и прерывание динамической индикации (7,8 кГц).
Изменено:
Ну это уже вопрос к тем кто поддерживает свои проекты, если нужно будет выдернут кусок, исходники я всегда оставляю. Я имел ввиду что у себя скорее всего буду это использовать.
Вдт - это WatchDog, это ещё один таймер с собственным осцилятором(128кГц) и возможностью хардверно дергать пин ресет. Обычно его используют как подстраховку, если вдруг программа где нибудь застрянет, то через установленный интервал мк перезагрузится. Также у него есть собственный вектор прерывания в котором можно что нибудь выполнять.
Изменено:
Не будем трогать миллис.
Можно для начала исправить. простые ошибки в самом скетче.
Смотрю версию v2.5 с Гитхаба - имхо, в ней счетчик времени содержит баг, который будет приводить к пропуску секунд, если в коде происходят длительные действия.
Ошибка в файле timer2Minim.ino - если по какой-то причине таймер проверять редко, он пропускает периоды.
Вероятно, это происходит не так часто, чтобы вызывать отставание на 15 минут за 1.5 часа... но все же.
Хотя может это давно исправлено, но более нового кода я не нашел.
Можно для начала исправить. простые ошибки в самом скетче.
Смотрю версию v2.5 с Гитхаба - имхо, в ней счетчик времени содержит баг, который будет приводить к пропуску секунд, если в коде происходят длительные действия.
Ошибка в файле timer2Minim.ino - если по какой-то причине таймер проверять редко, он пропускает периоды.
Вероятно, это происходит не так часто, чтобы вызывать отставание на 15 минут за 1.5 часа... но все же.
Хотя может это давно исправлено, но более нового кода я не нашел.
Баг в коде есть. Другое дело, что для его проявления нужен большой перерыв в вызове таймера.
Хотя, например, "антиотравление катодов" в стандартном коде занимает 300мс - уже не так далеко до периода таймера.
На самом деле - если баг известен- всегда лучше его исправить, вдруг поможет
Изменено:
Чтобы пропустить отсчёт, нужно пропустить подряд два или более срабатывания таймера. Я делал тайминг процессов - таких длительных нет.
С другой стороны, не имея аппаратной поддержки параллелизма, никакие ухищрения не позволят сделать непробиваемый код. Даже если повесить всё на прерывания, придётся задумываться об их блокировке другим прерыванием. Да и прерываний внутренних столько нет. Динамическая индикация сама по себе - челлендж для процессора, по хорошему нужно всё переделывать на статически подключенные катоды и динамически управляемые ШИМ аноды, но сложность схемы будет явно выше.
С другой стороны, не имея аппаратной поддержки параллелизма, никакие ухищрения не позволят сделать непробиваемый код. Даже если повесить всё на прерывания, придётся задумываться об их блокировке другим прерыванием. Да и прерываний внутренних столько нет. Динамическая индикация сама по себе - челлендж для процессора, по хорошему нужно всё переделывать на статически подключенные катоды и динамически управляемые ШИМ аноды, но сложность схемы будет явно выше.
@poty, В принципе как и с любым другим таймером. Выставляем пределитель, интервал между прерываниями от 16мс до 8с можно настроить, и все, просто считаем циклы. Да осциллятор 128кГц крайне термо-нестабилен, но для большинства задач этого достаточно.
На счет динамической индикации, не такая она уж и прожорливая если все правильно написать, но с такой портянкой в прерывании как сейчас да, это достаточно большая нагрузка...
На счет динамической индикации, не такая она уж и прожорливая если все правильно написать, но с такой портянкой в прерывании как сейчас да, это достаточно большая нагрузка...