Часть 1. Лирическая
Современный мир немыслим без огромного количества электронных и электрических помощников. Начиная от компьютеров и смартфонов, заканчивая простым выключателем света на кухне и автоматом защиты ввода. Так или иначе со всеми устройствами приходится взаимодействовать. С какими то чаще, например смартфон, который некоторые вообще не выпускают из рук, с какими то реже, тот же автомат защиты ввода в квартиру, о существовании которого некоторые даже не догадываются.
У совсем простых устройств интерфейс примитивный. Кнопка или тумблер, несколько кнопок для термостата, например. Характеристики задаются производителем и не меняются потребителем. Ток отключения 10А, 16А, 25А… Коммутация до 6А 230В… Но когда устройство чуть сложнее, все становиться очень плохо.
Немного отвлекусь, расскажу о своей неудаче как раз из-за аппаратного интерфейса. Возникла задача распределения нагрузки для частного дома. По сути — многоканальное программируемое реле времени. Сделал прототип буквально за вечер, поставил заказчику, заказчик, сосед по дому, оказался доволен, я решил попробовать наладить мелкосерийное производство, организовать небольшой электронный стартап деревенского масштаба, так как проблема нехватки вводных мощностей актуальна для частного сектора. Осталась одна проблема дизайна — конфигурация прибора. В прототипе интервалы были забиты просто в «фирмварь», если 200 ассемблерных команд так можно назвать. Пару раз пришлось корректировать уставки, делалось это просто сборкой новой прошивки и обновлением по средствам программатора. Понятно, что для серийного, даже мелкосерийного устройства такой метод не подойдет.
Тут я столкнулся со всеми «прелестями» разработки аппаратного пользовательского интерфейса… Простые методы, типа записать 16 вариантов уставок и поставить ползунковый переключатель не давали требуемой гибкости, делать какой либо серьезный интерфейс для связи с ПК или смартфоном — неоправданное усложнение, удорожание. К тому же сразу возникает необходимость разработки пусть и простого, но кросс платформенного приложения (Win / Linux / Android / iOs). Но и это не главное. По сути, пользователь один раз настроит прибор при установке и, в идеале, больше о нем не вспоминает.
В отличии от прототипа, на лицевой панели прибора появился 4х разрядный LED индикатор, кнопочки, светодиоды. Функционал тоже добавлялся, фичи задержек включения нагрузки после перебоя с сетевым питанием, дополнительные режимы для питания от ЛЭП или резервного генератора, подержание температуры непромерзания…
А вот и масса-габаритный макет этого монстра Франкенштейна
(Управляет контакторами, внутри слаботочные цепи коммутации катушек)
Пока присутствовал функционал только программируемого реле, с настройками было не сложно, созданный аппаратный интерфейс оправдывал себя. Но в какой то момент инструкция по конфигурации стала превышать объем кода «фирмвари». Изначальная идея: пользователь сканирует QR код на панели прибора, переходит на страницу с инструкцией — провалилась. Остается либо делать очень простой девайс, либо искать другой метод общения с устройством. Потенциальные покупатели (отважные тестировщики) очень долго разбирались в настройке по инструкции.
Самое печальное, у меня есть прототипы нескольких устройств, которые однократно настраиваются и живут своей жизнью в электрическом щите. Конфигурация — десяток другой байт. Осталось найти подходящий интерфейс.
Что мы имеем на сегодня? Сравнение «классических» способов настройки:
- Выбор из готовых конфигураций. ЗА: Легко реализуется как программно, так и аппаратно. Дополнительные аппаратные доработки минимальны. Пользователю не надо иметь специального оборудования, достаточно инструкции. ПРОТИВ: Отсутствует гибкость, не интуитивно, требуется наличие инструкции.
- Последовательность нажатий с обратной связью через простую индикацию (аналогично настройке обычных электронных часов). ЗА: Легко реализуется программно, пользователю не надо иметь специального оборудования, достаточно инструкции. ПРОТИВ: Не интуитивно, сложно настроить большое количество параметров, невозможность клонировать настройки, что является критичным для компаний — инсталляторов.
- Конфигурация с использованием стандартного проводного интерфейса. ЗА: Интуитивно, если хорошо написано приложение, легкое клонирование настроек, относительно простая реализация, возможно, не очень дорогие аппаратные доработки, возможность обновления firmware. ПРОТИВ: Пользователь должен иметь оборудование, как минимум компьютер или ноутбук с USB портом, преобразователь интерфейсов, если Ваш прибор предоставляет что-то отличное от USB или Ethernet. Необходимость разработки приложения.
- WiFi + WEB – стрельба из пушки по воробьям и махровая ардуринщина. Но идея неплохая. ЗА: аналогично проводному соединению, нет необходимости разрабатывать кросс платформенное приложение, предоставив встроенный WEB интерфейс конфигуратора, пользователю достаточно иметь любое устройство с поддержкой WiFi и браузером. Даже не обязателен доступ к глобальной сети. Возможно, этот дизайн будет дешевле, чем аппаратные кнопки / индикаторы, так же упрощается корпус. ПРОТИВ: Технически крайне некрасивое решение, переводящее изделие совсем в другой класс устройств. Понижается надежность работы, как из-за усложнения прошивки, так и возросшей чувствительностью к ЭМП.
Резюмирую, что одно из самых красивых решений с точки зрения пользователя — последнее. Но оно и одно из самых ужасных с точки зрения инженера. Я на нем почти остановился, но…
Техническая кривизна не давала покоя. Для того, чтобы записать несколько байт в EEPROM городить огород с таким обширным стеком протоколов нерационально. Но, похоже, я нашел решение своей проблемы, вот характеристики этого метода:
Плюсы:
- Удорожание аппаратной составляющей сравнимо с решением «выбор из готовых конфигураций», рублей 10 — 15. А возможность отказаться от лишних кнопок, индикаторов и т. д. дают, скорее, удешевление.
- Программная реализация не представляет проблем.
- Не требует разработки специального приложения. При желании — приложение можно предоставлять.
- Интуитивность зависит от качества разработки WEB конфигуратора или приложения.
- Гальваническая развязка с прибором.
Минусы:
- Низкая скорость передачи данных в сравнении с проводным или радио интерфейсом.
- Необходим физический контакт с прибором.
- Нужен хотя бы однократный выход в Сеть.
К тому же, данный метод передачи информации очень распространен в природе. Это — звуковая волна.
Сейчас смартфоны есть, пожалуй у каждого. Нет смартфона — подойдет любое устройство для воспроизведения звука, хоть кассетный плеер. Как я вижу такой интерфейс в действии:
- Пользователь инсталлирует прибор согласно инструкции.
- Создается требуемая конфигурация прибора, прописываются необходимые режимы и уставки.
- Пользователь переводит прибор в режим конфигурации, например специальной последовательностью нажатия клавиши, прибор отображает состояние готовности, допустим миганием светодиода с частотой 5Гц.
- В конфигураторе нажимается пиктограмма «передать параметры», после чего начинает воспроизводиться кодированная звуковая последовательность (а кто в 90х игры с кассет грузил?).
- Пользователь дожидается окончания загрузки данных в прибор (допустим, светодиод стал постоянно включенным) и нажимает пиктограмму «остановить передачу».
Все, новые параметры переданы в прибор. Как думаете, такой способ конфигурации будет достаточно удобен?
Вместо послесловия
Я специально не затрагивал техническую часть реализации. Каждый случай может быть индивидуальным, подход — общая идея. Если статья вызовет интерес, опубликую вторую часть. Практическую. Пока спойлер: затея увенчалась успехом, макет на 8 битном PIC16 + «студенческая» версия компилятора Си без оптимизации, в том числе и ручной, прошивка спокойно уложилась как по памяти (около 1KB), так и по производительности. Самая «тяжёлая» математическая операция — сложение sint8_t и sint16_t. По предварительным расчетам, ядро звукового конфигуратора, переписанное на Ассемблере, уложится менее чем 512 килослов и производительности 2MIPS у PIC16F819 должно хватить.
Всего наилучшего,
Константин.
Комментарии (58)
AlanDrakes
26.09.2019 14:31Забавно. Прямо несколько минут назад прочитал статью «Кнопка Amazon Dash: ретроспектива» — habr.com/ru/post/468913
И в данном устройстве работает тот же принцип передачи конфигурации.
Всё придумано до нас :(
nonpar
26.09.2019 14:47Я в случаях, когда девайс требует редкой настойки, вывожу вход/выход USART TTL и общий/питание на 4-контактный разъем, и на время настройки подключаю к нему Bluetooth модуль, после чего можно работать через терминальную программу на смартфоне. Но это решение для себя, не уверен, что оно подойдет простому юзеру.
lingvo
26.09.2019 15:19Проблема в том, что как только появляется канал связи с устройством и разрабатываются соответствующие протоколы и реализации, следующим вопрос будет: "ОК, параметры программировать можем. Но теперь хотим иметь возможность передавать информацию и в обратном направлении". И во многих случаях это приводит к полной переработке интерфейса.
В вашем устройстве может произойти то же самое: пока 4-х семисегментников достаточно, но микроконтроллеры дешевеют, памяти в них полно, так почему бы дать возможность пользователю увидеть больше, чем показывают ваши светодиоды? Например смотреть все измерения одновременно, записывать логи на компьютере и т.д.
Лично я закладываю в свои изделия такое:
- параметры пишутся во внешнюю EEPROM типа 24LC в DIPовском корпусе на панельке. Если надо перенести их на другое устройство/плату из-за неисправности или еще — просто выковыриваешь и вставляешь в другую плату. Массово программировать можно на программаторе.
- Для телефонов будет BT модуль (опциональный) с приложением. Позволит как программировать параметры, так и наблюдать за работой изделия в реальном времени. Протокол там простой последовательный, так что любой микроконтроллер справится.
Alexeyslav
26.09.2019 15:36Чтобы выковырять и вставить надо разобрать полностью устройство и получить доступ к внутренностям. Это точно для простых пользователей? EEROM в DIP-корпусе да ещё с панелькой по нынешним меркам занимает чудовищно много времени.
lingvo
26.09.2019 16:08Я видел такие решения довольно часто. EEPROM может находиться под крышечкой.
Alexeyslav
26.09.2019 16:26Черт, опечатался. То что времени на разборку устройства много надо, там же сама микросхема с панелькой много места занимает, особенно по высоте. Всякие там накладные выключатели и прочее в пролёте. А ещё попробуй выковырять тот чип без практики так чтобы не погнуть выводы… это решение для профессионалов, и то они тратить время на такую ерунду не будут — оставят внешний интерфейс и просто будут подходить к девайсу и «прошивать его» подключаясь к этому интерфейсу — минимум действий, минимум времени. На счетчиках электроэнергии примерно так и сделано — интерфейс оптический.
darkdaskin
26.09.2019 16:43В обратном направлении можно тоже звуком передавать. Пищалки стоят ещё дешевле микрофонов, с генерацией звука любой микроконтроллер справится.
Такой способ использует, например, LG в своей бытовой технике.
D01
26.09.2019 15:57Не проще ли подключить флешку с обычным ini файлом?
lingvo
26.09.2019 16:10Для флешки нужно на контроллере файловую систему поднимать. А это очень много кода для PICа.
D01
26.09.2019 17:49Можно что-то аналогичное, но тогда надо поставлять с переходником, вытащил из устройства, вставил в коннектор и в комп, поменял параметры, воткнул обратно. Но так надо будет много дополнительного софта.
Ну и еще вопрос: а точно ли это затратней, чем штука, которая будет распознавать звуки?)
Пользователю намного проще отредактировать текстовый файл.lingvo
26.09.2019 18:02Я не знаю. Поэтому в своих изделиях заложил коннектор для MicroSD карт(благо в ARMы простенький файловый стек легко входит), но вряд-ли SD карта будет использоваться для параметров, скорей всего для логов или обновления прошивки.
В одном изделии, например, у меня стоит речевой информатор, поэтому на карте хранятся wav файлы с именами 1_ru.wav, 2_ru.wav и т.д. в которых записаны слова "первый", "второй" и т.д. Нетрудно догадаться, что можно сделать _en файлы и провести интернационализацию. Ну а кто хочет, может перезаписать вообще свои образцы голоса.
PS, кстати, не стоит забывать достоинство этого метода в том, что все параметры можно настроить дома или в офисе в удобном, теплом месте, а на (холодном/темном/труднодоступном) объекте просто вставить нужную карту/флешку/EEPROMку без возни с кнопками и необходимости брать с собой инструкцию.
FGV
26.09.2019 19:11WiFi + WEB – стрельба из пушки по воробьям и махровая ардуринщина.
а причем тут адурина? можно и без нее.
Понижается надежность работы, как из-за усложнения прошивки, так и возросшей чувствительностью к ЭМП.
Ну с прошивкой бог с ней, сложнее, от прямоты рук программиста больше зависит. Но чувствительность к эмп? Это что ж за условия такие, в которых девайсина работает?
jakushev Автор
26.09.2019 19:401. Конечно можно без нее. Это метафора о топорном, прямолинейном решении, отлично подходящем для хобби, но не для производства.
2. Повышение сложности ПО ведет к повышению вероятности ошибок. От этого никуда не деться. Понятно, что wifi стек с 0 никто не будет писать, а готовые библиотеки не гарантируют отсутствия багов.
3. Прибор работает бок о бок с контакторами (коммутация 230V — 400V, 25 — 40А на «фазу»).lingvo
26.09.2019 20:00Повышение сложности ПО ведет к повышению вероятности ошибок.
Тут, как бы палка о двух концах. WiFi стек вы на своем PICe подымать не будете — такие решения обычно идут вместе со своим контроллером, который будет отвечать за WiFi и WEB и все с ними связанное. В этом случае вам будет удобно разделить функции между двумя контроллерами, оставив PIC управлять ответственными вещами, а на WiFiечный контроллер посадить GUI, параметризацию, управление кнопочками, WEB, логи и т.д. В этом случае софт PICа даже упростится, так как он будет отвечать за меньший функционал, основная функция системы станет надежнее — если с ВаФаем что-то случится, PIC продолжит работать. Это в принципе достаточно распространенная архитектура встраиваемых систем управления — не самая дешевая по железу, зато удобная в разработке — код простой, реалтайм с нереалтаймом разделен физически(поэтому часто в таком случае ОСРВ на управляющем контроллере не нужна вообще), возможность работы командой — одна пилит стек, другая PIC, возможность независимых апгрейдов каждого модуля в отдельности, легкий апгрейд FW, защита от хакерских атак и т.д.
jakushev Автор
27.09.2019 12:12Именно так я поступаю на сложных проектах. В статье идет речь об очень простых устройствах. Которые надо конфигурировать один — два раза. Например, в одном из относительно сложных контроллеров я даже с ESP не стал связываться, сразу заложил модуль на OpenWRT. Жалко, что наш Черный Стриж загнулся, заложил бы его, а не noname из Китая…
Alexeyslav
27.09.2019 13:37Можно и без ардуины, только стоимость решения сразу вырастет до небес. Веб-сервер под АРМ, интерфейс настройки, все необходимые скрипты сами писать будете? И сколько на это уйдёт времени?
FGV
27.09.2019 14:28Веб-сервер под АРМ, интерфейс настройки, все необходимые скрипты сами писать будете?
Зачем на арм? речь идет о копеечных esp8266/32, которые вполне себе тянут простейшие http сервера. А скрипты чего их писать то? одна страничка с настройками, и ничего лишнего.
И сколько на это уйдёт времени?
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/examples/protocols/http_server
Alexeyslav
27.09.2019 15:06Так там и есть ARM ядро. Ардуино-подход как раз и предполагает взять всё готовое и добавить сверху своих связующих соплей. А тут вам надо будет реализовать серверную часть сайта, как минимум.
FGV
27.09.2019 15:26Так там и есть ARM ядро.
Пишут что вот это внутрях:
L106 32-bit RISC microprocessor core based on the Tensilica Xtensa Diamond Standard 106Micro running at 80 MHz.
А тут вам надо будет реализовать серверную часть сайта, как минимум.
Ага, понятно, по ссылкам не ходим и не читаем. Вот например http сервер, поставляется прям вместе с ESP-IDF от espressif:
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/protocols/esp_http_server.html
Осталось только прикрутить к нему обработчики и свою страницу. Это день-два, по первой может неделя, пока с апи разберешся.
neco
27.09.2019 07:22в качестве варианта идеи пульт от теливизора? они есть у каждого. да там свой головняк со стандартами кодов сигналов но можно подумать…
jakushev Автор
27.09.2019 12:15И с инструкцией и обратной связью… Не будет пользователь вбивать 20 / 30 байт с пульта, даже если программа — конфигуратор отобразит последовательность. Я этот тип отношу к типу 2, рассмотренному в статье.
shiotiny
27.09.2019 10:58Выскажу свое скромное мнение.
Техническая кривизна не давала покоя. Для того, чтобы записать несколько байт в EEPROM городить огород с таким обширным стеком протоколов нерационально.
А зачем вам САМОМУ городить стек протоколов? Есть же готовые решения. И стоят они не дороже, чем ваши доработки по звуку.
Ваша идея со звуком — требует смартфона и спец. приложения.
Смартфон и так есть у всех (как вы сами описали тут). Это плюс. А спецприложение это минус. На все случаи жизни его не сделаешь.
Так почему не нравится «WiFi + WEB»?
Стоимость контроллера ESP8266 — около 100руб. Это очень дешево.
Как показала моя разработка (см. мои статьи о ShIoTiny или сайт) — на нем можно сделать развитый интерфейс практически с любой степенью удобства.
Мой редактор схем не заточен для мобильников. Но сделать отдельную страницу ввода параметров, доступную пользователю — не проблема. И заточить ее под мобильник тоже не трудно.
В общем, я думаю, что не надо плодить сущности. Надо по максимуму использовать то, что есть и по минимуму требовать от пользователя установки дополнительного ПО на смартфон.
Кстати, ваша идея — конфиг устройств с помощью звука — скорее всего очень подойдёт для подводных устройств. Звук в воде распространяется хорошо, а вот свет не всегда — мутная вода. Радиоволны тоже под водой не хотят распространяться.
jakushev Автор
27.09.2019 13:53Отлично, что Вы мне написали. Если честно, аналог Вашего контроллера у меня лежит в столе более 5 лет. Только предназначался он немного для другой цели. Не буду голословным:
и обратная сторона:
Плата даже переехала со мной из Подмосковья в Минск, но все руки никак не дойдут. Собрана на одной из первых ESPшек. Это чисто «для себяйка». Собрана наколенным методом еще до доступных PCB из Китая. Так что с этим решением я хорошо знаком и в статье его отметил как «стрельба из пушки по воробьям». Теперь по существу: Цена. Стоимость микрофона — 6 рублей, ОУ — чуть больше рубля (розница на известной Китайской торговой площадке). Еще с пяток пассивных компонентов. 10 рублей против 100. Но это не самое важное. На первую фотографию случайно попал кандидат AC-DC преобразователя. Заявленная мощность — 5В x 500мА, прототип устройства, для которого я планирую использовать звуковой загрузчик, в пике потребляет 50мА по 5V DC. На сколько я помню, ESPшке надо до 800мА (3.3V) в пике. То есть по источнику я сразу пролетаю + DC/DC 5->3.3. Это большие габариты, следовательно не укладываюсь в корпус. Температурный диапазон -40 +80. WiFi контроллер на это не рассчитан, хотя подобная плата на ESP у меня стоит в «скважинном домике» и прекрасно работает почти 5 лет. Но там температура ниже +7 не опускается. Как раз одна из задач «скважинного контроллера». Про приложение. Я как раз написал, что не требуется специализированного приложения. Достаточно WEB страницы. В прототипе пока генерируется Пайтоновским скриптом. Звуковой файл можно записать хоть на диктофон, компьютер и телефон не нужны. Просто у Вашего и моего контроллера абсолютно разные применения. Вы сделали универсальное программируемое реле, а у меня прибор для конкретной одной задачи. Кстати, подобный Вашему контроллер я делал еще на исходе нулевых. У него не было проблем с обратными связями, допускалось «монтажное или», которое разрешалось или запрещалось пользователем. Уперся как раз в GUI. Лучшее, что мог тогда придумать — трансляция KiCad нетлиста в прошивку симулятора схемы. Но это решение имеет много ограничений. Отладка в реальном времени неудобна, приходится часть параметров добавлять в промежуточном файле. По этому хотел спросить: Вы сами писали редактор, или брали готовое решение? Если сами — будите публиковать или продавать исходники?shiotiny
27.09.2019 14:32На сколько я помню, ESPшке надо до 800мА (3.3V) в пике. То есть по источнику я сразу пролетаю + DC/DC 5->3.3.
Вот этим ESP питается www.chipdip.ru/product/ams1117-3.3
Если у вас такие же платы как на фото — то спокойно на них умещается. Или у вас настолько жесткие габариты?
Просто у Вашего и моего контроллера абсолютно разные применения. Вы сделали универсальное программируемое реле, а у меня прибор для конкретной одной задачи.
Согласен. Просто надоело мне решать «простые задачи» долго) Но у вас, как я понял, главный критерий — минимизация цены.
Звуковой файл можно записать хоть на диктофон, компьютер и телефон не нужны.
А как вы убедитесь, что контроллер понял прошивку правильно? Без ошибок принял новые параметры? Контрольная сумма?
По этому хотел спросить: Вы сами писали редактор, или брали готовое решение? Если сами — будите публиковать или продавать исходники?
Редактор писал сам на базе jquery и других библиотек. Но исходники по некоторым причинам отдать или продать (надеюсь, что пока) не могу.jakushev Автор
27.09.2019 15:46Попробую ответить (немного привяжу характеристики текущего проекта):
1. Питание. Даже такой линейный преобразователь занимает достаточно места на плате. Плюс надо отводить (5-3.3)*0.8 = 1.36 Вт тепла в пике. Ладно, соединим с «земляной» заливкой. Микрофон по площади занимает меньше. Хуже, что AC/DC тоже меняется. Как по габаритам, так и по цене. На Али подходящий стоит уже не 50, а 140 рублей. Сравнимо со стоимостью ESP. И в корпус уже не влезает… Да, габариты жесткие. Размер как 2 однофазных автомата.
2. Да, минимизация цены. Сложные задачи я постоянно решаю на основной работе, в том числе и Xtensa приходится дебагировать. Иногда хочется чего то простого, но элегантного, решающего конкретные проблемы, с которыми столкнулся лично. Цена тут, скорее, вызов для себя.
3. Контроль ошибок? Диктофон, конечно, крайний случай, но если на приборной панели светодиод еще моргает — воспроизвести запись сначала. Контрольная сумма — само собой! И не на все данные, а на сегменты. Если сегмент корректный, прибор его игнорирует при повторной передаче.
FGV
27.09.2019 14:43Температурный диапазон -40 +80. WiFi контроллер на это не рассчитан
лист 2 esp8266ex datasheet:
1.2. Specifications
Table 1-1. Specifications
…
Operating Temperature Range –40°C ~ 125°C
...
А вот сами esp-07 уже от -20 до +85. И бяка ограничивающая температуру применения скорее всего — кварцевый резонатор. Собственно вопрос, а у Вас пик16 от чего тактируется?
jakushev Автор
27.09.2019 15:15Внутренний RC. Погрешность по частоте +-5% для конкретного контроллера не важна. Наличие встроенного датчика температуры позволяет выполнять подстройку частоты «на лету».
FGV
27.09.2019 16:13Внутренний RC.
Нет кварца — нет проблем :)
Кстати вспомнилось, работающая esp8266/32 греется, по ощущениям градусов на 10 минимум, так что думаю модуль в закрытом пластиковом корпусе вполне может и при -40 снаружи нормально работать.
Anrikigai
27.09.2019 12:28Я совсем не в теме пока.
Но спрошу — модуль Bluetooth сильно дороже микрофона? Или сложнее в программировании?
«Спарить» устройство со смартфоном большинство сумеет, я думаю (наушники же подключают).
И с обратной связью легче. И к расстоянию меньше требований.lingvo
27.09.2019 12:51Промышленные, например Microchipовские BT модули стоят 6-10 евро. Микрофон с усилителем можно намного дешевле сделать.
Anrikigai
27.09.2019 13:07Ого. Просто на Али видел, к примеру:
ESP32 ESP-32 Development Board Wireless WiFi Bluetooth Dual Core CP2104 Filters Power Module 2.4GHz RF for Arduino Nodemcu
Introduction:
ESP32 is already integrated antenna and RF balun, power amplifier, low-noise amplifiers, filters,
and power management module. The entire solution takes up the least amount of printed circuit board area.
This board is used with 2.4 GHz dual-mode Wi-Fi and Bluetooth chips by TSMC 40nm low power technology, power and RF properties best, which is safe, reliable, and scalable to a variety of applications.
$4 + доставка $2
И тут уже и BT, и WiFi…
Впрочем, я понимаю, что в «промышленном исполнении» будут сильно другие цены.lingvo
27.09.2019 13:27Не, ну в принципе вы правы. Модули на ESP32 сильно дешевле — 3-5 евро, даже в более-менее промышленном виде.
shiotiny
27.09.2019 13:30А зачем для модуля, который используется раз в год «промышленное исполнение»?
Я сильно сомневаюсь, что описанные устройства типа «реле времени» сделаны именно на «промышленных» элементах.
Можно вообще WiFi или BT модуль сделать отключаемым кнопкой. Подошел со смартфоном, нажал кнопку (включил WiFI или BT модуль), зашел на веб или в программу-конфигуратор, настроил, нажал кнопку (выключил WiFI или BT модуль). Все.
Про то, что устройство с wifi или BT будет «менее помехозащищенным» я вообще не понял. С чего бы?lingvo
27.09.2019 13:38А зачем для модуля, который используется раз в год «промышленное исполнение»?
"Промышленное исполнение" — это, в понимании разработчика, не только условия эксплуатации, а более комплексная характеристика, которая включает в себя:
- наличие развитой поддержки от производителя и гарантии
- повторяемое качество, отсутствие брака
- возможность покупать данное изделие в количествах, нужных для серийного производства через надежных дистрибьюторов
- гарантия того, что данное изделие будет производиться в этом виде хотя бы пару лет
- наличие достаточных средств разработки, отладки и тестирования, которые дадут конструктору возможность гарантировать, что данное изделие будет надежно и без глюков работать после того, как его продадут.
- в некоторых случаях можно добавить наличие second-source
Ну что-то такое.
Saiho
27.09.2019 14:06Понятно что вы ищете и технически решение приемлемое. Спасибо за статью. Но хочу обратить внимание на не технический вопрос. Вам комфортно было бы жить в доме, где каждое устройство от розетки до выключателя и от лампочки до микроволновки обладают микрофоном и связью с внешним миром одновременно? Все они от разных производителей из разных стран и с закрытым кодом. Вот я упомянутую выше кнопку от Амазона не хотел бы иметь дома т. к. от этого бренда в первую очередь можно ожидать нововведений типа целевой рекламы по ключевым словам, прозвучавшим в помещении. Не говоря уже о других способах использования аудиоинформации, которые вы легко можете себе представить. И даже если не злобные производители, то всегда есть злобные хакеры. Конкретно вы можете решить свои задачи и через аудио, но массовым явлением это не станет никогда. Надеюсь.
Стараюсь придерживаться правила «критикуешь — предлагай». Первый вариант: Гораздо меньше опасений вызывает передача световых сигналов. Используйте мигание экрана смартфона и фототранзистор в 5 мм корпусе (чтобы встроенная линза собирала побольше света) на устройстве. Такое решение вроде уже применялось. Обратная связь через светодиод на устройстве и переднюю камеру на смартфоне. Сложное приложение? Из пушки по воробьям? Да! А что делать если у вас есть только пушка?
Второй вариант: RFID-образный обмен. Устройство просто слушает спиральную антенну, а для ответа замыкает ее ключом. Все идет к тому, что эта функция станет стандартной в смартфонах и скорее всего, что бы мы не придумали из костылей, со временем именно она станет стандартом.
За поднятую тему спасибо. Проблема программирования простых устройств действительно существует. Обязательно буду следить за обсуждением и вообще за вашими статьями.jakushev Автор
27.09.2019 14:53Спасибо, что подняли интересную тему. По поводу микрофонов — как раз я рассматриваю класс устройств, где нет никаких других каналов связи. Ну если совсем заморочиться, то решается очень просто. Как на колонке от Google. Физический разрыв цепи от микрофона. Проверку такого решения сможет выполнить любой начинающий радиолюбитель. Думаю, если выключатель будет и будет фейковым — по репутации любого производителя будет нанесен жесточайший урон. Кроме того, мы постоянно ходим с нашими любимыми «прослушками» — мобильными телефонами. Пока никто не отказывается. Даже если не Google или Apple, то вредоносный софт достаточно легко сможет активировать прослушку. И микрофон физически не отключается. Да и не один он в телефоне. Но за замечание ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО. С точки зрения паранойи не рассматривал. Если мои изделия и дойдут хоть до мелкосерийного производства, обязательно предусмотрю такой выключатель!
По поводу света. Как раз это был первый вариант исполнения. Я не уверен, что любой телефон сможет моргать экраном с частотой более 10Гц. Даже если 20Гц, давайте посчитаем: Нам нужен самосинхронный код. Берем манчестер. На один бит нам надо 2 периода сигнала. То есть, в лучшем случае получаем канал со скоростью 10бод. Для передачи 16 байт нам потребуется 12.8 секунд. В моем прототипе, который ограничен ну очень медленным по нашим временам контроллером, при использовании кода 1/2 2/1, не знаю его правильное название, но на 1 бит надо 3 интервала сигнала, я получил скорость 4 байта / сек или 32 бода. Это только на прототипе. 300 бод — вполне достижимая скорость, умел бы мой контроллер аппаратно умножать… То есть для передачи 16 байт надо уже 4 секунды. Плюс вопросы засветки (сталкивался с такой проблемой) или перекрытие приемного окошка проводами, например. И это решение — дороже. К тому же с ПК или ноутбука сложно передать данные. Да, такое решение было описано еще в ЮТ, вроде в 92 году. Приставка для управления нагрузками без необходимости разбора ПК. На экран монитора устанавливалось N фотоприемников и простая программа на Бейсике, подсвечивающая экран в нужном месте.
RFID — возможно, когда он будет в каждом утюге и будет доступ к модулю из WEB приложения…Saiho
27.09.2019 19:01Вы правы. Физическое отключение микрофона дает спокойствие. Например, на моем нетбуке камера физически закрывается шторкой и это действительно убеждает меня что камера ничего не подсматривает. Хорошее решение.
Справедливости ради замечу, что скорость перерисовки экрана вы явно занизили. Все не так плохо :) Скорость может быть гораздо больше.
Но давайте оставим оптику и посмотрим внимательнее на звук и RFID. Не настаиваю, но предлагаю рассмотреть варианты. Во-первых антенну передатчика можно подключить к звуковому разъему смартфона и получить полудуплексную связь. Стоимость аудиоджека и кусочка провода копеечная. Можно прилагать к каждому устройству.
А во-вторых почему бы не отказаться от микрофона или антенны вообще и соединять аудиовыход смартфона с устройством напрямую обычным аудиокабелем? Хотите чтобы пользователю не нужно было ничего искать? Припаяйте провод 10 см к устройству, а на другой конец аудиоразъем и сложите в нишу корпуса. Предсказуемое качество канала, не нужна тишина на время прошивки и т. д. Как следствие, намного бОльшая скорость. А звуковой сигнал, как вы гениально предложили, генерируется скриптом с веб-страницы.
Кроме того, хочу обратить внимание насколько важна обратная связь. Пока у вас производится одно устройство проблемы не заметите. Но появится другое и пользователи тут же начнут заходить на неправильную веб-страницу и пытаться запрограммировать устройство не предназначенными для него настройками. Конечно устройство отвергнет такую попытку, но отреагирует мигающим светодиодом т. к. не сможет отличить такую ситуацию от ошибки передачи. А пользователь после трех попыток будет уже сильно нервничать и не понимать что происходит. Лучше бы сразу закладывать возможность опроса устройства на предмет его модели, а еще лучше на скачивание всех текущих настроек и отражать их на в форме веб-страницы в качестве исходных.Alexeyslav
30.09.2019 08:48В последний раз когда у меня торчал кусочек провода с компьютера(может быть любая техника) даже отключеного от сети во время грозы он погорел. Наводка на этот самый проводок. Поэтому, скрученные проводки — это до первой грозы. Или защиту от грозовых разрядов надо ставить. Иначе первая сильная гроза, неудачный момент и погорят девайсы. Тогда ещё погорела розетка — был четкий след с фазы на контакт заземления.
Saiho
30.09.2019 13:12Вы Московские карты для проезда в метро видели? Они не выгорают во время грозы. Это потому, что защита от наводок делается совсем просто. Диодная сборка вроде BAT54S, крайние выводы на землю и питание, средний на сигнал. Но аналогичные диоды уже есть в микроконтроллере. Внешние могут понадобиться только если их не хватает, в чем я сомневаюсь.
Alexeyslav
30.09.2019 13:34Не выгорают, потому что антенна там используется замкнутая. Диодная защита не всегда помогает диоды сгорают после того как сгорела вся схема, или по крайней мере просто сгорают так что их приходится менять(и то и то на практике встречалось). И сбрасывать лишний ток на шину питания тоже не всегда хороший выход — актуально только когда минимальное потребление схемой тока всегда существенно больше чем предполагаемый импульс(сумма по всем входам) приходящий на вход — т.е. в реальных схемах это микроамперы и эти диоды ставятся совсем от другой угрозы — тиристорного эффекта паразитных структур на кристалле микросхемы сделанной по технологии CMOS и сходных, который происходит при токе через встроенные(на самом деле это паразитные) защитные диоды >2мА а на статике или близком грозовом разряде такое может с лёгкостью произойти. Если это происходит, то паразитный тиристор защелкивается и соединяет локальные шины питания в КЗ, выжигая часть кристалла если позволяет источник питания — ток больше ничем не ограничен. А если ток ограничить, то кристалл станет работоспособным только после того как снять с него напряжение.
ser-mk
27.09.2019 14:09Развивая мысль вашу… Можно было простo miniJack поставить разъем, и передавать можно было бы с любого смартфона(кроме последних айфонов) и ноутбуков.
jakushev Автор
27.09.2019 14:55Этот вариант я тоже рассматривал. Много проще в реализации, б'ольшие скорости, но нужен кабель. Как раз микрофон — замена кабеля.
IronCaterpillar
27.09.2019 15:47Рассматривался ли вариант с NFC? Достаточно удобно, компоненты дешёвые и кол-во смартфонов с NFC растёт постоянно?
jakushev Автор
27.09.2019 15:50Да, но пока вижу 2 проблемы: NFC есть не в каждом смартфоне и необходимость разработки / публикации минимум для 2х мобильных платформ.
vbifkol
Хорошая идея. А светом не дешевле/проще?
jakushev Автор
Как раз это была первая идея. Но тут сразу выяснился ряд проблем: только смартфон, ПК неудобно подносить к датчику. Вопрос с частотой, с которой я смогу «моргать» cancas'ом в разных браузерах и разной производительности железа. Получиться ли выжать хотя бы стабильные 10 Гц? Думал и «фонарик» использовать, но это уже приложение и я не уверен, что у всех телефонов он гарантирует хоть какую то стабильность времени включения / выключения. К тому же, это решение дороже, как ни странно… Если бы на телефонах не умер ИК порт, то и проблемы не было.
SvSh123
ИК-порт попадается, но всё реже.
Почему решение со светом дороже? Для этого всего и нужно, что фототранзистор да один свободный порт на контроллере.
jakushev Автор
Я цену считал где то месяца 3 назад. До статьи руки недавно дошли, в перерывах «пока компилируется». Электретный микрофон и ОУ дешевле вышли. И еще один момент. Для фотоприемника желателен коллиматор, пусть и простое, но дополнительное конструктивное решение. Микрофон не так требователен к месту расположения. И как ответили ниже: проще в использовании.
Useroff
Можно же взять приемник типа TSOP, линза на корпусе, внутри сразу АРУ и детектор несущей, сигнал генерить так же, на звуковом канале, передавать светодиодом, воткнутым в аудиоджек.
SvSh123
Так в том и фишка, чтобы ничего никуда не втыкать. В противном случае проще использовать ИК-порт или вообще адаптер USB-UART.
ser-mk
А можно пример такого приемника?
Useroff
Вот даташит: www.vishay.com/docs/82459/tsop48.pdf
deepform
О, как оказалось у меня он есть)
Спасибо
Alexeyslav
Инфракрасным. Причем связь можно двустороннюю организовать. Это потребует правда небольшой аппаратной приставки — фототранзистора и ИК светодиода в разъём 3.5. Будет больше похоже на затычку.
SvSh123
Дешевле и проще. А вот для пользователя сложней, придется смартфон экраном прижимать к определенному месту прибора.