Тоже пришли часики версия PRO. прошил прошивкой matrixclock-0db99e8 последней выложенной здесь, проц мега8L установленная, результат на фото
перестало идти время все замерло фьюзы не трогал, хотелось бы пока без пояльника обойтись, подскажите пожалуйста, где накосячил? походу наверное все таки в фьюзах дело из за кварца. Потом попробовал вот такие фьзы поставить результат такойже пока что, но матрица стала мерцах от таких фьзов

У меня пошли, когда конденсаторы на кварц подпаял.

нужно припаять DS3231 и 2 резистора и перемычку по питанию на DS3231 - и они у Вас пойдут - и батарейку надобно еще чтоб время сохранялось

Я припаивал модуль для Ардуино с ебея. все работает.

М/с 3231 и ее обвязка вся установлена? Это скриншот фьюзов неправильный, указана Мега16.

конденсаторы возле меги на 22пф запаять? и еще выше рисунок с фьюзами который я показал как вернуть изначальные фьюзы, а то ведь мерцают они, обвязки нету на фото выложил выше как выглядит плата с другой стороны, да я понял уже что на 16 мегу фьюзы, но не умерли часики от этих фьюзов, а значит есть шанс их подправить, тока я не знаю уже какие ставить!

Если использовать только резисторы подтяжки на плате датчика давления (они есть?), они же подключены к 3.3В, а шина I2C построена на транзисторах с открытым коллектором (что и есть на самом деле), то макс. уровень на шине 3.3В - уровень лог. единицы, что достаточно для 5В устройств и безопасно для 3.3 вольтовых. "Нетолерантность" выводов скорее связана с наличием защитных диодов между выводом (анод) и плюсом питания (катод) что чревато при работе с двухтактным выходом подключаемой 5В логики. Но у нас только открытые выхода. Этот диод ограничит макс напряжение на шине на уровне 3.3В +падение на диоде. Поэтому макс. ток через защитный диод, при подключении подтяжки от 5В, определяется резистором подтяжки, и равен (5В-3.3В)/4.7КОм=0.36 мА, что скорее не смертельно, но проблема в том, что макс. ток через этот диод не нормируется, поэтому правильнее подтяжку запитывать от 3.3В.

Это правильно, если у Меги тоже открытый коллектор, но все не так просто - ибо шина двунаправленная, с одной стороны подтянуто к 5В, а с другой стороны подтянуто к 3,3В:
В даташите на мегу написано: и ни слова об открытом коллекторе - хотя открытый коллектор никогда не подтягивают резисторами внутри микросхемы - поэтому и обозван открытым. и в современных микросхемах стоят защитные диоды по входам которые спасают от завышенного напряжения на входе
В даташите на BMP180: - с Меги идет логическая единица в 5 Вольт что выходит за предельнодопустимый параметр по входу датчика и так как стоит резистор у датчика на 3,3В - то завышенное напряжение 5В также попадает на выход трехвольтового стабилизатора, что также может быть опасным (в стабилизаторах тоже иногда стоят диоды а могут и не стоять), обратно же с датчика идет 3,3В что не так страшно для меги.

Вот еще вырезка из даташита: 5*0,7=3,5

На самом деле, в даташите чётко прописано, что в режиме аппаратного I2C выход работает именно в режиме открытого стока.
В проекте, хотя и используется программный I2C, но тоже фактически в режиме открытого стока. Т.е. активная единица на выходах SDA/SCL не допускается программно в принципе. Либо активный ноль, либо неактивная (вывод в режиме входа) единица.
Именно. Это типичные диоды для защиты от статического электричествва, и они, как правило, достаточно мощные (по площади), так что мизерный ток 100мкА (5-3,3-0,7В)/10кОм им повредить не должен. Хотя вообще так делать нехорошо, согласен.

Вообще у датчиков BMP180 в этом проекте (я имею в виду ATmega8) какие-то печальные перспективы. Сегодня вечером, повозившись с ними отдельно, понял, что в ATmega8 это не влезет вообще никак. Там столько операций деления 16 и 32-битных чисел при работе с калибровочными коэффициентами, что расчёт температуры/давления требует около 2,5кБайт flash-памяти.
Нужно либо каким-то чудом уменьшить размер прошивки на четверть, чтобы это влезло, либо перепаиваться на 168/328 мегу, что мне делать не очень хочется.

А так датчики вполне у меня заработали, проблема только в размере кода.

8МГц от внутреннего генератора. В исходниках проекта (Makefile) ясно видно, что Fuse-биты должны быть:lfuse = 0x24 и hfuse = 0xd1. Точно так же видно, что эта прошивка предназначена для работы с аппаратными часами на базе DS1307 или DS3231 (для этого варианта есть посадочное место на плате плюс батарейка для хранения времени). Программной реализации часов, как в родной китайской прошивке, здесь нет.

Может все же перепаять? Будет больший простор для дальнейшего развития проекта.

Спасибо с фьюзами на сайте по указанной вами ссылке выставил нужные фьюзы! Прошился заново на всякий случай, но eeprom залить не могу ругаеться, не могу понять зачем пока он на него ругаеться! шью через CodeVision AVR.

Будем делать без преобразователя уровней) Я встречал такое решение даже в оборонке.
Я тоже за переход на более "жирный" контроллер. Мега328.

Здравствуйте.

В начале форума поэтому я и писал о применении dip корпуса.
Плату рисую под dip корпус и когда появится модификация под другой МК
просто вставлю другой. Применение корпуса TQFP целесообразно когда
развитие конструкции не предусматривается.

Ну это личное мнение.

У ATmega 8/48/88/168/328 цоколёвка одинаковая как для DIP, так и для QFP корпуса. Так что потенциальное развитие конструкции тут ни при чём.

Может быть, завтра съезжу на радиорынок для покупки ATmega168 (или 328).

Я про удобства.

При dip корпусе вынул-вставил, а при TQFP необходима пайка 32 выводам.

Обновление прошивки.

- Оптимизация кода.
- Изменения в структуре EEPROM для будущих датчиков давления/влажности
- Максимальное число температурных датчиков (и текстовых меток в EEPROM для них) увеличено до 4

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

Если кто-то использует ATmega168 или ATmega328, он может в прошивке для BMP180 вернуть поддержку будильника назад - в эти МК влезет и будильник, и датчик давления Для этого просто надо раскомментировать закомментированые строки и пересобрать прошивку под свой МК (переменная MCU в Makefile). А я позже всё-таки попытаюсь вместить всё это в ATmega8.

а как с помощью AVR Studio прошить ЕЕПРОМ, там только HEX, а файл BIN

Не знаю, я под Linux код пишу, на "чистом" avr-gcc и шью с помощь avrdude. Если AVRStudio не умеет прямо писать бинарные форматы, самым простым выходом вижу вариант с их преобразованием из binary в ihex:

обьясните как с помощью дуде прошить БИН в ЕЕПРОМ
по виндой у меня в SinaProg выбор файла для загрузки в ЕЕПРОМ вообще не активно
может как то можно чтоб и файл для ЕЕПРОМ тоже был HEX

update
с помощью утилиты преобразовал в кекс - прошил
часы повели себя по другому. но не так как надо
на матрице фигня
кнопки не работают - бум разбираться
использую мега328 и матрицы с SMD max7219 32x32

В Makefile в качестве LED_DRIVER можно указать:

HT1632 - для китайской платы J-MCU 3208 Pro, там своя разводка кнопок и прочего
MAX7219 - для схемы в статье
MAX7219MOD - то же, но с поворотом матриц на 90 градусов - так разведены "готовые" китайские модули.

Соответственно, скрипт build_all.sh генерирует все варианты прошивок.

В pins.h вся разводка для всех вариантов приведена. Кнопки, как обычно, срабатывают при закорачивании на землю.

В том же Makefile можно увидеть и строку avrdude для прошивки. В частности, прошить из каталога проекта:

Flash в Intel Hex формате:

Eeprom в Raw (binary) формате:

Естественно, программатор (-c usbasp) и порт (-P usbasp) нужно подставить свои.

Если прописать правильные их значения в Makefile (там есть для этого нужные закомментированные строки), вся работа с прошивкой будет сводиться к командам из консоли:

make clean - очистить исходники от старых объектников от предыдущей прошивки
make LED_DRIVER=MAX7219MOD - собрать соответствующий вариант прошивки
make LED_DRIVER=MAX7219MOD flash - прошить flash
make eeprom_by - прошить eeprom
make fuse - прошить Fuse-биты

Аналогично, любую IDE можно настроить на вызов этих команд из Makefile, что я с успехом использую в QtCreator.