Arduino.ru

http://blog.amperka.ru/micro-python

Micro Python(MP) — это названия и платы, и языка на основе Python, на которой она работает. В сравнении с Raspberry Pi и Arduino автор проекта приводит целый ряд преимуществ своей платформы:

1. Мощность — MP мощнее в сравнении с микроконтроллером Arduino, используя 32-разрядные ARM процессоры типа STM32F405 (168MHz Cortex-M4, 1 МБ флэш-памяти, 192Кб ОЗУ).
2. Простота в использовании — язык MP, как уже было замечено,  основан на Python, но несколько упрощен, для того, чтобы команды по управлению датчиками и моторами можно было писать буквально в несколько строк.
3. Отсутствие компилятора — для того чтобы запустить программу на платформе Micro Python нет необходимости устанавливать на компьютер дополнительное ПО. Плата определяется ПК как обычный USB накопитель — стоит закинуть на него текстовый файл с кодом и перезагрузить, программа тут же начнет исполняться. Для удобства все-таки можно установить на Пк эмулятор терминала, который дает возможность вписывать элементы кода с компьютера непосредственно на платформу, используя его вам даже не придется перезагружать плату для проверки программы, каждая строка будет тут же исполняться микроконтроллером.
4. Низкая стоимость — в сравнении с Raspberry Pi платформа MP несколько дешевле, и, как следствие, доступнее.
5. Открытая платформа — также как и Arduino, Micro Python является открытой платформой, все схемы будут находиться в открытом доступе, что подразумевает возможность спроектировать и создать подобную плату самому в зависимости от потребностей.

Есть варианты и ещё мощнее и гибче. Нужна полноценная ОС, которая и будет всем новым железом автоматически рулить. Можно и на дуине такое навертеть, но всё будет очень медленно работать, потому как на самой дуине получится только ядро ОС, а вся переферия неизбежно останется жить на внешнем диске, который нужно будет постоянно читать.

Круто! Хотя вроде слышал что Распберри не так хороша в работе с железом, как Arduino в силу каких-то осбенностей ахитектуры..

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

Вобщем-то это не сильно лучше чем связка Linux + Arduino например, где можно кидать файл с кодом в скрипт на линуксе (или в винде наверное тоже) и он будет компилировать и прошивать им Adruino.

ourlive

В качестве полноценной ОС можно использовать например Raspberry Pi  или аналог с Линуксом на борту и через него уже управлять Дуиной, которая будет рулить железками, Но тут большой минус именно в возможности перехватить исходный код - Как бы этого избежать? 

Поэтому интересует модель именно "плагинов", когда закрытый исходный код не изменяется, а обогащается возможностями плагина (желательно тоже с закрытым кодом).. 

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

Ну с проверкой хеша это самособой, это не проблема. 

Насчет писать свою ОС - это конечно сильно.. зачем? вобщем-то весь софт коммерческий пишется для винды, мака и линукса и вроде все хорошо.

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

Проект не для школьников как раз, иначе зачем было бы про безопасность думать..

Просто к примеру если все зашить в контроллер и залочить - то уже невозможно вытащить оттуда код программы.  

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

Главное понять хочу, по какому принципу происходит подключение этих "модулей" и что они из себя представляют.

(Добавлено:)

Вот например, PS3 - никому так и не удалось взломать эту систему и обойти защиту. Пиратских дисков к ней нет, а к x-box есть все.  Хотя как раз таки есть обновления файлов прошивки через интернет (значит их можно перехватить), расширение функционала, возможность скачивать приложения (т.е. своего рода плагины\модули, которые имеют полный доступ к аппаратной части).. И при всем при этом - есть физический доступ - можно разобрать, попытаться подключиться к пинам процессора и т.п.  но никто ничего не смог сделать.

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

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

а в общем смысле не понятно зачем нужна это возьня с загрузкой "драйверов". Чем загрузка драйвера на флэшку проще заливки прошивки?

Конечно я думал в эту сторону, но всего не предусмотришь. 

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

А вот когда речь идет о подключении чего-то вроде произвольного шилда или нового вида датчика - то нужны библиотеки.. и как то нужно их устанавливать.

Заранее всего не заложишь.. я же не могу значть что понадобится пользователям и к тому же что мы сами намудрим из переферии за год-другой.. И что потом - предлагать покупать новую версию продукта? или бесплатно менять? Все это плодит сущности и связывает руки. 

Поэтому хотелось бы так:  подключается "лицензионная" приблуда - программа её распознает, лезет в интернет и скачивает нужные для неё обновления.

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

Может быть можно использовать уже скомпелированные двоичные данные, зашифрованные например. 

В любом случае пока не соображу - как можно подключать такие внешние куски.

для самопрошивки придумано бутлоадер, но его размера  в AVR для работы с интернет врятли хватит

но можно поставить два МК - один будет иметь не изменяемую прошивку которая отвечает за обновление софта, а второй МК собственно и будет обновляться

Конечно именно так, только вместо второго МК я планирую использовать микрокомпрьютер по типу Raspberry Pi  с Linux.  Но опять же - с прошивкой все упирается в небезопасность её передачи и хранения.

распбери умеет выполнять код из оперативки и с флэшки, там вообще не нужны такие заморочки и все можно делать как с привычным компьютеров. только зачев вам в этом случае МК?

Ну насколько я знаю Дуина лучше справляется с "железными" задачами, чем Raspberry Pi, не даром коптеры и прочие роботы строят имено на Ардуино.. Но в любом случае речь идет не о Raspberry Pi а о мини компьютере (стике) на OC андроид\линукс  а там поддержки работы с железками и свободных пинов нету.

ничего подобного, у распбери полноенны порт ввода-вывода, а не используют его скорее всего потому что он громоздкий и излишний для таких задач

а не проще ли вам сделать банальный "расширитель портов" для вашего андроида? через тот же USB, зачем такой огород городить?

Т.е. дать возможность приставке работать с вводом-выводом и обойтись вообще без Arduino?

Не думал об этом может в этом что-то есть.

Но даже если так - мне все равно не понятно как реализовать безопасное подключение кусков кода (плагинов) - к программе.. даже на полноценной ОС.

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

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

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

Так что это будет уже не открытый проект, все довольны.

Но это уже все лирика - как и что использовать платно или бесплатно - личное дело каждого разработчика.

Так что логика не страдает.

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

Если нет, то хотелось бы уже обсудить по существу. Как например происходит взаимодействие с подключаемыми плагинами\модулями  в Java или в Processing? Например откуда берутся дополнительные глобальные переменные для работы с данными плагина,  ведь число подключаемых модулей не ограничено, стало быть, заранее они зарезервированы быть не могут.  Как происходит добавление новых функций? Понятно, что например добавить в меню новый модуль - значит запросить список файлов в папке, и согласно их именам создается массив пунктов меню "плагины" например. Но как происходит исполнение кода этих модулей?  

Я просто имел дело только с программированием AVR и незнаю, может на полноценной ОС там другая логика.. вот хотелось бы суть понять в кратце.

с этим вопросом вы ошиблись форумом

Просто вы столько раз сказали мол "сделали бы на полноценной ОС и нет проблем" что я решил что может и правда там все так просто и не возникает подобных вопросов. Если знаете - то поделитесь. 

А если нет, то давайте думать над сутью дальше, просто не ограничиваясь пространством МК.  Вобщем-то Arduino в связке с Processing  - это входит в тему форума, и это можно считать работой на полноценной ОС. Вобщем-то через firmata можно управлять всей аппаратной частью дуины через процессинг, например, но это все равно не снимает вопроса - как расширять функционал модулями\плагинами\обновлениями.

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

мои выводы:

- если применять полноценную ОС то ардуина/МК не нужны

- если делать все на МК не понятно для чего все это? без понимания задачи и обсуждать нечего

Но мне инетеснее понять логику работы с подключаемыми модулями - о которой я спрашивал.

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

Для примера есть у вам arduino nano, светодиод (чтоб мигать) и динамик (чтоб соответственно пищать) собранные в виде шилда. В нану зашит скетч который по внешним командам (предположительно из текстового файла) конфигурирует нужные порты на выход (проверив подлинность файла по вашим алгоритмам). Подгружает следующий файл инструкций (псевдоскетч) в котором нет упоминаний ни о каких портах, но есть инструкции что делать с диодом и динамиком. Так оно работает на ПК, на что между прочим тратится до 80% ресурсов машинного времени (не дай бох какое приложение получит прямой доступ к регистрам процессора или адресному пространству оперативы). Зато безопасно.

функционал чего?

ourlive

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

Что они из себя представляют?

из того что вы сказали - значит доступы к портам Input\OutPut само собой, а дальше псевдоскетч.. не совсем понимаю что это. Видимо как раз логика работы с устройством.

Я думаю что напрямую код передать нельзя, значит нужно писать параметры по какой-то классифицированной схеме. например подать High =1 подать Low=0 и потом читать эти данные через Switch.. довольно неудобно.  А если например нужно сделать сравнение, то нужно видимо сделать функцию compare(val1,val2,type) где на входе будет 2 значения которые нужно сравнить,  и тип сравнения, например 1- <, 2- >, 3- ==, 4- != и т.п.  и возвращать true или false

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

Хотя может я что-то не понимаю.

Клапауций

функционал устройства конечно же.

Если мои абстракции слишком абстрактны - привожу пример, максимально близкий к планируемому применению: Умный дом.

Есть центральный контроллер (Адруино+ мини PC на линуксе) и к нему подключаются управляемые устройства и датчики. Освещение (через реле), градусник за окном, кондиционер, датчики присутствия и т.п.

Если человек захочет управлять еще и кофеваркой например, то ему не нужно менять контроллер  - он просто покупает "рекомендованную" кофеварку (которая умеет отдавать и принимать определенные данные), подключает её к свободному порту контроллера, контроллер определяет её и лезет на сайт разработчика за дровами. Скачивает обновления и готово. В пользовательском интерфейсе появляется вкладка для настройки "кофеварка" - и теперь можно сварить себе кофе из другой комнаты, но что более важно: можно задавать зависимости от других подключенных устройств. Например:

Человек подключил барометр, или погодную станцию.. И теперь он может задать в настройках - что если барометр показывает дождь - то готовить Латте-макиато, а если солнечно - то Эспрессо. 

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

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

Вы же сами описали требования, которые решаются только методом виртуализации. Плагин по определению подключается к чему то. Вот это "что то" вам и нужно написать. Ад-не ад, но или меняйте тех задание или получайте туеву хучу работы для немаленького отдела кодеров на несколько лет. Ведь описать нужно отдельно все функции языка, переписать с нуля все потенциально востребованные библиотеки, отладить все несуразици и конфликты. Да ещё и сделать это так, чтобы потеря мощности процессора на виртуализацию была по возможности минимальна. По сути проще написать новый язык.

Вот, приведенная вами ссылка на википедическую статью "Плагин" - полностью соответствует тому что мне нужно. А основное приложение - это как раз оболочка, полозовательский интерфейс и некий базовый функционал. Вот, в статье увидел что плагин - это отдельное скомпелированное приложение.. или Разделяемая динамическая библиотека.. Значит насколько я понимаю, на МК это запустить не получится - только на ОСи. 

Может потому, что я никогда не сталкивался с "динамическими библиотеками" я и не понимаю как они могут использоваться сразу несколькими программами, и расширять функционал без перекомпиляции.. Вот об этом и вопрос. Например в Procesing -е можно работать с такими библиотеками -плагинами? И если да, то где можно почитать подробнее, лучше бы с примерами.

интересно, как давно у вас наблюдаются симптомы путанья мыслей? к доктору обращались?

давайте прикинем изначально. что именно такого вы собрались подключить к МК для чего бы понадобилось создавать драйвера и причем без перекомпиляции... тоесть что бы воткнул и оно заработало?.. давайте определите список таких устройств..

"только на ОСи" так вам это в самом начале сказали, что нужно писать полноценное ядро ОС, а уж на каком железе будет жить дело хозяйское. Многие МК между прочим сейчас мощнее большей части компов 20ти летней давности, а про функционал можно и вовсе молчать, не соизмерим.

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

Конкретно я ничего подключать не хочу, и поставленную ТС задачу считаю порочным порождением капитализма.

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

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

гыыы так в чем проблема то? тоесть подключение различных устройств и шилдов это видимо очень простая задача. гораздо проще чем втыкание УЗБ кабеля от компа и заливка новой заранее изготовленой прошивки? что мешает вам написать готовые скечи к каждому шильду, скомпилировать и написать бат в 3 строчки который будет прошивать это все в один клик?

но возращаясь к БАРАНАМ, что бы это работало в режиме plug&play, вам для начала придется разработать спецификацию, протоколы и прочее барахло. потом напроизводить мешок всякого разного гавна. которое в конце концов один хрен будет глючить! 

Puhlyaviy: Забыл выделить ещё одно ключевое слово в требованиях "без перепрошивки" базового устройства.

А вот про вторую часть вашего сообщения полностью согласен. Ну раз ТС надо, пусть делает, в принципе же это возможно.

это не ключевое слово! ибо оно просто лишено смысла! что бы что то присоединить к МК, нужно проделать операции гораздо сложнее чем воткнуть УЗБ шнур и кликнуть мышкой!

ибо даже ПС не работает без перепрошивки. пока ОС ей не прошьеш. будеш наблюдать ничего :)

Кто это вам сказал, что смысла лишено? А как же тогда все современные компьютеры работают? По вашему чтобы переподключить мышку или клавиатуру с хаба №1 на хаб №2, нужно перекомпилировать ядро ОС, а то не заработает? Всё это вполне можно осуществитьт в упрощённой форме на МК.

нужно изменить ОС. разница что в МК изменния нужно внести во флеш память. а на ПС нужно внести измения на диск.

и еще раз ЗАЧЕМ?

даже если взять ПС вы часто в него что то втыкаете и вытыкаете? типа видео карту меняете каждые 20 минут? , жеский диск перставляете с операционкой раз в час?

а в собраном МК я вообще не вижу смысла что то переставлять...

Про замем, это не ко мне, я только о возможностях размышляю. Внести изменения на диск, это не тоже самое, что изменить ОС. Вы путаетесь в терминологии, и соответственно путаете других.

Для справки:

"Микроконтроллеры AVR имеют гарвардскую архитектуру" (Википупия)

В отличие от "современных компьютеров", у которых единое адресное пространство (все, кроме BIOS, размещается в RAM, но и ROM обрабатывается одними и теми же машинными командами - при чтении вы даже не заметите момента перехода границы RAM-ROM).

Куда вы собрались подгружать коды плагинов в АВРках? В RAM? Там они не выполнятся (гарвардская архитектура, мать ее ети). В программную память? Так это та самая перепрошивка, от которой вы всеми силами пытаетесь избавиться.

Хотите "плагинности" - переходите на микроконтроллеры, умеющие выполнять коды, размещенные в RAM (ARM, например, или Б41). Либо ставьте микроконтроллер на сам шилд и размещайте в этом микроконтроллере дополнительную функциональность. А в систему "МК Ардуино + МК шилда" добавляйте протокол, обеспечивающий разрешение конфликтов (семафоры там разные, диспетчер....)

step962: То ли я дурак, то ли ноги не идут... Вопрос виртуализации для ардуины закрыт теоретически (сам термин "виртуализация" понятен?)? Можно же обойтись без прямого тоступа хоть к ROM, хоть к RAM и обходится заранее выделенным массивом. Даже многозадачность (пусть и не в классическом виде ОС) в стандартных примерах есть. То что это не рационально я знаю.

avr может исполнять программы из eeprom и с sd карты. См. bitlash

toc

Спасибо! Более чем интересно!  Практически то что нужно.. единственное - с позиции опять же безопасности может подхрамывать, но в целом можно найти решения. Очень любопытное решение). Разве что занимает кучу памяти, другие вещи могут не влезть. И не совсем понял - есть ли там указатели, т.е. можно ли из одного загруженного макроса, ссылаться на другой.

Puhlyaviy

Несколько постов выше я уже описылвал конкретный пример: умный дом... что непонятного? Таких устройств божет быть сколько годно много, не представляю даже что вызывает ваше недоумение. Программирование кофеварки как вариант например) Управление освещением, управление сервами (они без драйвера не поедут), чтение данных с датчиков температуры и влажности, управление реле, LCD дисплеями... да вообще  - любое устройство которое возможно подключить к МК потребует своих инструкций.. что тут не ясно то?  

И да, все ради плаг энд плэй.  и взаимной интеграции. потомучто иначе никак.

А давать с каждым устройством прошивку и установщик - то тут сразу 2 камня предкновения:  

безопасность само собой.. кто же дает исходники..

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

ourlive

Вы хорошо поняли что я имею ввиду..  хотелось бы услышать ваше мнение по поводу bitlash

А по поводу ОС - думаю чем поднимать ядро ОС на МК проще поручить это делать приложению скажем на процессинге..  и реализовать отдельные модули\плагины как dll библиотеки (если это можно сделать на процессинге) .А для достижения безопасности думаю очень эффективно было бы использовать свойства "черного ящика".. т.е. нп пользовательской стороне будет лишь клиент, не содержащий в себе критической логики, который будет обмениваться данными через протокол с сервером - отдельным устройством содержащим ОС Linux и программу обработчик. Который в свою очередь, будет также обмениваться данными с МК, находящимся в той же коробочке. Т.о. взлом клиентской программы практически бесполезен, а доступ к "серверной" части сильно затруднен. В качестве пароноидальных средств можно установить крон, проверяющий целостность кода, и если он был нарушен или изменен, то весь раздел просто сносится к чертям)

Что касается загрузки обновлений то они могут скачиваться в зашифрованном виде клиентом, а затем  побайтово передаваться в обработчик (на сервер), который уже расшифрует и установит их у себя.

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

step962

По поводу ARM можно тоже поразмышлять, сейчас собираю прототип на ардуино, но не думаю что стоит им ограничиваться. Проблема ARM на мой взгляд в том, что с них можно снять дамп оперативы. На AVR это сложнее, а если выставить атрибуты залочивания, то вообще вроде выводится каша.

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

А когда речь идет о простейших датчиках - то установка на них своих мк неоправдана, и сильно удорожает их.

Зато на мой взгляд такой подход лучше в плане безопасности - влезть в такую закрытую систему куда сложнее.

гыыы, тупой и еще тупее.. по вашим измышлениям уже видно что вы даже не брали на себя труд поразмыслить как и что работает и опыта работы с МК у вас нет. :) и что самое смешное вы даже про умные дома на МК не читали ничего, иначе бы представляли откуда ноги растут..

намекаю БОЛЬШИМИ БУКВАМИ :)

МК СТОИТ ПОРЯДКА 5 БАКСОВ ( в среднем)

avr может интерпретировать программы из eeprom и RAM (с SD-карты они будут загружены в RAM). Но это именно интерпретация. Скорость такого "исполнения" на порядок ниже, чем для скомпилированной программы. Для некоторых неторопливых приложений это не имеет никакого значения. Для некоторых - ставит крест на возможности их реализации.

А смотреть можно не только bitlash, но и встроенные бейсики, и си-интерпретаторы, и тот же forth...

Насчет "дампа с оперативы" - и что с того? Запишите ключевые функции в flash, закройте ее от чтения (у ARM-контроллеров это реализуется более эффективно, чем в AVR). И все...

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

это безполезное занятие. товарищ пытается расуждать о МК с позиции своих представлений о копьютерах. :)

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

кто вам не давал сказать всего лишь одну фразу "умный дом", я б сразу сказал - забудьте про плагины. Все устройства должны быть модульнозаконченными и общаться между собой по средством одной или нескольких типов стандартизированных шин данных. Например все низкоскоростные устройства не относящиеся к системам безопаности работать по 1-wire и обслуживаться функционально разными контроллерами. UART для среднескоростных, но малообъёмных данных и т.д.. Например датчики температуры имеют прямое отношение только к климатконтролю, и посредственное дублирующее к пожарной безопастности. Датчики присутствия это и охрана и система управления освещением и тот же климатконтроль. Стройте децентрализованную систему на малых МК, это на порядки надёжнее, чем брать 1-2 больших и толстых, да ещё и отдавать решающие  функции центральному серверу. Приведу пример моего понимания "умный дом": контроллер обслуживающий рыбок в аквариуме (включающий/отключающий свет по расписанию, жужащий иногда насосом и т.п.) выясняет, что лампочка у него сгорела, обращается к контроллеру рулящим общим освещением типа: в зону "аквариум-подоконник" нужно света в объёме 150лк, текущий 50лк, приоритет низкий. Контроллер освещения в свою очередь выясняет, что в помещении никого нет, пользовательского запрета на включения зонального освещения нет, контроллер энергораспределения лимиты не устанавливал т.е. можно рыбкам и посветить. И далее изучает обстановку: шторки закрыты, на улице день, но не солнечно - даёт команду:  шторки открыть, выясняет норму света над рыбками у рыбьего МК -120кл, добавляет до требуемого зоновым освещением. Все счастливы (особенно рыбки). Утрированно, но как то так.

Или например контроллер протечки водопровода напротив должен быть полностью автономным, единственное что он отдаст в общую сеть, это "нагистральные краны перекрыты, жду ремонтную бригару". Сервер данные записать и оповестить смской и емейлом всех заинтересованных, возможно подать звуковое оповещение об аварии.

Единственная проблема будет в разработке мегапротокола с далеко идущими перспективами и приемлемым уровнем защиты. Но это на порядок проще, чем писать плагины. Возможно часть устройств и имеет смысл заставить работать через bitlash (там книжка толстая и вся на бусурманском, сами читайте возможности), где логика сложная и её нужно будет время от времени апгрейдить. Но все устройства имеющие отношение к безопасности должны апгрейдится только аппаратным способом.

жеваный крот.. ну зачем.. теперь все пойдет по новому кругу. только теперь про протоколы которые нужно апгредить налету :)

ага

тут изначально же было видно, что товарищ не вкуривает про что при стоимости МК в среднем 5 баксов, его проще к каждому датчику приделывать и разбрасывать везде где не попадя, не заморачиваясь апгрейдами. ибо проще выкинуть и собрать новый.

Puhlyaviy

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

А то что 5 $ это не деньги что ли?  Если датчик в китае стоит 1$ то примотать к нему контроллер - это удорожить его в 6 раз!!  А еще работа по перепайке, и т.п. - это еще дороже. 

Куда легче один раз написать плагин для работы с этим типом датчика. 

А выкинуть и купить новое это не наш метод.. автомобили сейчас тоже видимо по вашей логике собирают, что они служат по 3-5 лет и разваливаются. Чтобы собрать или купить новый - человеку нужно как минимум выйти из дома и пойти искать - а это для современного потребителя просто непосильная задача. Все должно быть онлайн. Поэтому разумные люди делают так, чтобы потом ничего не менять и не переделывать. Вещь должна служить пока не перестанет удовлетворять запросам, без ремонтов и замен.

гыыы да вы еще и про потребителей ничего не знаете :) давайте я вам раскажу про среднего потребителя..

чем меньше ты ему оставиш возможности залесть куда то ручками и чего то там править и настраивать, тем больше сэкономиш на поддержке и печати инструкций.. и тем счасливей будет потребитель, ибо он будет думать что у вас все так шикарно работает и вы очень клевый производитель.. (самый крупный пример apple со своей продукцией)

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

даеш потребителю готовое решение и он счаслив.

Так я то это и понимаю.. а вы мне говорите что замена блоков - это лучшее решение (дешевле выкинуть и заменить), да еще что-то про сборку.. 

А я таки и говорю как раз про плаг энд плей: воткнул, скачались драйвера сами собой и все работает.. ничего пользователю делать не нужно.. у всех есть постоянный выход ви интренет и постоянно все программы себя обновляют, пользователь даже не замечает.

А так получается: придумали новый функционал (по сути - новый способ использовать уже существующие возможности системы) - будб добр купить "новую версию".. 

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

Можно их конечно прошить прямо на устройство и брать оттуда, без выхода в интернет - но тогда мы теряем возможность обновлений, и должны будем удорожить устройства еще и добавлением флеш памяти.. 

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

то что вы не понимаете это и так для всех очевидно :)

и врятли поймете пока не составите список своих датчиков и не посмотрите так ли их много...

вам выше уже написали. только вы не хотите думать. а разжевывать я не стану. лень

Draghkon: вот валяются у меня несколько lcd экранов, ethernet-шилд, комплект радиомодулей. Есть россыпью 1-wire датчики температуры, и даже откуда то завелось несколько терморезисторов. Хочу что бы всё это завелось на меге, по езернету отдавало данные в локалку, по уарт в ПК. А радиомодули связывают мегу с наной, которая караулит один фотодиод, и крутит две сервы. Жуткая мешанина всего, как вы и заказывали, набросайте алгоритм работы этого по вашим представлениям.