Как стать автором
Обновить

Как управлять микроконтроллером, не привлекая внимания санитаров

Время на прочтение 6 мин
Количество просмотров 22K
Микроконтроллеры – они повсюду, на транспорте, на производстве, в медицине, в быту. Благодаря им, на смену умению “паять много”, пришло умение программировать. То, что вчера нужно было перепаивать, сегодня перепрограммируют. Элементарный мультивибратор, для проекта очередной пищалки, выполненный на микроконтроллере, будет надежнее и дешевле, аналога на отдельных компонентах. И такой тренд, по моему мнению, будет только нарастать.

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

Часть, и без того ограниченных ресурсов микроконтроллера, уходит на обслуживание всей этой инфраструктуры взаимодействия с пользователем. В итоге несущее весь полезный функционал ядро, микроконтроллер и силовые ключи, занимают 5-10% физического объема. Все остальное — это вспомогательное, экраны и кнопки.

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

При этом, у всех этих кнопок и экранов ограниченный потенциал использования, по сравнению с любым мобильным гаджетом в кармане у каждого из нас… С удобным, большим, контрастным, сенсорным экраном и достаточно производительным “железом”. Помимо этого, у многих на полке пылится не менее мощный, вполне исправный, морально устаревший, девайс, иногда и не один. Который выкинуть… пока рука не поднимается.

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

Работа в этом направлении, уже идет. Например появляются модели напольных весов, которые через Bluetooth позволяют на мобильнике не только видеть вес, но и отслеживать историю его изменения. Однако пока, от встроенного индикатора веса все же не отказываются…. пока.

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

Так почему бы уже сейчас, коль достоинства столь очевидны, не начать переносить с микроконтроллера часть функционала взаимодействия с пользователем на сторону мобильных устройств.

Ответ прост.
Это сложно.
Распределенные системы всегда значительно сложнее.

И сложность не в самом принципе коммуникации/транспорте, который уже удалось формализовать в виде UART, I2C, CAN…., а в сложности написании самого протокола поверх транспорта. Некоторую часть проблем: отслеживание сбоя канала, запрос повторной передачи, диспетчеризация пакетов… для машин с достаточными ресурсами, удалось реализовать в виде протокола TCP/IP. Но оставшаяся часть, написание собственно самого коммуникационного протокола специфична для каждого проекта и требует значительных затрат. Одним из способов, позволяющим упростить проблему, может стать автоматизация процесса программирования.

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

Protocol Buffers
Cap’n Proto
FlatBuffers
ZCM
MAVLink
Thrift

На сколько сложным может оказаться протокол обмена, можно оценить по одному из дескрипторов протокола обмена с квадрокоптером. В данном примере в качестве языка описания протокола выбран XML.

Для микроконтроллеров, многие решения из мира больших машин, типа TCP/IP, в силу ограниченности ресурсов не применимы. Приходится вспоминать, и использовать CRC, Bit/Byte stuffing, Endianness, а также учитывать многие другие, порой совсем неочевидные тонкости типа такого или такого. Попытка решения проблемы, путем написания кода вручную, способна превратить творческую жизнь программиста в ад. Подобный тому, который был с поддержкой java script на разных браузерах. Только здесь разные языки на совершенно разных платформах. Даже небольшие изменения в уже отлаженный протокол, могут привести к очень длительному процессу отладки.

Совсем не многие из вышеперечисленных инструментов, в своей кодогенерации опускаются на уровень микроконтроллеров. Попытка использовать упомянутые инструменты кодогенерации с трудом удавалось натягивать на микроконтроллеры старших 32 битных серий. Самые популярные, дешевые и широко распространённые 8 битные микроконтроллеры оставались в стороне. Мне очень часто попадаются проекты в которых самым правильным было бы вынесение органов управления на мобильное устройство. Иногда это удавалось сделать, но дальнейшее сопровождение и расширение функционала становилось очень не простым.

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

Сам кодогенератор было принято решение писать на SCALA, за основу языка описания протокола был взят широко известный язык JAVA.

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

BlackBox генерирует исходный код на следующих языках программирования JAVA, C#, C. Планируется поддержка SWIFT.

На данный момент, кодогенератор BlackBox построен как SaaS. Для получения сгенерированного и оттестированного кода необходимо:

  • Создать спецификацию протокола. По сути это обычный исходник на java. Вот например как он выглядит для демо проекта управления с Android миганием светодиода на борде под STM8S103F3P6 через Bluetooth UART на HC 08. При написании спецификации необходимо к java проекту подключить набор аннотаций описывающих характеристики данных, а также, следуя небольшому набору правил описать пакеты, каналы, хосты, коммуникационные интерфейсы, топологию сети
  • Проверить, что спецификация успешно компилируется, и послать её исходник, в виде аттачмента письма на почтовый адрес OneBlackBoxPlease@outlook.com. Сервер периодически забирает присланные спецификации из этого ящика, проверяет их корректность. Генерирует заказанный в спецификации исходный код на требуемых языках программирования. После этого создается несколько тестов и исходники прогоняются через них. Если все тесты прошли успешно, то сгенерированный код, последний прошедший тест, а также пример использования заказанного API упаковывается в архив и высылается адресату. В случае обнаружения ошибки, отправитель уведомляется о возможной задержке и служба поддержки BlackBox разбирается с возникшим затруднением.

Тут можно найти пример высылаемого сгенерированного кода, а тут использование этого кода в выше упомянутом, демонстрационном проекте управления с андроида вспышками светодиода на демоплате собранной на STM8.

Используя BlackBox вы сможете с лёгкостью наладить связь не только между микроконтроллерами, мобильными устройствами но и обычными компьютерами. И что важно, с минимальными затратами времени и сил. Фактически код сгенерированный BlackBox может стать каркасом Вашего распределенного приложения. Программисту останется просто добавить обработчики на события приёма пакета, а также логику создания пакета, заполнения его данными и отправки его получателю.

Оглянитесь вокруг как много проектов могут выиграть следуя этой парадигме. Вот парни из Гуанджоу сделали осциллограф DS212. Если перенести экран и органы управления на сторону мобильного телефона или планшета, можно:

  • существенно снизить стоимость изделия
  • значительно повысить эргономичность со всеми возможностями тачскрина.
  • сам осциллограф, став еще компактнее, будет находится там, где непосредственно происходит измерение, а результат будет отображается там, где это удобно пользователю, в пределах 10 метров, если это Bluetooth.
  • получая измеренные данные по бес проводу и запитывая сам осциллограф от батареи, которую он теперь станет потреблять значительно скромнее, получаем надежную гальваническую развязку.

Помимо этого, в процессе создания кодогенерации для JAVA, задумался о проблемах и недостатках встроенной в JAVA конструкции enum. Как решение, программисты Android, предлагают использовать аннотацию IntDef.

Творчески переосмыслив, я создал свое решение SlimEnum. Оно активно используется в BlackBox при кодогенерации на JAVA. Для удобства программирования с использованием SlimEnum, был создан плагин для IDEA/Android studio, который можно установить из plugin репозитория Intellij. Непосредственно SlimEnum, его достоинства и особенности будут описаны в отдельной статье.
Теги:
Хабы:
-2
Комментарии 177
Комментарии Комментарии 177

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн