Часы на ГРИ v2. Задания на доработку
- Автор темы MyrZZik
- Дата начала
@Sergo_ST, если идти вот так, "в лоб", то написать приёмную часть этого взаимодействия несложно. Надо только придумать "протокол", совершенно не проблема.
Я говорил несколько о другом. Оригинальная конструкция многого не имеет в принципе. По сути, это только часы, без секунд, с эффектами переключения цифр. Без будильника (звука), нормального управления подсветкой, метеоданных... Многие собирают всё именно так, но тогда - что такого сложного нужно настраивать? В качестве основы "оригиналы" достаточно "благодарны", но добавление всех этих "фич" занимает выводы. Не буду говорить о всех реализациях, участвовал только в COVID-19, там эти TX/RX просто заняты другим "оборудованием". Т.е., просто подпаяться к этим выводам - не получится. Для того, чтобы такую конструкцию сделать хотя бы повторяемой, нужно освободить эти выводы непосредственно на плате, одновременно предусмотрев место для блютус модуля. Не вижу здесь тоже больших проблем, просто по сравнению с лобовым вариантом сложность реализации несколько возрастает.
Почему я упомянул I2C: можно подпаяться к любой существующей плате (как минимум во всех них есть DS3231 с таким интерфейсом) и сделать своеобразный плагин. Кстати, такие модули существуют, как-то раньше я этим просто не интересовался. В частности, на nRF51822.
Я говорил несколько о другом. Оригинальная конструкция многого не имеет в принципе. По сути, это только часы, без секунд, с эффектами переключения цифр. Без будильника (звука), нормального управления подсветкой, метеоданных... Многие собирают всё именно так, но тогда - что такого сложного нужно настраивать? В качестве основы "оригиналы" достаточно "благодарны", но добавление всех этих "фич" занимает выводы. Не буду говорить о всех реализациях, участвовал только в COVID-19, там эти TX/RX просто заняты другим "оборудованием". Т.е., просто подпаяться к этим выводам - не получится. Для того, чтобы такую конструкцию сделать хотя бы повторяемой, нужно освободить эти выводы непосредственно на плате, одновременно предусмотрев место для блютус модуля. Не вижу здесь тоже больших проблем, просто по сравнению с лобовым вариантом сложность реализации несколько возрастает.
Почему я упомянул I2C: можно подпаяться к любой существующей плате (как минимум во всех них есть DS3231 с таким интерфейсом) и сделать своеобразный плагин. Кстати, такие модули существуют, как-то раньше я этим просто не интересовался. В частности, на nRF51822.
@Sergo_ST, я блютузами не пользуюсь. Мне с ESP8266 проще. Причём, без связки с Arduino. А если и привязывать что-то к этим часам, то, по-хорошему, нужен лишь протокол обмена (или хотя бы приёма - только в Ардуино) командами через UART. Тогда и с ПК можно было бы терминалом время установить. (А если протокол приблизить к GPS-посылкам, чтобы парсинг не утяжелять, то вообще будет без разницы, что подключать - то есть не обязательно иметь на борту этот модуль постоянно.)
@poty, а если сам ESP-01 использовать как I2C-слейв? (Есть библиотека, в которой заявлена устойчивая работа мастером, но не слейвом. Не пробовал, но тут есть источник проблем. В теории GPIO0/GPIO2 подтянуты вверх - и это требуется для старта модуля. Если при подаче питания кто-то дёрнет шину вниз, ESP не будет работать, как ожидается. Например, если при старте GPIO0=LOW, ESP перейдёт в режим программирования...)
Но если уж заморачиваться, то почему бы не взять ESP-12E/F или уже с обвязкой что-то типа Wemos D1 Mini? Тут уже можно городить полноценный I2C-клиент.
Но не проще ли взять ESP8266 как основной процессор? Это, конечно, другая схема будет (и такие схемы известны), другие часы...
@poty, а если сам ESP-01 использовать как I2C-слейв? (Есть библиотека, в которой заявлена устойчивая работа мастером, но не слейвом. Не пробовал, но тут есть источник проблем. В теории GPIO0/GPIO2 подтянуты вверх - и это требуется для старта модуля. Если при подаче питания кто-то дёрнет шину вниз, ESP не будет работать, как ожидается. Например, если при старте GPIO0=LOW, ESP перейдёт в режим программирования...)
Но если уж заморачиваться, то почему бы не взять ESP-12E/F или уже с обвязкой что-то типа Wemos D1 Mini? Тут уже можно городить полноценный I2C-клиент.
Но не проще ли взять ESP8266 как основной процессор? Это, конечно, другая схема будет (и такие схемы известны), другие часы...
Так об этом и речь. Просто терминал - это для упёртых админов, не каждый сможет командами at пользоваться, как сейчас модно говорить, usability - не на высоте будет. А вот если приложение сделать, то никто и знать не будет, что там посередине - блютус или Wi-Fi?
Вот это - очень заманчивое решение. Немного бы меня подтянуть в этом вопросе (где почитать) - я бы попробовал. Надеюсь, с программированием справлюсь, ничего сложного, думаю, там нет.
Вот здесь, думаю, не проще. Я потихоньку двигаюсь в этом направлении, но в известных реализациях многие отмечают не очень плавную работу функций реального времени при проблемах с сетью. Видимо, несколько реал-тайм процессов не уживаются на одном проце, несмотря на существенно большую частоту.
Кроме того, никак не могу понять, почему аппаратный PWM ограничен 1000Гц? Это значит, DC/DC преобразователь нужно делать на внешней микросхеме и нужно где-то взять адекватное тактирование для динамической индикации и эффектов.
Изменено:
На сколько я знаю, ESP очень узко специализирована на работе с веб, поэтому не думаю что это хорошая идея полностью строить на ней часы(по крайней мере нужен внешний преобразователь и желательно драйвер для управления лампами)...
Опять же, не утверждаю, тк с ними особо не работал(только UDP обмен данными), плюс специфичный язык программирования LUA(мне C как то ближе).
В общем для себя сделаю на BT модуле, исходники выложу, мб кому пригодится...
Опять же, не утверждаю, тк с ними особо не работал(только UDP обмен данными), плюс специфичный язык программирования LUA(мне C как то ближе).
В общем для себя сделаю на BT модуле, исходники выложу, мб кому пригодится...
Какое то время назад я начал для одних проприетарных часов делать управление по web, но так как я в веб не сильно продвинут, то пока жду странички от опытных разработчиков 
И через какое то время до меня дошло что таки можно просто по USB управлять каким то приложением (там выше все правильно написано)
Вылиллось вот в такое приложение, (закрытое): Я не дизайнер как мог делал:
И да, часам будет пофиг, что с другой стороны, есп, пк, блютус.. главное что бы оно могло понимать и отвечать на нужные команды, коих с десяток наверное
И через какое то время до меня дошло что таки можно просто по USB управлять каким то приложением (там выше все правильно написано)
Вылиллось вот в такое приложение, (закрытое): Я не дизайнер как мог делал:
И да, часам будет пофиг, что с другой стороны, есп, пк, блютус.. главное что бы оно могло понимать и отвечать на нужные команды, коих с десяток наверное
@poty, терминал - это не про AT-команды, а про терминальную программу. Хотя бы по типу того монитора порта, что в Arduino IDE встроен, - он позволяет строку отправить, типа "T=151847,D=20210327" или иной какой, чтобы контроллер вытащил дату-время из неё и установил. Если делать для Wi-Fi/BT, то можно слать разные конфигурационные параметры, чтобы отобразить или установить их. Типа в МК отправляешь "T=?,D=?,CFG=?", а в ответ приходит "T=151847,D=20210327,AT=0715,AD=W,NTB=2300,NTE=0700..." (с выводом времени и дней недели будильника, начала-конца ночного режима и прочего). Эти параметры отображает программа/web-страница для настройки, исправленное засылает обратно в МК. Можно слать не весь конфиг, а запрашивать его кусочками по параметру или по блоку параметров - это уже детали, которые можно потом обсудить.
А вот real-time и ESP8266 - это не совсем совместимые категории. Потому и ограничение частоты ШИМ в 1 кГц (можно меньше - от 100 Гц), что ШИМ формируется программно. Ну нет у esp8266 того изобилия аппаратных возможностей, как у Atmega328P, в том числе, таймеров. Программно почти всё, даже поддержка I2C (потому и работает на любых выводах, кроме GPIO16).
Надо, конечно, упомянуть, что есть в ESP8266 аппаратный ШИМ аж на 312 кГц, но отмечается, что при его работе такие помехи прут, что его использование не совместимо с Wi-Fi.
Конечно, ESP8266 не так хорош (и не так документирован, к слову), как Атмеги, но и его используют в коммерческих проектах. И его вполне можно приспособить для часов. Да, нужна обвязка - неизбежно. И обвязка по последовательным интерфейсам - выводов-то всего ничего. И потому в обработчике прерывания уже не получится установить комбинацию для К155ИД1. И для питания придётся ШИМ-контроллер использовать... Но я пару недель назад собрал часы на ESP8266 - работают... Программа пока чужая - это вопрос времени.
Но давайте разделим темы: 1) ESP8266 как источник точного времени для текущего проекта и 2) ESP8266 как ядро часов на ГРИ.
А вот real-time и ESP8266 - это не совсем совместимые категории. Потому и ограничение частоты ШИМ в 1 кГц (можно меньше - от 100 Гц), что ШИМ формируется программно. Ну нет у esp8266 того изобилия аппаратных возможностей, как у Atmega328P, в том числе, таймеров. Программно почти всё, даже поддержка I2C (потому и работает на любых выводах, кроме GPIO16).
Надо, конечно, упомянуть, что есть в ESP8266 аппаратный ШИМ аж на 312 кГц, но отмечается, что при его работе такие помехи прут, что его использование не совместимо с Wi-Fi.
Конечно, ESP8266 не так хорош (и не так документирован, к слову), как Атмеги, но и его используют в коммерческих проектах. И его вполне можно приспособить для часов. Да, нужна обвязка - неизбежно. И обвязка по последовательным интерфейсам - выводов-то всего ничего. И потому в обработчике прерывания уже не получится установить комбинацию для К155ИД1. И для питания придётся ШИМ-контроллер использовать... Но я пару недель назад собрал часы на ESP8266 - работают... Программа пока чужая - это вопрос времени.
Но давайте разделим темы: 1) ESP8266 как источник точного времени для текущего проекта и 2) ESP8266 как ядро часов на ГРИ.
@gcat, мне ситуация непонятна. Во всех случаях DUTY влиять должен, причём заметно (либо напряжением, либо нагревом деталей). Предполагаю, что есть где-то значительная утечка тока в высоковольтной части, не позволяющая напряжению подняться. Здесь многие говорят про неотмытый флюс или другое замыкание контактов, но это бы проявлялось фантомными цифрами или цифрами, которые на зажигаются. Весьма вероятно, что дело в неправильном сопротивлении в анодной цепи: если оно слишком маленькое, то лампы будут выступать в качестве своеобразных стабилитронов, просто сбрасывая напряжение в ток через себя. Но тогда индикаторы бы, скорее всего, светились достаточно ярко. Возможно, какие-то утечки в высоковольтном конденсаторе, но тоже не всё сходится (>300В на холостом ходу). Чуть выше по ветке была проблема с входным 5В, но и конденсатор имеется, и измерение проводили.
Как вариант - что-то не так с измерительным прибором (например, маленькое входное сопротивление, шунтирующее высоковольтный конденсатор). Ещё может быть вариант со слишком большой индуктивностью дросселя.
Так как преобразователь напряжения здесь очень простой (ключ-MOSFET, дроссель, диод и конденсатор), то чудес быть не должно. Надо искать, как мне кажется, во внешних цепях.
Как вариант - что-то не так с измерительным прибором (например, маленькое входное сопротивление, шунтирующее высоковольтный конденсатор). Ещё может быть вариант со слишком большой индуктивностью дросселя.
Так как преобразователь напряжения здесь очень простой (ключ-MOSFET, дроссель, диод и конденсатор), то чудес быть не должно. Надо искать, как мне кажется, во внешних цепях.
Всё же хотелось бы чего-нибудь попроще в этом качестве, но начать можно и с этого.
@poty, попроще - это как раз терминал (монитор порта из Arduino IDE) и парсинг строки, полученной через Serial. Тогда и "посложнее" будет таким же, только подключаться будет не ПК по проводу, а BT- или Wi-Fi-адаптер.
Я про попроще говорил про простейший Web-сайт на самом маленьком модуле. Как его подключать к Ардуино - вопрос второй.
Так и я про то:
Но шаги 1 и 2 делать придётся для любого способа управления из предложенных.
- Проектируем протокол - систему команд/ответов (по типу "T134511" для установки времени или ответа о текущем времени, "T?" для запроса, аналогично про дату и другие конфигурационные параметры). Для унификации шлём только символьные строки.
- Добавляем в прошивку часов парсер строки, полученной из Serial, и формирователь ответов на запросы для отправки в Serial.
- Часами уже можно управлять с ПК через USB-UART на плате Arduino.
- Пишем web-морду для ESP-01 (или иной платы на ESP8266 - процессор-то одинаковый, только у ESP-01 не все выводы наружу оформлены), учим модуль получать и отправлять данные с UART (RX/TX). Соединяем по RX/TX модуль и Arduino - часами можно управлять по Wi-Fi через web-морду.
- Если подключим ещё один GPIO от ESP к Reset Arduino, то получим возможность прошивать часы "по воздуху". (Если используется ESP-12E/F, то есть памяти хотя бы 8 мегабит (1 мегабайт), то и ESP можно прошивать "по воздуху"...)
- Аналогично для BT: пишем программу для смартфона, подключаем BT-модуль к RX/TX.
Но шаги 1 и 2 делать придётся для любого способа управления из предложенных.
Берете наш фреймворк EmbUI, из коробки получаете синхронизацию времени, mqtt, веб-приложение, локализацию и т.д.
Затрат на написание 0. Как может выглядеть интерфейс поглядеть можно в ветке лампы. Фреймворк открыт и доступен всем в гите.
А можно эти часы перевести с платформы нано на esp32 (c wifi). Добавится возможность сделать синхронизацию по wifi (web морду) связь с удаленными датчиками ... Достаточно переделать соединение под esp32 и пере развести плату если назначения контактов изменится, отпадет необходимость держать модуль часов реального времени (периодически синхронизировать и от встроеного генератора поддерживать ход часов).
Избыточное цитирование. Отредактируй или сообщение будет удалено
нет. esp не хватит на все со всеми фишками и подсветками. чисто часы. я добавил просто esp32 в сам проект. и это работает. но. модуль времени все равно обязателен. и это далеко не просто переразвести дорожки.
Изменено: