А может из-за того что на самой плате датчика стоят сопротивления подтяжки и на модуле RTC стоят сопротивления?
А температуру более менее нормально показывает...

Как и ожидалось, подобного глюка не наблюдается. Выводятся показания одного DS18B20, температуры/давления BMP180, температуры/влажности DHT22 (дефолтный eeprom) бегущей строкой, после чего адекватно отображается время с будильниками. По дате тоже без проблем.

Сколько у Вас, кстати, датчиков подвешено, насколько длинная строка в буфер кладётся?

всех по одному 1820 BMP180 DHT22 - спасибо, завтра буду менять контроллер

Для очистки совести перед перепаиванием попробуйте ещё на других файлах eeprom этот эффект выловить. Я у себя на белорусском языке проверял.

Чудеса, загрузил ЕЕПРОМ английский - проблемы с индикацией будильника нет ( 1 час работало)
загрузил ЕЕПРОМ беларусский - проблемы с индикацией будильника нет ( 1 час работало)
аналогично украинский
загрузил снова русский, чудеса! работает уже пол дня все отлично
это я натренировал что ли ЕЕПРОМ

upd: рано обрадовался, проблемма вновь проявилась через 12 час работы

посмотрел код функции alarmRawWeekday()
не понятны
rawWeekday >>= 1;
rawWeekday |= 0x40; - заметьте это и есть та злощастная 1 которая при определенных ситуациях вылазит

поправил так

идея - устанавливаем 1 только в том дне на который установлено
2 часа полет нормальный - окончательно сообщу завтра когда более суток проработают
в моем варианте - четкая проверка - установлено пишем 1 в соответствующий бит дня недели

upd2:
почти сутки работы - с моими исправлениями глюка не наблюдается
плохо что его отловить не просто, он может проявится и через 5 мин, так и через 12 часов
потестим еще пару дней,
для очистки совести прошил старый вариант - посмотрю когда вылезет

upd3: глюк со старой прошивкой вылез через 25 мин
прошил свою - тестим до понедельника, чтобы сделать окончательно вывод

В последней прошивке вместо "Пятница" - " Пiтница"

Ничего подобного.




В цикле 7 раз (от 0 до 6, от понедельника до воскресенья) делаем сдвиг переменной rawWeekday, изначально пустой, устанавливая 6-й бит при необходимости (0b01000000 = 0x40). В итоге после всех битов понедельник (если будильник заведён) окажется младшим (0b00000001), воскресенье - старшим (0b01000000).
По идее, этот вариант равносилен Вашему. Раньше, кстати, так и было, но теперешний вариант компилируется в более компактный код, поэтому и использован.

очень доходчиво, но почему то при определенных условиях выдается неверный результат
если бы ваш код был не верен, всегда бы было неправильно
а тут непонятно может и через 5 мин вылезти может через день

сейчас уже 3 день с моим кодом проблеммы нет
я не настаиваю - применять или нет - решать вам

Значит у меня опять епром глюкнул

выложите скрин для понипрог фузоов для меги 8.......

пипец, что творится с JY-MCU-3208
после 4 дневной безупречной работы стало при выводе бегущей строкой выводить
"года 23.8 С, температура 737 мм. рт. ст, давление 43.9% КПа влажность"
похоже опять на слет ЕЕПРОМ

вкл выкл не помогает

Пробовали FUSE ставить в -U lfuse:w:0x24:m -U hfuse:w:0xd1:m? Т.е., настроить на 8МГц + уровень BODLEVEL=4В?

Я на других своих проектах сталкивался с повреждением EEPROM при отключенном BODLEVEl или с уровнем 2.7В. Суть в том, что когда напряжение питания снимается, есть риск каких-то случайных выбросов сигналов внутри контроллера во время чтения (даже не записи!) EEPROM, которые могут включить цикл записи в EEPROM. Поэтому теперь сразу ставлю этот уровень повыше, чтобы подобные выбросы исключались как можно раньше (уже на уровне 4В контроллер уходит в RESET, до возможного появления этих паразитных сигналов).

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

У себя на вышеуказанных настройках, кстати, я сбоев EEPROM не наблюдаю - ни на MAX7219, ни на HT1632. Хотя выключаю питание каждый день, уходя на работу.

Было такое при нескольких отключениях и включениях питания. Прошил фьюзы brown-out detection enabled [BODEN] и BODLEVEL=0 brown-out detection level at VСС=4.0 V и сбой EEPROM прекратился.

прошил фузы как рекомендовали
перепрошил флеш и еепром
спасибо, все восстановилось как надо, поглядим

Интересное дело - утром (воскресенье) будильник разбудил в 7 часов. Хотя вроде не наводил. Проверил - действительно, установлен был на воскресенье. Снял настройку, поставил для контроля режим маленького шрифта (с секундами и днями недели)

Вечером увидел горящую точку в воскресенье, пропавшую после снятия питания. Считывание eeprom показывает, что будильник не был взведён на воскресенье. То есть, на старте будильники вычитываются, а потом уже где-то в ОЗУ происходит сбой. При каких условиях - непонятно, какой-то неуловимый баг. По коду-то всё вроде правильно, но где-то ведь он взводится.

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

3 день полет нормальный - точка в воскр. не вылазит
размышления - если есть подозрение что при вызове процедуры alarmRawWeekday() происходит какое то прерывание и портит картину в ОЗУ, то может просто поставить
cli() в начале и
sei()
в конце - 2 байта всего

Может и так. Хотя можно и макрос ATOMIC_BLOCK попробовать.

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

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

Это только предположение, но пока пару часов код с заменой int8_t на uint8_t работает вроде бы без сбоев. Предлагаю Вам тоже проверить такой вариант для статистики. Всё-таки почти 20 байт экономии .

ставлю на тест ваш вариант - через пару дней сообщу результат

1 день работы - полет нормальный - тестирую дальше

2 день полет нормальный

в плане улучшения функционала мысли
автоповтор на + - кнопки (вроде сами хотели сделать)
переменная в ЕЕПРОМ - коррекции показаний давления - у меня врет на 5 единиц в минус

с точкой будильника похоже можно фиксить и включать в основную прошивку

Спасибо

У меня тоже 2 дня нормально. Казалось бы, банальная замена int8_t на uint8_t, разница в итоговой прошивке в один байт - а глюка нет. Исправление уже в git.

Коррекцию показаний давления чисто для себя можете и сами пока сделать. Хотя идея, в целом, неплохая, можно выделить ячейки в eeprom для коррекции датчиков.

Кстати, откуда уверенность в занижении на 5мм показаний? Я на narodmon.ru смотрел - мои результаты вроде похожи на то, что у людей в регионе. Кстати, на каком этаже меряете? Каждые 10 метров ведь на 1мм давление падает.