Часть 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 должно хватить.
Всего наилучшего,
Константин.