Микроконтроллеры – они повсюду, на транспорте, на производстве, в медицине, в быту. Благодаря им, на смену умению “паять много”, пришло умение программировать. То, что вчера нужно было перепаивать, сегодня перепрограммируют. Элементарный мультивибратор, для проекта очередной пищалки, выполненный на микроконтроллере, будет надежнее и дешевле, аналога на отдельных компонентах. И такой тренд, по моему мнению, будет только нарастать.
Часть, не сложных проектов на микроконтроллерах, типа выключателей света или датчиков уровней, однажды отлаженные, более не требуют каких либо дополнительных настроек. Однако большинство проектов все же подразумевают взаимодействие с внешним миром. К примеру термостат или таймер нуждаются в возможностях подстройки и контроля заданных величин. Чаще всего эту функцию реализуют через добавление в проект механизмов взаимодействия с пользователем. И вот простейший проект начинает обрастать экранами, кнопками, энкодерами…
Часть, и без того ограниченных ресурсов микроконтроллера, уходит на обслуживание всей этой инфраструктуры взаимодействия с пользователем. В итоге несущее весь полезный функционал ядро, микроконтроллер и силовые ключи, занимают 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. Для получения сгенерированного и оттестированного кода необходимо:
Тут можно найти пример высылаемого сгенерированного кода, а тут использование этого кода в выше упомянутом, демонстрационном проекте управления с андроида вспышками светодиода на демоплате собранной на STM8.
Используя BlackBox вы сможете с лёгкостью наладить связь не только между микроконтроллерами, мобильными устройствами но и обычными компьютерами. И что важно, с минимальными затратами времени и сил. Фактически код сгенерированный BlackBox может стать каркасом Вашего распределенного приложения. Программисту останется просто добавить обработчики на события приёма пакета, а также логику создания пакета, заполнения его данными и отправки его получателю.
Оглянитесь вокруг как много проектов могут выиграть следуя этой парадигме. Вот парни из Гуанджоу сделали осциллограф DS212. Если перенести экран и органы управления на сторону мобильного телефона или планшета, можно:
Помимо этого, в процессе создания кодогенерации для JAVA, задумался о проблемах и недостатках встроенной в JAVA конструкции enum. Как решение, программисты Android, предлагают использовать аннотацию IntDef.
Творчески переосмыслив, я создал свое решение SlimEnum. Оно активно используется в BlackBox при кодогенерации на JAVA. Для удобства программирования с использованием SlimEnum, был создан плагин для IDEA/Android studio, который можно установить из plugin репозитория Intellij. Непосредственно SlimEnum, его достоинства и особенности будут описаны в отдельной статье.
Часть, не сложных проектов на микроконтроллерах, типа выключателей света или датчиков уровней, однажды отлаженные, более не требуют каких либо дополнительных настроек. Однако большинство проектов все же подразумевают взаимодействие с внешним миром. К примеру термостат или таймер нуждаются в возможностях подстройки и контроля заданных величин. Чаще всего эту функцию реализуют через добавление в проект механизмов взаимодействия с пользователем. И вот простейший проект начинает обрастать экранами, кнопками, энкодерами…
Часть, и без того ограниченных ресурсов микроконтроллера, уходит на обслуживание всей этой инфраструктуры взаимодействия с пользователем. В итоге несущее весь полезный функционал ядро, микроконтроллер и силовые ключи, занимают 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, его достоинства и особенности будут описаны в отдельной статье.
Krey
Если отвечать на поставленный вопрос, то ответ еще проще:
Время жизни энкодеров и кнопок в разы дольше чем время жизни неподдерживаемого приложения в любом облачном маркете.
На примере моей микроволновки с энкодером и кнопками оно больше времени существования самих маркетов и даже парочки ОС. Так что я никогда не куплю девайс, единственным интерфейсом у которого будет приложение.
cheblin Автор
В принципе да, излишества это всё… можно и вес фиксировать в EXCEL, а потом строить красивые таблицы. Хотя стоп, к чему Excel, когда есть бумага и карандаш!
Скажите, у Вас есть современный кондиционер/телевизор. А как Вы ими управляете?
sintech
Предыдущий оратор не отрицал удобство мобильных приложений, но когда альтернативы нет это плохое устройство. Основная функциональность должна быть доступна без использования сложных приложений и нетривиального процесса спаривания. Вы привели хороший пример — электронные «умные» весы. Приложения нет, видишь только вес а если есть, то кучу других параметров. Но в целом тема затронута актуальная, спасибо.
Oxyd
Ну во многих случаях всё-же удобнее рулить приложениями. Вот например меню новастаровского контроллера для управления LED видеоэкранами
Только есть одно но, из-за ограниченности ресурсов стоящего внутри железа многие функции в меню сильно урезаны в функциональности, а многие и просто недоступны. Да если-бы и не было ограничений, то, например, нарисовать произвольную раскабловку шин данных собранного экрана проще, удобнее, приятнее и быстрее с любимого ноутбука. ;-)
cheblin Автор
ну или интерфейс осциллографа
olartamonov
Да, значительно более лучшая реализация на этом виде на заднем плане на столе стоит.
ploop
Пример неудачный от слова «совсем»
Лучший интерфейс для осциллографа — физический, какой он, собственно, и есть. Это становится понятно только тогда, когда за ним реально поработаешь, а всё ПО на полноценных ПК/ноутах может носить только вспомогательные функции.
Это только кажется, что если там много всяких крутилок, то их можно убрать куда-нибудь в меню и оставить один большой экран. Нет. В процессе работы они все, что вынесены отдельно, используются. При чём не глядя. Всё, что можно убрать, уже убрано.
cheblin Автор
на каком осциллографе с сенсорным экраном у вас был плохой опыт работы? модель.
и о чорт! статья не про это! она про BlackBox… про генератор исходного кода обработки бинарного протокола.
ploop
Я просто сказал, что пример, который вы дважды (что на глаза попалось) использовали, не удачный.
Есть вещи, для которых сенсорный экран (смартфон) в качестве интерфейса действительно имеет место быть.
hardegor
На любом меньше 15 дюймов — банально руки закрывают экран.
Хотя не спорю, удобно, что места на столе занимает минимум. Я бы прикрепил как дополнительный монитор жестко к полке — как-раз будет перед глазами и держать второй рукой не надо.
nafikovr
На любом.
Alexeyslav
А я бы просто добавил подключаемую по USB(или блютуз?) панель с кнопками-крутилками на любой вкус а может даже и не одну. Но почему-то никто не догадался до такого финта с этими осциллографами-планшетами.
ploop
Для игрушечных осциллов смысла нет, панель по цене наравне с ним будет. Для нормальных, где вся цена в электронике, по сути получится отделение экорана, который стоит малый процент по сравнению с остальным…
Alexeyslav
Себестоимость такого пульта будет не такой большой по сравнению с самим осциллогарфом, а продавать будут задорого, да.
r00tGER
Можно я отвечу, про телевизор и кондиционер? Спасибо!
Управляю обычным пультом — так удобнее всего:
— пульт всегда заряжен (для зануд: да, батарейки раз в год можно и поменять)
— физические кнопки
— цена: можно ронять, можно позволить более небрежное обращение в угоду комфорта
— всегда в комнате
— всегда работает и не отваливается (привет обновлениям)
А приложением поигрался и забыл.
cheblin Автор
у меня нет телевизора.
но есть кондиционер… пульт от которого давно потерян. и не мной
зато на маркете есть приложение в котором прошиты практически все кондиционеры и телевизоры.
установил. пользуюсь. доволен.
— мобильник у меня всегда заряжен. и на счету есть деньги. и я слежу за этим. я современный человек. без связи никак.
— сенсорный экран с мультитачем
— на рынке очень много дешевых планшетов и мобильников
— всегда с собой
— всегда работает.
что я делаю не так?
r00tGER
> я современный человек. без связи никак.
Так и напрашивается эпитет «успешный» (ради чего-то же должны быть все эти усилия, раз вы на них акцентируете внимание, при том что они очевидны)
А если серьёзно, то вопрос и не стоит, кто именно, что-то делает не так.
У всех свои предпочтения. И пока приверженцев определенных предпочтений будет весомая доля, с точки зрения бизнеса их придется учитывать.
Я понимаю, что со временем обычный пульт станет отдельной опцией, а потом и вовсе исчезнет. Но, на данном этапе он лично мне более удобен.
Для примера, даже Apple TV идет с «обычным» пультом.
Liverius
В тоже время у Apple есть HomePod у которого пока еще заявленно голосовое управление или, как альтернатива, со смартфона, без каких либо физических элементов. Видимо именно поэтому она до сих пор не поступила в продажу.
IronHead
Приехала к вам в гости бабушка.
Бабушка: Внучек, где пульт от кондиционера? мне жарко…
Внучек: Бабушка, возьми планшет на диване, запусти приложение MyCoolControl, закрой рекламу крестиком в углу, подключи по блютуз устройство Cool_In_Room_143, в поле температуры введи нужную температуру.
Бабушка: Пойду лучше смузи налью и на гироскутере покатаюсь…
cheblin Автор
бабуся закончить бы фразу не успела, как все бы уже произошло…
Goron_Dekar
Например сенсорный экран?
Мне кнопки удобнее, можно ночью нащупать и не будить жену ярким светом подсветки.
nafikovr
Поэтому пульт от кондиционера должен быть прикреплен к стене, как и выключатель освещения, и термостат. А все эти приложения для смартфонов требуют слишком большого количества телодвижений для простых операций требующих нажатия одной кнопки на родном пульте/устройстве
lingvo
… И в этом случае весь этот зоопарк пультов может быть заменен одним единственным планшетом, закрепленным на той же стене, работающем в режиме 24/7 и который может управлять и отоплением и кондиционированием и светом и жалюзями и погоду на улице показывать и все это через один интерфейс. Не находите, что это будет и эстетичней, удобней, дешевле и более заточено на будущее?
nafikovr
если вы найдете приложение, которое всем эти зоопарком будет командовать без необходимости провести конфигурацию среднестатистическим пользователем, то да, звучит красиво. а так — если девайс и поддерживает управление изначально, то обычно только своей программой, которая больше ничего не поддерживает.
Alexeyslav
Планшет не тормозит, никогда не виснет и никогда не вовремя не обновляется. Что-то мне подсказывает, таким пультам нужно бронированное стекло толщиной минимум в сантиметр чтобы табуреткой со злости нельзя было разбить. А учитывая что управлять он будет всем и является единственной точкой отказа для всех систем… его точно разобъют, вопрос только насколько быстро.
И кстати, в будущем точно не будет никаких планшетов для управления техникой. Обои-телевизоры, мысле-передатчики, компактные ДНК-сенсоры… вот более вероятное будущее.
Krey
Вообще то комплектным пультом.
Вы привели замечательный пример. Представим что в ваших весах нет индикации веса. Вы встаете на них и получаете вес на свой смартфон. Далее вас нет дома, а встать на весы желает еще ваша жена и дочка. Приведете тут порядок действий который нужно провести с весами и другими смартфонами (весы ведь спарены с вашим мобильником)?!
cheblin Автор
порядок действий не меняется.
скажите, а вы на практике как часто используйте Bluetooth устройства? ну там наушники, мышки, клавиатуры, очистители воздуха...?
если не часто, то на ютюбе это можно наглядно увидеть.
Krey
На практике я не только часто использую устройства с БТ, но и пишу иногда софт для них. И когда вы перестанете теоритизировать, а станете их использовать, то узнаете что 9 из 10 весов с рынка не смогут нормально спарится с другим телефоном, без того что бы не вытащить из них батарейку даже при штатной процедуре создания связи (т.е для жены придется держать еще и инсрукцию где нибуть рядышком) и даже при этом они будут работать не со всеми телефонами. И совсем уж мало устройств будут работать без глюков, если их постоянно перекидывать по смартфонам без полного сброса.
Еще стоит упомянуть чехарду с профилями и протоколами BT из за которых большинство устройств просто превратится в тыкву в скором времени, когда исчезнет родное приложение из маркета.
cheblin Автор
похоже эти весы с дефектным Bluetooth модулем.
если бы подобное происходило повсеместно со всеми Bluetooth устройствами, об этой технологии, кроме её создателей, никто бы не узнал.
IronHead
Такое происходит периодически. Приходится отвязывать устройство, делать аппаратный сброс (перезагрузку) устройства и делать сопряжение снова. С этим не так часто сталкиваются в жизни (а если сталкиваются — перезагружают устройство и телефон и ругают программистов), но во время тестов на этапе разработки — это жутко бесит.
Krey
Ну поскольку большинство устройств китайский околоноунейм, то разного рода дефектных устройств достаточно много.
Ну возьмем идеальные весы. Вы ушли на работу, жена встает на весы, ничего на смартфон не получает, чертыхается и лезет в инструкцию читать про pairing. Вы приходите домой, встаете на весы и ваш вес добавляется в историю веса жены на ее смарте. Теперь чертыхаетесь оба и идете покупать весы с индикацией.
Я хочу этим сказать что задача использования бытовых устройств с БТ совместно несколькими людьми нормально вообще не решается.
cheblin Автор
понятно. место проклятое. тогда WiFi какой нибудь модуль на ESP8266 вас спасет. стоит он столько те же самые 100 рублей.
код сгенеренный BlackBox потрабелен.
Krey
Но речь тут не обо мне идет, я вполне в состоянии при наличии времени, желания или заказа и существующие БТ девайсы интегрировать в систему умного дома.
Только это все далеко от уровня бытового использования устройств без индикации, которых по описанным в этом посте причинам не существует.
undisclosed
Доля Вашей правды действительно есть.
Но конкретно на счет весов упомянутых в статье, позволю себе с Вами не согласиться.
У меня дома есть эти ми-весы, связаны с несколькими телефонами и спокойно узнают каждого члена семьи. Более того, когда встаю на весы и беру на руки маленькую дочку — приложение показывает мне ее вес и пишет его в отдельный профиль. Батарейки не вынимал из них с момента покупки (более 2х лет уже...). На индикацию не смотрю (зрение поганое), и я их даже иногда полностью из-под шкафа не достаю. Т.ч. при нашем паттерне использования — абсолютно не доставляют проблем ни мне ни жене ни периодически приходящим бабушкам и без индикации обошлись бы спокойно. Но с экранчиком они все-же лучше, чем совсем без него.
Krey
укажите модель весов пожалста, посмотрю поближе.
undisclosed
У меня самая первая версия Mi Scale. В статье ссылка как раз на них.
Сейчас еще вышла вторая версия с возможностью определения массовых долей жировой, мышечной и костной тканей. Про них ничего не скажу.
nafikovr
Проблемы может не быть у вас, но это не исключает ее вообще. Не скажу за весы, но гарнитура mi криво спаривается некоторыми телефонами, при чем включая такие же mi.
avost
С весами хороший пример. Обычно, весы у меня в одной комнате, а телефон в другой. На кой мне красивые графики я не знаю, Альцгеймер меня пока не застиг и я свой средний вес помню. И/или реперные точки.
С телевизором тоже хороший пример. У меня есть пульт и приложение на телефоне. Приложение использую совсем редко, когда совсем уж делать нечего, а тут одновременно с телевизором телефон в руки попался. Телефон, опять же, как правило где-нибудь далеко, а телевизор хочется переключить прямо сейчас. Пульт, правда, дети тоже постоянно теряют, поэтому востребованность пульта примерно равна востребованности кнопок на телике. А, да, у детей кнопочные телефоны (смарты не выживают если на них с горки кататься или по гаражам лазить), поэтому работа с теликом в вашем варианте детям недоступна?
Кондиционер… у него "пульт" в стену вделан. Офигенно удобно и не потеряешь :)
Реально, управлять с телефона/планшета чем-то, что не встроено в телефон жутко неудобно.
ЗЫ у меня ещё и микроволновка с единственным, да ещё и механическим органом управления. Из многих опробованных вариантов этот — самый удобный.
Представил себе микроволновку с управлением от телефона. Отличная вещь, если хочешь сделать подарок заклятому врагу!
poznawatel
Я тоже не куплю такое недоустройство. Вдобавок такой подход экспоненциально наращивает количество векторов атаки. Stuxnet научил меня, что лучше проще, да лучше.
shadovv76
вы имеете какое то отношение к иранской ядерной программе? :)
EighthMayer
Нужно иметь какое то отношение к иранской ядерной программе, чтобы стараться делать не говно? :)
shadovv76
чему может научить Stuxnet обычного пользователя бытовой автоматизации?
это ПО разработано под прориетарную систему, намеренно, с участием производителя оборудования (без копирайта, но содержало валидные сертификаты) и занесено физически (на флэшке) с использованием инсайда на объекте. Если придаваться панике, то с таким же стечением обстоятельств можно испортить даже используя кнопочный вектор атаки.
P.S. С целью развернутого пояснения к моей предыдущей лаконичной фразе.
EighthMayer
А, вы именно о Stuxnet говорили? Тогда я вас неправильно понял, прошу прощения. Я развернул вашу лаконичную фразу как «не имеет смысла заботиться о информационной безопасности до тех пор пока не имеете отношения например к иранской ядерной программе».
zerg59
Вы недооцениваете здоровое любопытство соседских детей (любого возраста) ;-)
ramzzes52
Даже если не говорить о малом времени жизни маркетплейсов с приложениями, то можно пивести такие доводы. Я выдвинул из под дивана напольные весы, встал на них, голову опустил (вернее и не поднимал), зафиксировал свой вес на экране, убрал весы обратно — четыре действия. В случае с мобильным управлением: достал весы,… сами представьте что дальше нужно делать и посчитайте сколько действий будет в итоге, сколько дополнительных условностей сразу появляется для выполнения простой задачи. Вроде все по мелочи, но вспомните ка UX-принципы. Такая разница в случае с интерфейсом веб-приложения может напрочь изменить его судьбу. Совсем отказывааться от традиционных интерфейсов зачастую не рационально даже просто для выживания продукта на рынке, а насиловать рынок избавлением них, ну, пардоньте… Должно быть на выбор и то и другое.
cheblin Автор
в бухгалтерии помимо, компьютеров всегда есть калькуляторы, вот сётов не осталось… интересно почему?
по поводу весов.
перед взвешиванием, достаточно на мобильном ткнуть на уже настроенное bluetooth соединение. и встать на весы.
всё.
Anastasia_K
т.е. перед взвешиванием мне ещё и мобильник искать надо?
Ugrum
Конечно. Без мобильника весы вас не признают и прогонят легкими ударами тока по пяткам.
nafikovr
А вес мобильника потом вычтут?
shtushkutush
— И обязательно добавим bluetooth!
— Зачем?
— С bluetooth все становтся лучше!
Как дополнение к основному (классическому) управлению, пойдет. Хотя часто является лишним и ведет к удорожанию конечного продукта. Как замена основному управлению — НЕТ.
Да, телевизором можно управлять с телефона, но при поломке пульта, пошел и купил новый.
Да, стиральной машиной можно управлять с телефона, но белье с порошком в нее само не загрузится!
Я за прогресс, но не нужно к машине приделывать 5е колесо!
cheblin Автор
будет стоять две модели одна с пультом, но дороже (за капризы надо платить), другая без.
а рыночек сам всё порешает.
TerminusMKB
А может сделать с пультом дешевле, и пусть тогда «рыночек решает»?
cheblin Автор
а кто будет платить за пульт?
h0rr0rr_drag0n
Покупатели телевизора с пультом, которым, допустим, не надо будет платить за разработку приложения для смартфона.
Что-то мне подсказывает, что сделать свой пульт с кнопками и ИК для производителя будет дешевле, чем разрабатывать и поддерживать приложения с той же функциональностью для айфонов, андроидов (с учётом зоопарка аппаратуры на которых оные крутятся) и прочих мобильных ОС.
P.S. А ещё надо учитывать стоимость телефона, который нужен будет, чтобы это приложение-пульт, которое естественно напишут под самые распоследние версии андроида/iOS, как-нибудь работало. Я тут недавно по глупости купил экшн-камеру от Xiaomi, которая управляется через приложение для Андроида — поставил это приложение на Sony Ericsson wt19i — память на телефоне кончилась. А покупать новый телефон у меня пока нет ни бюджета, ни желания.
Alexeyslav
В целом разработка приложения обойдётся горааааздо дешевле чем РАЗРАБОТАТЬ тот же пульт и производить его. Программистов можно набирать пачками и задёшево, а для пультов нужен завод с рабочими определённой квалификации, инженеры разрабатывающие электронику пультов, пластик подбирать, дизайнеров, эргономистов… отдавать это на аутсорс может и дешевле выйдет но не принципиально. А тут понимаешь… открытый API сделал, и пользователи глядишь 10 вариантов приложений САМИ напишут на любой вкус.
ploop
Что?
Разработка пульта сводится к разработке дизайна в лучшем случае, всё остальное вам сделают под заказ за копейки, а то просто берётся OEM за 1$ и клеится своя наклейка.
Вы же при производстве электроники не собираетесь разрабатывать отдельно комплектующие, вы просто их покупаете. Пульт — такая же деталька, микросхема в большом и красивом корпусе, модификаций которых вам предложат миллион.
h0rr0rr_drag0n
В дополнение к ответу ploop про «дорогое» производство аппаратуры, отмечу, что приложение нужно поддерживать, править баги, выпускать новые версии под новые версии андроида, iOS и т.д. Тогда как пульт — он железный — его не надо выпускать каждый раз под новую версию ОС. Кроме того, с пультом у нас уменьшается количество прослоек с багами и глюками при выполнении простейших действий по переключению каналов,
А открытый API — не более чем игрушка для гиков. Людям нужно, чтобы можно было переключать каналы не вставая с дивана и не делая лишних и ненужных действий. Удорожать разработку телевизора ради удовлетворения сравнительно малой части населения никому не надо.
Alexeyslav
Вот не скажи, каждый производитель пытается сделать свой пульт, своя эргономика, свои формы… даже от разных моделей разные пульты. Короче там полёт фантази не хуже чем в софте. И сами пульты бывают весьма бажные. Вот прикол — через два года ПЕРЕСТАЁТ работать функция настройки каналов на пульте. Нет, кнопки сами в прекрасном состоянии — настройка каналов вызывается одновременным нажатием двух кнопок, причем отдельно обе кнопки работают без замечаний т.к. со второй кнопкой работает СБРОС настроек канала и регулировка яркости/цветности/насыщенности. Добро пожаловать на рынок за новым пультом…
И бывает внешне пульт такой же но ревизия уже другая — на плате рисунок другой, микросхема другая… Так что с физическими пультами заморочек не меньше чем обновлять софт и править баги, только латентность гораздо больше.
h0rr0rr_drag0n
Не согласен, что заморочек столько же. В случае с пультом, как вы сами пишете — вы просто покупаете новый и даже не паритесь какая там ревизия печатной платы, прошивки и т.д. — если старый пульт работал нормально после покупки и до поломки, то и новый будет в 99.999% случаев работать.
В случае с ПО, у нас есть большее количество слоёв с багами и возможными точками отказа, между человеком и телевизором. И в качестве одного из слоёв — всё проблемы аппаратуры, которые присущи и пультам, то есть мы получаем проблемы пультов (некачественные электронные компоненты, нарушения при производстве устройства) + проблемы ПО.
ploop
Ну эргономика и формы это про что я и говорил — дизайн.
А вот начинка — одна и та же. Микросхемка-ASIC на несколько стандартных протоколов и разное количество кнопок.
Если современный производитель решился разработать пульт на контроллере (про ASIC уже молчу), да со своим протоколом — сам себе буратино, ибо встанет в копеечку.
Сложнее дело обстоит с пультами кондиционеров, там логика работы устройства находится в пульте, плюс он с обратной связью. Тот естественно дороже.
IronHead
Не поделитесь ссылкой где написано, что пульты у кондиционеров с обратной связью. Интересует как это реализовано. Просто признаться — ни разу не видел пультов с обратной связью. С эмуляцией (для глаз пользователя) — да, видел, а вот именно чтобы реальная по ИК каналу — нет.
ploop
Были такие, обсуждалось. Так же по ИК-каналу, только ЕМНИП связь инициировалась в момент нажатия кнопки на пульте — кондиционер получал пакет и отправлял свой, т.к. в этом случае пульт гарантированно смотрит на него.
Andy_Big
Наверное, такие и бывают, но что-то мне не попадались :) Тем более, что бы еще и с логикой работы кондиционера внутри — это вообще непонятно из каких соображений надо делать :)
lingvo
Пульт от телевизора, если подумать, сама по себе специфичная штука. На нем обычно есть только кнопки без каких либо дисплеев и индикаторов. Обратная связь — через телевизор. Поэтому вполне понятно, что приложение на телефоне — это overkill — для телевизора нужно управление только в одном направлении — от человека.
В данном случае я уверен, что приложение на телефон — это неправильное направление развития. Голосовое управление, например, было бы куда более подходящим методом, так как имеет те же характеристики, что и пульт — оно однонаправленное.
IronHead
Голосом не удобно. Жестами — еще куда не шло. Но я бы больше обрадовался пульту к телевизору с радио управлением и кнопкой на ТВ «найти пульт» (пульт при этом должен запищать)
Alexeyslav
До голосового пока ещё далеко. Такое управление нынче даже с одним человеком не очень-то хорошо справляется, а если шумы и источники противоречивых команд, с этим пока ещё проблемы. Поэтому физический пульт пока самый понятный и надёжный способ управлять техникой.
r00tGER
А за программистов которые будут писать регулярные апдейты?
По крайней мере для совместимости с новыми версиями мобильных платформ. Не говоря уже об исправлении ошибок.
Или придется всё это хитро завуалировать от зорких глаз рыночка. Например, включив цену разработчиков в стоимость, а пульта нет?
undisclosed
Ну как бы физический пульт тоже не сам себя делает и настраивает. Для этого инженер/программист требуется. И для физического пульта — требуется покупка комплектующих в отличии от приложения.
Вы, по-моему, недооцениваете стоимость работы Китайских программистов. Более того, как правило, все они сидят на фиксированной зарплате. И если такой специалист уже есть в штате на фабрике (а он 100% есть, и не один), то его труд по написанию/изменению приложения пульта дополнительной стоимости не создает. Да и поддержка такого приложения — минимум трудозатрат, как правило ограничиваются добавлением новых кодов для нового оборудования производителя.
Так что без пульта будет все-же дешевле. Вон уже пошли телеки с одной физической кнопкой на юните.
r00tGER
Труд программиста — это такой же ресурс, как и пластик для корпусов устройств. А дальше чистая экономика — если выгодно тратить ресурсы программиста на написание апдейтов, то их потратят.
Но, практика показывает, что на устройства 2-3 летней давности уже практически не выходят апдейты. Моему кондиционеру 8 лет, и его пульт отлично работает до сих пор. А, теперь представьте, что за 8 лет произошло с приложениями в вашем смартфоне, и сколько смартфонов сменилось…
undisclosed
Труд программиста в Китае — предоплачен.
Програмер может спать, если работы мало, а может работать. Не нравится как один работает — заменят на другого.
Для фабрики затраты — одни и те же.
И я не говорил, что мне это нравится, но судя по всему, производители идут по этому пути. Я лишь поясняю, почему им это выгодно.
Будут писать апдейты ровно до тех пор, пока у них покупают эту технику.
Как вариант, сделают универсальный пульт на все модели и будут поддерживать по тому же принципу как поддерживаются драйвера на видеокарты.
ploop
Выше уже написал — пульт относится к части комплектующих и покупается отдельно, наряду с остальными.
Minras
В следующий раз буду обновлять комменты до написания своего.
migelle74
Рынок действительно все порешает.
Та, что без пульта будет стоить дороже. Т.к. спрос на стиральную машину без кнопок-крутилок будет около нулевой, покупать ее будут только узкий круг гиков, соответственно производить ее будет дорого.
P.S. У меня спутниковый ресивер может управляться как с веб-морды, так и с приложения. В итоге обе эти опции используются только в одном случае — когда надо поставить таймер на запись. Все. В остальных случаях используется пульт т.к. он доступнее и быстрее.
nafikovr
Уже решил.
Во-первых, экономия будет копеечной. Ибо разработка пульта уже выполнена (есть же аариант с пультом, а производство копеечное.
Во-вторых, пульт просто удобнее ибо тактильные ощущения позволяют выключить телевизор неглядя.
В-третьих, люди обустраивающие медиацентры на базе пк/одноплатников вполне себе покупают пульты за цену сравнимую с ценой бюджетного телевизора.
IronHead
В современном мире срок жизни вещей определяется не временем жизни кнопки (имеющей ресурс 1 млн нажатий), не временем жизни дисплея и или энкодера. В современном мире время жизни определяет мода. Сейчас модно смотреть видео в 4к и иметь доступ к ютуб с телевизора, но тем не менее — старые телевизоры по прежнему работают на дачах, не думая ломаться.
Что удобнее — пульт с 4 мя кнопками: «громкость и переключение каналов» или мобильное приложение, которое не работает без доступа к интернету, да еще и требует постоянного запуска себя?
Так ли вам нужен блютуз в чайнике, ведь воды в нее он сам не нальет.
Вы пользовались осциллографами приставками к ПК? По своему опыту знаю, что лучше отдельного прибора со своим экраном — только отдельный прибор со своим экраном.
Tomasina
О да… Перед праздниками был целый квест в поисках простого телевизора для дачи, основным ежедневным пользователем которого является пожилой человек. Главным критерием было не наличие 4К / Smart и прочих плюшек, а… удобного и простого пульта (с качеством картинки при нынешнем DVB-T2 проблем нет, ловится даже на 17-сантиметровый гвоздь).
Увы, безуспешно. В ценовом диапазоне 20-80 тыс. нет ни одного ТВ с удобным и простым пультом. Даже самые глупые ТВ (с минимум функций) имеют слишком замороченные пульты, у всех без исключения основные кнопки (включение, каналы, громкость) мелкие и расположены впритык с остальными.
Пришлось позже купить универсальный обучаемый пульт за 300 р., типа такого.
cheblin Автор
то ли на макете, толи где то в обсуждениях пролетало приложение — конструктор пульта.
самомобучаемое(читает коды старого пульта) и позволяет конструировать интерфейс мобильного пульта.
оставив только те кнопки которые нужны.
для андроидов с ИК
Tomasina
Вы пропустили акцент — для пожилого человека. Многие из них не приемлют концепцию сменных функций, зависящих от контекста, им нужен тактильный отклик от нажатия и, главное: одна кнопка = одна функция.
ed007
Посмеялся. Вы действительно теоретизируете. Управлять телеком с мобильника/планшета через экранные кнопки — реальная пытка даже для гика. Все делается наощупь с кнопочного пульта.Быстро.
Ugrum
Ну есть у меня андроид с ИК (Redmi 3). Есть как родное ксяомишное приложение-пульт, так и сторонних куча бесплатных и не очень. Поиграл в самом начале чуток- настроил сплит, спутниковое, телевизор. Думал, ну всё, минус три пульта. Ан нет, через неделю-полторы минус все эти приложухи, ибо эти тихий ужос, а физические пульты вернулись на свои законные места.
nafikovr
Это отличный вариант чтоб отключить музтв в кафе или настроить кондиционер в офисе, но не более того
dernuss
Я пользуюсь usb осциллографом часто. Очень удобно на самом деле. Тот что у меня фирмы picotech. Очень хорошее программное обеспечение, декодирует кучу последовательных протоколов (can, usb, 1wire и т.д.). Конечно есть и недостатки, например нет гальванической развязки.
nafikovr
Ему бы еще отдельный монитор выделить, цены бы не было. (Сарказм)
EighthMayer
С основной частью ваших изначальных тезисов я не согласен, но я про это уже говорил на easyelectronics.
Весьма обрадовало что вы пошли дальше тезисов, и соорудили для всего этого какие-то инструменты. Но вот предоставление этих инструментов в виде SaaS, на мой взгляд, всё портит. Я бы не стал добавлять такое в свой проект.
cheblin Автор
а на мой взгляд, как раз наоборот. на стороне сервера будет трудиться команда поддержки, которая будет собирать пожелания, анализировать и аккумулировать лучшие практики.
не надо. это сделает Ваш конкурент.
Stanislavvv
И через пару лет внезапно компания дропнет поддержку протокола вашего девайса, ибо вышел новый протокол с новыми рюшечками, который в ваш старый девайс никто засовывать и не собирался. Или просто закроется. Или сдохнет интернет в неподходящий момент.
Akon32
Схема сборки с отправкой email куда-то — это полный трэш. Нормальные люди делают скрипты или плагины к
sbtсистемам сборки.Проект — реально чёрный ящик, совершенно непонятно, как работает полученный код. Я бы не рисковал такое использовать. Лучше построить свой лунапарк. Или взять MQTT.
cheblin Автор
какой именно? демо код на JAVA? на C? на С#?
или вы уже отправили свой дескриптор на кодогенерацию? обычно приходить подтверждение. скажите какой проект, я посмотрю.
отлично! больше хороших решений!
управлять коптером с земли?
Tomasina
Запятые, где запятые?
seri0shka
Я, наоборот, кучу лишних запятых заметил )
Squoworode
Это, конечно, важно, запятые, запятые, запятые, да побольше, побольше!
Liverius
Как идея, все это выглядит интересно. Я сам за то, что бы всем домом можно было управлять с одного экрана (хотя конечно проблему порошка и воды в чайник просто так не решить). Но в то же время полностью отказываться от физического управления не стоит: никогда не помешает резервная система на случай форс-мажора. Как уже многие заметили — в первую очередь пострадает надежность всей системы. Например (из личного опыта) на старом телефоне (хотя на тот момент ему было всего 2 года) сломался экран — он перестал что либо отображать. Устройство потеряло свою функциональность, но это всего лишь телефон. Сломайся так центр управления всем домом и тогда проблема ручного засыпания порошка в стиральную машину перестанет быть хоть какой-то проблемой. Конечно на такой случай можно иметь пару запасных планшетов/телефонов, но это удорожание всей системой. Что до использования личного телефона, то здесь возникает вопрос доступности к нему всех членов семьи и еще вопрос и какой объем памяти в таком телефоне стоит резервировать. Конечно все люди разные: кому-то хватит функций звонка и возможности отправки сообщений, а у кого-то память забита фоточками с недавних выходных и играми. Так что для практического применения имеется множество вопрсов. Которые еще решать и решать.
Neuromantix
Каким образом мультивибратор на МК может быть надежнее мультивибратора на дискрете или логике? Ответ — никаким.
Все, что привязано к интернету, без интернета превращается в тыкву.
Стоимость телефона для управления может превышать стоимость исходного устройства на порядок, а дешевый/старый телефон — тупить, не поддерживать софт, глючить и тд. В отличие от этого железные кнопки и энкодеры никогда не тормозят и не глючат (при грамотном проектировании схемы).
Беспроводные каналы по радио подвержены помехам и перегрузке.
И главное — спаять мультивибратор на дискрете или логике можно через 10 минут после открытия схемы и прочтения описания даже с нулевым опытом. Сколько часов потребуется для написания того же мультивибратора для МК, отладки и прочего?
И не забывайте, что правильный мультивибратор требует двух микроконтролеров (шутка. если что)
Нет, спасибо.
cheblin Автор
тоже мнение.
Sun-ami
Мультивибратор на МК может быть надежнее мультивибратора на дискрете или логике, потому что может обходиться без каких-либо компонентов кроме МК — а это значит, что он меньше подвержен электромагнитным воздействиям в силу малых размеров МК, имеет меньше точек соединения, подверженных коррозии в агрессивной среде, может быть реализован на МК в компактном корпусе с малой массой, что упрощает защиту от вибрации и больших ускорений, может иметь встроенный термодатчик для компенсации температурного дрейфа параметров времязадающих элементов, и функцию автокалибровки для компенсации их отклонений их параметров от номинала. Собирать мультивибратор на МК не требуется — при наличии готовой программы он реализуется прошивкой МК с предварительным прочтением инструкции за 1 минуту. Железные кнопки и механические энкодеры изнашиваются и ломаются — но выносить интерфейс полностью в смартфон — считаю неправильным, лучше использовать сенсорные кнопки и, где нужно — тачскрины для базового функционала. А интерфейс со смартфоном тоже нужен — но для редко используемых функций — тонкой настройки, задания программ и профилей, диагностики, обновления прошивки.
Neuromantix
Собирать как раз требуется, т.к. «готовую программу» взять неоткуда, ее надо писать, т.е. учить программирование, при этом придется еще учить и то, что к собственно схеме отношения не имеет — ватчдоги например.
Железные кнопки и энкодеры заменяются любыми кнопками и энкодерами — хоть из 2 полосок жестянки. Установив дисплей с тачскрином, можно с удивлением обнаружить через пару лет, что он уже снят с производства. и заменить его не на что. Особенно если он какой-нибудь нестандартный.
Было 2 микроволновки — одна с механическим реле времени, вторая — с сенсорными кнопками. Первая отремонтировалась покупкой механического реле за 150р, а вторую пришлось списать, потому что «плата управления более не выпускается, у вас старая модель». Прошивки управления тоже нет" И все.
ploop
С сенсорными или с плёночной клавиатурой? На сколько знаю, сенсорные не ставят на микроволновки.
Плёночную буквально вчера реанимировал. Точнее сказать, клавиатуре уже кирдык, просто вынес аккуратно на панель две железных кнопки, проследив цепь и подпаявшись к плате. Продублировал «Старт» и «Стоп», из остального разве что разморозка иногда использовалась, остальное никогда.
Neuromantix
С пленочной. Сдох управляющий МК — нажатие на любую кнопку воспринималось как нажатие на «установку часов», либо не воспринималось вообще. Проблема именно в МК, т.к. подключение кнопок вместо самой клавиатуры ничего не меняло.
ploop
А, ясно.
Тут ещё момент — там плата с контроллером по сути только коммутирует силовуху, можно попробовать приспособить или механическое реле времени, или обычный тумблер вообще без реле. Куда-нибудь в гараж сгодится кофе подогревать :)
Sun-ami
Готовых программ мультивибраторов (генераторов) в интернете полно, и с исходниками в том числе. Как и готовых схем мультивибраторов. И в том и в другом случае желательно представлять себе как работает схема или программа, чтобы настроить под себя и разобраться в чём дело, если сразу не заработает. В сенсорных кнопках ломаться просто нечему. Проблема ремонта микроволновки — в недоступности прошивки, если хочется иметь возможность отремонтировать микроволновку самому — возможно, нужно было изначально выбирать модель, для которой доступны сервис мануал, компоненты, и прошивка. Но в этой теме выбор концепции интерфейса обсуждается с точки зрения разработчика — а у него есть возможность научить устройство работать с другим тачскрином, или закупить их заранее для ремонта, если речь идёт о серийном устройстве. Или, если нет желания сопровождать устаревшее устройство — просто отдать исходники тем, у кого такое желание есть.
Alexeyslav
Нет, на МК мультивибратор все-таки надёжней.
Во первых — меньшее количество компонентов!
Во вторых — предсказуемость работы. На МК мультивибратор будет начинать строго с заданной фазы, а не как в дискретном в зависимости от луны, качества исполнения компонентов и влажности воздуха в комнате. Кроме того, есть исполнения контроллеров с температурной компенсацией тактовой частоты, а при необходимости добавлением внешнего кварцевого резонатора получаем точность поддержания временных интервалов до 5-6 знаков. В то время как обычный дискретный мультивибратор способен обеспечить лишь 2 знака. Есть конечно исключения — такой себе мультивибратор как ГИАЦИНТ, но сложность его конструкции…
Сделать мультивибратор на МК гораздо быстрее чем спаять дискретный(если не учитывать время установки Arduino IDE, но скажем так купить необходимые детали паяльник и припой тоже время занимает и гораздо больше) — взять готовый пример мигания светодиодом.
Недостатки же дискретной схемы — спаял и в 9 из 10 случаев оно НЕ ЗАРАБОТАЕТ по причине несоответствия параметров деталей, незамеченного непропая или КЗ в схеме. Уверен, тот кто впервые сталкивается с электроникой без инструкции(готового разжёваного примера и работающего паяльника с подходящим припоем) не запустит мультивибратор и за пару часов, какие там 10 минут? В своё время лабораторки по ТОЭ показали это довольно таки наглядно. Почему-то только у меня одного мультивибратор заработал сразу, а секрет прост — просто у меня уже был минимальный опыт.
В третьих, сделать устойчивый дискретный мультивибратор с периодом следования импульсов в несколько часов, как?
Сейчас, кстати, с применением математики связь стала возможной при уровне сигнала ниже уровня шумов на 28дБ, ну это не менее 100 раз. Сделать такой дискретный приёмник? как? Благодаря цифровой связи мобильник обеспечивает приемлемую связь при высоком уровне помех и уровне сигнала порядка -100дБ(-70дБ на мобильнике это 3 палки из 5 по уровню сигнала). В дискретной аналоговой технике это на уровне фантастики.
Neuromantix
Если дискретная схема грамотно спроектирована и аккуратно собрана — она работает в 100% случаев. Да. в аналоговой и дискретной схемотехнике деталей побольше, чем в МКшной, но не вижу в этом проблемы. тот же гиацинт по конструкции прост как бревно, в этом его прелесть и есть.
Для периода в несколько часов надо использовать не мультивибратор, а иную подходящую схемотехнику.
И еще раз повторюсь — изучение программирования тоже входит в «сделать». Только вот все упорно это отрицают.
ЦОС — это уже немного другая история. Хотя и у цифровой связи есть неустранимые проблемы, в частности бесит, когда цифровое ТВ намертво виснет при слабом сигнале. аналоговое лишь зашумливало картинку.
Alexeyslav
На самом деле это зависит от декодера, слишком тупой декодер не умеет снижать битрейт и вытягивать хоть что-нибудь из имеющегося сигнала — не хватает ресурсов по памяти и процессору. А само кодирование предполагает так же работу в достаточно плохих условиях, гораздо худших даже чем аналоговое при выделенной полосе частот. Кроме того, если цифровое перестаёт работать с ростом ошибок достаточно резко, то аналоговое деградирует постепенно, а современные требования к качеству картинки довольно высоки — никто не хочет смотреть видео даже с малейшим «снегом» когда этого можно избежать.
Если взять равные условия — ширину полосы цифрового потока в 8Мгц, как аналогичного аналогового, то обеспечить устойчивость картинки к помехам можно гораздо лучше чем у аналогового сигнала. Но зря чтоли цифровое ТВ внедряют? Основное преимущество цифры — уплотнение каналов на ограниченном частотном ресурсе при прочих равных условиях приёма.
ploop
На самом деле цифровое будет показывать без единого квадратика при уровне сигнала, на котором на аналоге и силуэтов не рассмотреть. Если виснет — это уже за гранью для аналога вообще.
nafikovr
Andy_Big
Никто не мешает прицепить резонатор и к дискретному мультивибратору :)
Очень спорное утверждение :)
Вы столько ужасов понаписали про конструкцию из трех деталей, что просто диву даешься как у людей работают конструкции из десятков и даже сотен деталей :)
А тот, кто впервые сталкивается с МК, не запустит его и за пару дней :)
nafikovr
С точки зрения менеджмента рисков изделие на мк действительно более надежное относительно того же изделия на логике.
Shpiler
Насчет замены кнопок на приложение забыли упомянуть еще один момент — кто будет писать приложение под телефон? Если все кнопки-крутилки-экранчики я разведу и запрогаю за два вечера, то приложение буду писать примерно вечность, или же придется нанимать человека, который умеет это делать, платить ему деньги и потом возмущаться почему ничего не работает (а в высокоуровневом софте со множеством целевых устройств и ОС баги будут всегда, в то время как прошивку МК можно довести — и обычно доводят — до идеала)
Хорошо, допустим у нас по условию задачи очень маленькое или глубоко спрятанное устройство, где кнопки ставить просто некуда. Ну или еще какая причина для управления с компьютера. Пишем протокол, окей, но зачем же кодогенераторы? Программисты настолько разучились держать в голове больше трех ветвлений? Есть примеры хороших протоколов, которые вполне можно написать руками, поддерживающие сколько угодно любых команд и никогда не сбоящие. Посмотрите на любое устройство, подключаемое по последовательному интерфейсу, авторы которого недостаточно стары, чтобы использовать MODBUS. RFID считыватели, купюроприемники, да сотни их. Всё прекрасно пишется руками под любой функционал.
А MAVLink чудовищен просто с самого рождения. Создан был как универсальный протокол для всех, большая часть его сообщений не поддерживается ни одним полетным контроллером, многие поддерживаются не так как хотелось бы пользователю и еще пойди разберись как и почему он (не)работает. Не надо так. Есть устройство, есть задача, под неё пишется протокол. Уж поверьте моему опыту, это упрощает разработку настолько, что даже в случае кардинальных перемен в ТЗ переписывание вообще всего с нуля становится вопросом пары дней нормального программиста.
Это ведь софт, его всегда можно переписать. Лучше закладывайте универсальность в железо, ведь его в случае чего переделывать гораздо дольше и дороже.
cheblin Автор
Ваш не воссторг по поводу но функционал который на него пытаются возложить от того не становится меньше.
вы гений. стабильный(как это недавно стало модно говорить) гений. реальность показывает что увы, не все такие. вместо ручного кодирования создают кодогенераторы. ленивые наверно.
Shpiler
Просто избалованные гигабайтами и гигагерцами. Почему то во времена первых полетов на Луну абсолютно всем программистам удавалось обойтись без многослойных пирогов из фрэймворков. И как то удавалось держать в голове каждый регистр. Да, их было меньше, чем сейчас, нынче и задач больше и кодеров надо много. Но ведь могли же люди писать вот так, не могла эволюция за 4 десятка лет дать такой обратный ход.
Shpiler
И так то я не против, пусть пишутся фреймворки и крутятся на них одиэсочки. Но не надо с таким подходом идти в хардварь. Я уже устал эти решения выкорчевывать из каждого второго проекта
REALpredatoR
Нет, спасибо. Как-нибудь обойдусь в доме без кучи вещей к которым при желании могут получить доступ по воздуху посторонние люди и сторонние приложения с неизвестным кодом внутри.
cheblin Автор
они у вас уже есть.
REALpredatoR
У меня нет бытовых устройств имеющих wi-fi, bluetooth, или выход в какую-либо сеть (интернет, или мобильную). Никто удалённо не включит мне электрочайник, микроволновку, или кондиционер, не выключит холодильник, не откроет краны водопровода, и не пустит мне кипяток когда я в душе :D
ploop
Кстати идея — краны с вайфаем! Удобно же, зашёл в душ, открыл приложение, выбрал температуру — вода пошла! Нажал «выключить» — упс… телефон что-то залило, не работает, но не беда — у нас же смартфонов как грязи, мы же люди современные!
Snakey
Не, еще лучше — в приложении стрелочки вверх и вниз для управления напором воды, а в другом приложении стрелочки вверх и вниз для изменения температуры. Первое приложение от водоканала, второе от местной котельной, а всего за 0.99$ в месяц доступ к объединенному управлению (+ термодатчик). Либо посмотри рекламу или наслаждайся кипятком в унитазе.
Всегда так заканчивается.
ProLimit
Спорные идеи у автора. Физические крутилки и экранчики НА ПОРЯДОК удобнее мобильного приложения, которое нужно еще скачать, подключить, разобраться в излишнем функционале (а он там 100% будет излишним), а еще он будет убогим и неюзабельным, если планируется использовать кодогенераторы для автоматиации труда ленивого программиста. По сути сейчас очень мало дейстивтельно хороших интерфейсов, и на них тратятся годы труда сильной команды. PS: сенсорный интерфейс современной микроволновки от LG периодически вызывает раздражение и ностальгию по двум крутилкам, которые были идеальным интерфейсом, но маркетологи в погоне за 1000+1 функциями его похерили.
impetus
у микроволновок типоразмеров плат управления не так уж много — блок, который сбоку от дверцы, который с управлением — подходит практически от любой к любой. Колхоз, конечно, но иногда оно того стоит. («нувыпоняли»)
Gryphon88
Как по мне, вполне разумный подход предложен. Особенно если:
1. устройство самопальное, т.е. есть контроль над прошивкой и железом
2. устройств или много однокнопочных, или они распиханы по глухим углам, или нельзя установить экран/лампочку, или интерфейс уж очень замудренный
3. планшет или телефон не выносится из помещения, где живёт управляемое оборудование и не заменяется на другую модель
4. ну и интернет — нафиг. Локальное приложение, планшет в режиме точки доступа или BT.
Жаль только, что если устройство повиснет или заглючит, придётся все равно с матюками цеплятся по UART.
cheblin Автор
На самом деле, статя о кодогенераторе, о том как с он решает многие проблемы написания кода.
Вынесенные интерфейсы, изменение конфигурации устройств на микроконтроллерах, это один из многих вариантов его применения.
Но, каждый видит и читает то, что понимает. Придется писать отдельную, скучную статью.
Gryphon88
Будьте добры. Обычно про кодогенерацию пишут или чересчур специализированно, или слишком академично, в т.ч. с использованием вымирающих технологий. В итоге как бы понятно, о чём речь, но в том, как пользоваться и когда оно вообще нужно ясности особо не прибавляется.
Andy_Big
Приложение как альтернатива и расширение физического интерфейса — поддерживаю. Как единственный вид интерфейса — ни в коем случае. В большинстве бытовых приборов в 90% случаев используется всего 3-5 функций (в телевизоре, например, вкл/выкл, переключить канал, изменить громкость, иногда выключить звук). Все эти чаще всего используемые функции должны быть доступны в физическом интерфейсе — быстро, одним движением. Телевизор, управляемый только из приложения на смартфоне — это извращение. Бытовые весы без дисплея, выводящие показания только на смартфон — это извращение в квадрате.
Ig_B
Думая о своих потребностях в протоколах, вижу, что и MODBUS это больше, чем надо, и собираюсь сварганить что-то свое, попроще. Руками.
Однако, если возникнет потребность в сложном протоколе, посмотрю в сторону BlackBox
cheblin Автор
MODBUS это просто транспорт, как и UART.
он не описывает пакет. и какие данные передаются в пакете.
BlackBox — по описанию создает код который способен, сформировать пакет, залить данными, сжать данные перед отправкой, посчитать CRC, приложить к пакету… и так далее
в тексте есть ссылка на на дескриптор протокола mavlink
это не сам протокол, а только дескриптор. по нему будет сгенерировано куча кода.
Ig_B
MODBUS все-таки протокол. И для примера вы могли бы написать его дескриптер для BlackBox, чтобы оценить удобство модификации под свои нужды.
cheblin Автор
UART тоже протокол. транспортный.
как TCP или UDP.
никаких модификаций в BlackBox вносить не нужно. код сгенереный BlackBox создаст пакет, предоставит API заливки пакета данными, сериализации его в бинарный вид (байтовый массив) который вы самостоятельно передаете, любым транспортным протоколом.
а на сервере все наоборот. посмтотрите. все примеры доступны в репозитории.
Sun-ami
Нет, согласно модели OSI, UART — это не транспортный протокол как TCP, и даже не сетевой, как IP — это канальный протокол, точнее всего лишь часть его подуровня — MAC.
lingvo
Я принял решение в своих изделиях разделить управляющий контроллер и GUI на разное железо.
Т.е. управляющий контроллер не имеет на борту GUI, и работает в реальном времени.
А для GUI берется обыкновенный Raspberry Pi или его аналоги с линуксом, который связывается с управляющим контроллером по какому либо из локальных интерфейсов (в моем случае это CANopen) и уже дает пользователю все возможности настройки и управления — по BT, Wi-Fi, Ethernet и пр. Финальная цель одна и та же — дать пользователю управлять моим изделием с планшета/телефона
Но тем не менее Ваш подход тоже интересен. Допустим у меня есть STM32F4XX с подключенным к нему Bluetooth модулем. И мне нужно посылать на STM32 управляющие команды и принимать диагностическую информацию на смартфон. Как ваша идея может мне помочь? У вас уже есть работающие приложения — примеры?
cheblin Автор
зачем? будет хуже чем любой, даже древний, мобильник…
зачем? у вас связь происходит по длинным протяженностью(50-100 метров) проводам?
на линии куча устройств которые могут конфликтовать?
простите, вы ТОЧНО прочитали написанное?
ок. найдите в тексте и начните читать с
и ссылки. в тексте очень много ссылок, на исходники, на документацию
если останется непонятно, продолжим.
lingvo
Я имел ввиду в качестве сервера, которому и будет подключаться мобильник или любой другой клиент в том числе удаленный.
Да. Это принятый стандарт в моей отрасли. Система состоит из центрального контроллера и кучи разбросаных I/O модулей.
Хмм, я не заметил ссылки на App Store, или хотя бы на .apk файл демки. Без этого как-то не хочется даже открывать исходники или документацию и терять свое время.
ploop
Вообще-то по уму так и делается.
Gryphon88
Можно ваше мнение: я видел такие решения, когда на микроконтроллере ничего или почти ничего (например, опрос датчика по таймеру), а переключение GPIO управляется по UART с приложения с компьютера. Такой подход вообще разумен и используется, или я наткнулся на экзотику и инструмент прототипирования?
ploop
Не совсем понял, как оно работает. Контроллер используется просто как набор GPIO с интерфейсом UART? Ну если цель такая, то всё нормально. Если цель опросить датчик и передать на комп — то дичь конечно…
Gryphon88
в прошивке Кухтецкого (не только у него, видел несколько похожих реализаций) сделано по-пионерски:
Но я видел и проекты, которые использовали эту прошивку с модификациями как раз для опроса датчиков или управления ШД; правда, там где были критичны временные интервалы, были сделаны в прошивке функции, которые дергались по USB, и дополнительно прописаны обработчики соответствующих прерываний
ploop
Ну да, как я и говорил — если цель с ПК рулить исполнительными устройствами (дёргать и читать GPIO), то делается такое. В примере выше в большинстве случаев можно вообще не использовать контроллер, а обойтись какой-нибудь FT232RL или аналогом, поддерживающим бит-бэнг, но статья за 2009 год, не знаю, распространены ли были они…
Всё зависит от задачи, и в принципе нет «плохих» или «хороших» подходов, есть плохие и хорошие реализации :)
Krey
Так иногда делается, когда нужно обеспечить равные отсчеты времени, например в PID регуляторах. ОС общего назначения часто не в состоянии этого сделать с заданной частотой и допуском.
Gryphon88
Можно чуть подробнее? Мы тогда должны непрерывно писать в USB на контрольную точку, чтобы «тактировать» пакетами? Не понимаю, как можно обеспечить сколь-нибудь точный таймер от ОС общего назначения
Krey
Не, я имею ввиду применение когда нужно замерять какие-то параметры с точным интервалом времени, а обрабатывать и выполнять команды в менее жестком времени.
PKav
Первое. У меня в квартире отлично принимаются 4 WiFi сети с паролем 12345678. Какое ещё количество людей не будет менять дефолтный пароль на WiFi и Bluetooth? А теперь представьте что будет, если кто-то перепрошьет чайник и включит его нагреватель на весь день пока хозяин на работе? Или прошьет стиральную машину и откроет клапан залива воды?
Далее. Телефоны тормозят. Тормозит само приложение, тормозит связь. На той же стиральной машине мне нужно после загрузки белья сделать 5-7 нажатий чтобы началась стирка. С телефоном пока дойдешь до телефона, пока откроется приложение, пока свяжется со стиральной машиной… С чайником ещё веселее — одно нажатие кнопки заменяется всей этой ерундой.
Третье. Беспроводной модуль связи тоже может отказать. Легко и непринужденно. И устройство превратится в кирпич.
И последнее. Удобный интерфейс сделать сложно. Реально сложно. Очень много приложений для смартфона напоминают мне картинку «Превозмогая трудности». И если для приложений общего назначения часто есть аналоги, то для конкретных устройств их нет и никогда не будет.
Итог. Управление со смартфона имеет право на жизнь только если его можно отключить из нормального кнопочного интерфейса с экраном.
cheblin Автор
что за место-то такое проклятое?
статья не столько про перенос интерфейсов. она про кодогенератор исходников обработчика бинарного протокола BlackBox. поскольку при переносе интерфейса — получается распределенное приложение, для BlackBox это одно из возможных его применений.
slovak
Проверить, что спецификация успешно компилируется, и послать её исходник, в виде аттачмента письма на почтовый адрес OneBlackBoxPlease@outlook.com.
Плюс одно подтверждение названия проекта.
cheblin Автор
в ответ будет выслан исходный код. с комментариями всего API. что не так? как это должно быть?
madf
Холивар не о чем (ибо отсутствует основа понимания схемотехники и подхода к задаче), видимо хотелось просто что-то написать на Гиктаймсе.
Экраны и кнопки будут всегда, т.к. вместо заумного и избыточного мобильного устройства, всегда есть надежность, простота использования в законченном изделии.
cheblin Автор
Диод надежнее любого ПЗУ. :)
ploop
Именно. Поэтому в грамотно спроектированном устройстве всегда есть компромисс между железной частью и программной.
Moog_Prodigy
>служба поддержки BlackBox разбирается с возникшим затруднением.
Вопрос, а служба круглосуточная? Сколько операторов в онлайне? Если один человек — это несерьезно. Когда проект завязан на одного человека, никто не застрахован от его хотелок, ошибок или исчезновения (смерть например).
А серьезно станет всё, когда она превратится в техподдержку очередного фреймворка и захочет за это денег. Какие гарантии, что все предыдущие скомпилированные проекты, дорвавшись потом хоть раз до интернета (ну, мало ли?) не сделают из моего дома гостиницу «Экономическая»?
И кто несет ответственность за баги в скомпилированном коде и логику его работы. Автопроизводители то еще не до конца определились по поводу автопилотов и вспомогательных систем.
cheblin Автор
пока нет. все на самом начальном этапе.
просто то, что сработало у меня, показалось мне красивым и начало приносить прибыль, я решил сделать публичным достоянием.
сейчас команда — это один человек.
поэтому, для того чтобы успевать, всё, что можно было автоматизировать, уже автоматизировано.
со временем, когда у этого проекта, в его новой форме, появится некоторая модель получения прибыли, появится команда.
скорее всего проекты малой сложности, и полностью открытые, так и останутся бесплатными.
этот проект не попытка поправить свои финансы. у меня с этим и так не плохо.
хочется сделать, полезный сервис, который будет совершенствоваться и привлекать качеством продукта. его самоокупаемость при стабильном развитии — уже для меня будет успехом.
вы получаете полностью протестированный, заказанный код в исходниках.
из обременений у вас только обязательство указывать, что в вашем продукте используется код сгенерированный BlackBox.
код от BlackBox не лазит в интернет. он помогает только удобно упаковать (сериализовать) данные в байтовый массив и восстановить их обратно. вы самостоятельно решаете, как эти данные будут переданы.
гарантией вашей безопасности является ваша грамотность. впрочем это касается не только кода от BlackBox.
ответственность за баги кода от BlackBox будет такая же, как и создателя у продукта, в котором этот код будет работать.
хотите разделить ответственность?
не вопрос, обсудим.
одновременно с вопросом о разделе прибыли.
svitoglad
Почему-то для управления станками до сих пор активно используют кнопки и это при наличие на пульте тачскрина.
www.youtube.com/watch?v=goIE7KRxXcI
lingvo
Там есть своя специфика. Например оператор CNC может иметь на руках толстые рабочие грязные перчатки, которыми в тач-скрин тыкать не очень, а в большие кнопки — легко. Обычно это всего несколько кнопок — старт/стоп и выбор нескольких предварительно запрограммированных программ, иногда кнопки ручного управления, где важна скорость реакции и тактильная обратная связь. Ну и кнопка аварийной остановки — грибок — маст хэв должна быть железная по правилам безопасности.
cheblin Автор
спасибо за Ваш комментарий, но статья в основном посвящена кодогенератору BlackBox.