Предложения по развитию проекта MegaD
-
- Сообщения: 395
- Зарегистрирован: 17 фев 2013, 23:49
- Откуда: Волгодонск, Ростовская обл.
- Контактная информация:
Re: Предложения по развитию проекта MegaD
Pavel v, по Вашему вопросу тут очень много тем создано, давайте не будем тут флудить, а воспользуемся поиском?
Например можно обсудить сервер тут Кстати про сервер ...
Например можно обсудить сервер тут Кстати про сервер ...
Re: Предложения по развитию проекта MegaD
To Pavel v:
1. Да, как и сказал Andrey_B, доставка с алиэкспресс не быстрая, месяц-два, как и все посылки из Китая.
2. Краны есть всякие нужно только поискать, вот например:
http://www.aliexpress.com/wholesale?Sea ... 1220021036
3. Датчики давления, да, на 4 атм. но у меня выше и не бывает. Если поискать, то есть всякие, смотря какие нужны.
4. На счетчиках написано: "ВСГд-15" (горячая вода) и "ВСХд-15" (холодная вода) внешне выглядят вот так:
http://www.tehnopostavka.ru/kipia/index ... ductID=118
http://www.tehnopostavka.ru/kipia/index ... ductID=119
те которые со стёклышком.
То Всем остальным:
Вопрос уже в том что становится жалко IP адресов. Приходится все управление переводить в другую подсеть, а это немножко уже не удобно.
Ответ на будующий вопрос:
Нет мегадевайсов не такая куча в сети. в сети есть еще IP камеры, телевизоры, андроид планшеты и все прочее что ломится в сеть.
1. Да, как и сказал Andrey_B, доставка с алиэкспресс не быстрая, месяц-два, как и все посылки из Китая.
2. Краны есть всякие нужно только поискать, вот например:
http://www.aliexpress.com/wholesale?Sea ... 1220021036
3. Датчики давления, да, на 4 атм. но у меня выше и не бывает. Если поискать, то есть всякие, смотря какие нужны.
4. На счетчиках написано: "ВСГд-15" (горячая вода) и "ВСХд-15" (холодная вода) внешне выглядят вот так:
http://www.tehnopostavka.ru/kipia/index ... ductID=118
http://www.tehnopostavka.ru/kipia/index ... ductID=119
те которые со стёклышком.
То Всем остальным:
Вопрос уже в том что становится жалко IP адресов. Приходится все управление переводить в другую подсеть, а это немножко уже не удобно.
Ответ на будующий вопрос:
Нет мегадевайсов не такая куча в сети. в сети есть еще IP камеры, телевизоры, андроид планшеты и все прочее что ломится в сеть.
Re: Предложения по развитию проекта MegaD
оффтопик.
dimik2000 - в дом. условиях С-сегмента не хватает? с трудом верится.
dimik2000 - в дом. условиях С-сегмента не хватает? с трудом верится.
-
- Сообщения: 395
- Зарегистрирован: 17 фев 2013, 23:49
- Откуда: Волгодонск, Ростовская обл.
- Контактная информация:
Re: Предложения по развитию проекта MegaD
Похоже планируется более 255 устройств.
Re: Предложения по развитию проекта MegaD
Другая маска подсети и проблемы нет.
Re: Предложения по развитию проекта MegaD
Всем спасибо за ответы и извинения за флуд.
-
- Сообщения: 77
- Зарегистрирован: 22 ноя 2013, 03:17
Re: Предложения по развитию проекта MegaD
Мне не терпится подключить дополнительный функционал в MegaD: датчики давления bmp085 (их можно использовать в вентиляции и для определения атмосферного давления), датчики температуры, средние значения ADC (писал в соседней теме) и тд.
Что хочу предложить:
1. Можно сделать возможность выбора при компиляции, какие модули нужны. При этом все модули могут не влезать в мегу, но всегда можно будет выбрать наиболее нужные. К примеру - не нужен мне dhtХХ - выпиливаю его поддержку, но нужен bmp085 - добавляю ее. Делается довольно легко define'ами.
2. В рамках п.1. сделать web - интерфейс - опцией. Наверное, единственное, что нужно в реальности менять из веб-морды - ip адрес. Для всего остального можно написать небольшой php модуль, который опросит МегаD и выдаст всю инфу о ней - какие выводы как сконфигурены и тд. И из этого модуля можно будет переконфигурить megaD. Это, как мне кажется, даст существенный плюс: экономию памяти на буфере (не надо отдавать большие html), ну и экономию флеша под тексты. Я понимаю, что надо будет добавить код, выдающий в http коротко конфигурацию всех портов, но это вроде несложно, я исходники изучил.
Т.е. для чайников нужно иметь умолчальную прошивку, аналогичную текущей. А для не-чайников, которые могут запустить у себя простейший php, скомпилить новую прошивку, будет возможность получить новый функционал.
Что хочу предложить:
1. Можно сделать возможность выбора при компиляции, какие модули нужны. При этом все модули могут не влезать в мегу, но всегда можно будет выбрать наиболее нужные. К примеру - не нужен мне dhtХХ - выпиливаю его поддержку, но нужен bmp085 - добавляю ее. Делается довольно легко define'ами.
2. В рамках п.1. сделать web - интерфейс - опцией. Наверное, единственное, что нужно в реальности менять из веб-морды - ip адрес. Для всего остального можно написать небольшой php модуль, который опросит МегаD и выдаст всю инфу о ней - какие выводы как сконфигурены и тд. И из этого модуля можно будет переконфигурить megaD. Это, как мне кажется, даст существенный плюс: экономию памяти на буфере (не надо отдавать большие html), ну и экономию флеша под тексты. Я понимаю, что надо будет добавить код, выдающий в http коротко конфигурацию всех портов, но это вроде несложно, я исходники изучил.
Т.е. для чайников нужно иметь умолчальную прошивку, аналогичную текущей. А для не-чайников, которые могут запустить у себя простейший php, скомпилить новую прошивку, будет возможность получить новый функционал.
-
- Сообщения: 184
- Зарегистрирован: 07 ноя 2011, 08:45
- Откуда: Ступино МО
Re: Предложения по развитию проекта MegaD
Немножко похоливарю...
При всём уважении к тем, кто хочет диммер или кучу значений на ножку (1 раз - свет, два раза - весь свет, три - выключить всё)
Прошу - не забывайте, что в контроллере копеечная память и ограниченная частота и то, что сам МегаДевайс задумывался изначально "простыми мускулами" умного дома... Я тоже не прочь от диммера, но есть шим, а есть шим - есть диммер, хоть на 12В, хоть с доп. детальками на 220В (PIC10F200 + BT137 = диммер с 5-ти рублёвую монету).
Многозадачность решается количеством простых деталей... регистр + 2 Меги = 14 * 2 / кол-во выходов ригистра... Чем не многозадачность? =)
Если просить подарок к Новому Году, хоть и с опазданием, то надо просить оптимизацию всего того, что сейчас есть.
За пол-года Мега выросла до пятой версии, появились счетчики, появились порты (относительно 3 версии), работает пошустрее...
Но не настолько быстро, как могла.
Я солидарен с Sergey Borovkov
Пора делать веточку как на гитхабе )))
standard - то, что сейчас,
dev- модульная.
Из предложений - перебрать всю web часть... Кидаться только заголовками. Или реализовать простейшее REST приложение... GET POST
Добавить поддержку UDP (Андрей, не читайте. )
Всё освободившееся место от форм и "бешенного" парсинга url в буфер!..
На данный момента буфер под завязку, а столько еще всего хочется ))))
Почему я очень прошу буфер, UDP, частоту ?
1) по TCP скорость получения состояния порта 127-140 в секунду (это на 3.03 версии, извините, обновиться физически не могу) - медленно
2) буфер - это большее количество значений ADC и других состояний. Сейчас ~100 значений в секунду... (Мега может давать 1000 на 16MHz, без хлопот) - это приемлемая запись звука, это красивые графики в реальном времени, это... да это очень много интересного, где нужно измерять аналоговый сигнал.
3) UDP - на сервер вешаем любого демона на одном из (много-много) портов и слушаем мегу... Пусть мега ддосит сервер отправляя UDP пакетики (приблизительно по 4 или 8 кб в секунду - да простят меня математики, если я ошибся), а не на оборот
(на Линухе хоть в файл перенаправляем и обрабатываем аж javascript'ом, хоть сокет, хоть в dev устройство при определённых мучениях ))) echo "11:2" >> /dev/mega ...)
4) Половину функционала благодаря смене протокола вырастет в разы. Счётчики будут считать не до 255, (если с сохранением, то 255*255, сохраняя циклы... + значение) - буфер-то позволит. Короче - UDP это 100% обратная связь от железки.
5) WEB часть - в двух словах... header("CMD pass,11,1,25,12341....); парсить легче, чем _http://ip/pass/?cmd=...&pt=....&ip=..... Только "CMD pass" и цифры с ",". Такой парсинг перейдёт к switch - case. и уменьшит существующую простыню на >500 строк до 50... - а это level_up(buffer)
P.S. Скоро Новый год. С наступающим, форумчане!
При всём уважении к тем, кто хочет диммер или кучу значений на ножку (1 раз - свет, два раза - весь свет, три - выключить всё)
Прошу - не забывайте, что в контроллере копеечная память и ограниченная частота и то, что сам МегаДевайс задумывался изначально "простыми мускулами" умного дома... Я тоже не прочь от диммера, но есть шим, а есть шим - есть диммер, хоть на 12В, хоть с доп. детальками на 220В (PIC10F200 + BT137 = диммер с 5-ти рублёвую монету).
Многозадачность решается количеством простых деталей... регистр + 2 Меги = 14 * 2 / кол-во выходов ригистра... Чем не многозадачность? =)
Если просить подарок к Новому Году, хоть и с опазданием, то надо просить оптимизацию всего того, что сейчас есть.
За пол-года Мега выросла до пятой версии, появились счетчики, появились порты (относительно 3 версии), работает пошустрее...
Но не настолько быстро, как могла.
Я солидарен с Sergey Borovkov
Пора делать веточку как на гитхабе )))
standard - то, что сейчас,
dev- модульная.
Из предложений - перебрать всю web часть... Кидаться только заголовками. Или реализовать простейшее REST приложение... GET POST
Добавить поддержку UDP (Андрей, не читайте. )
Всё освободившееся место от форм и "бешенного" парсинга url в буфер!..
На данный момента буфер под завязку, а столько еще всего хочется ))))
Почему я очень прошу буфер, UDP, частоту ?
1) по TCP скорость получения состояния порта 127-140 в секунду (это на 3.03 версии, извините, обновиться физически не могу) - медленно
2) буфер - это большее количество значений ADC и других состояний. Сейчас ~100 значений в секунду... (Мега может давать 1000 на 16MHz, без хлопот) - это приемлемая запись звука, это красивые графики в реальном времени, это... да это очень много интересного, где нужно измерять аналоговый сигнал.
3) UDP - на сервер вешаем любого демона на одном из (много-много) портов и слушаем мегу... Пусть мега ддосит сервер отправляя UDP пакетики (приблизительно по 4 или 8 кб в секунду - да простят меня математики, если я ошибся), а не на оборот
(на Линухе хоть в файл перенаправляем и обрабатываем аж javascript'ом, хоть сокет, хоть в dev устройство при определённых мучениях ))) echo "11:2" >> /dev/mega ...)
4) Половину функционала благодаря смене протокола вырастет в разы. Счётчики будут считать не до 255, (если с сохранением, то 255*255, сохраняя циклы... + значение) - буфер-то позволит. Короче - UDP это 100% обратная связь от железки.
5) WEB часть - в двух словах... header("CMD pass,11,1,25,12341....); парсить легче, чем _http://ip/pass/?cmd=...&pt=....&ip=..... Только "CMD pass" и цифры с ",". Такой парсинг перейдёт к switch - case. и уменьшит существующую простыню на >500 строк до 50... - а это level_up(buffer)
P.S. Скоро Новый год. С наступающим, форумчане!
Лень — двигатель прогресса...
-
- Сообщения: 184
- Зарегистрирован: 07 ноя 2011, 08:45
- Откуда: Ступино МО
Re: Недостатки MEGAD
Чуть-чуть математики...Virtus-pro писал(а):....
т.е сама мега серверу будет отдавать в таком видеИ почему кстати XML на последнее место? В php даже класс есть встроенный чтобы работать с xml, причем очень удобно.Код: Выделить всё
...M6ImFhMyI7czoyOiJpcCI7czoxNDoiMTczLjE5OS44Ny4xMjYiO3M6NjoiY19wb3J0IjtzOjQ6Ijg3NzciO3M6NjoicV9wb3J0IjtzOjU6IjI3MDIwIjtzOjY6I
Ну в общем это только мое предложение
Попробуйте на php написать парсер для строки url и генератор ответа. Без использования функций, кроме, count, strlen, substr и других примитивных и разумеется конструкций. Если вы напишите . У вас будет простыня из кучи if else, case, break. Да - работать будет. Но после этого первой строкой ini_set('memory_limit 'очень-очень мало килобайт');
и попробуйте запустить =)
Это реально запихнуть в чистую мегу, но в мегу, на которой в 32кб памяти:
веб сервер, парсер url, генератор форм, куча проверок на содержание url, проверки портов, генератор ответов серверу, 2 режима работы и куча остального....
Лень — двигатель прогресса...
-
- Сообщения: 77
- Зарегистрирован: 22 ноя 2013, 03:17
Re: Предложения по развитию проекта MegaD
Зачем быстрее? Я правда не понимаю. Писать звук при помощи MegaD - нецелевое использование устройства. Для передачи звука или видео есть более подходящие девайсы.ArtSamovar писал(а):Немножко похоливарю...
Всё освободившееся место от форм и "бешенного" парсинга url в буфер!..
На данный момента буфер под завязку, а столько еще всего хочется ))))
Почему я очень прошу буфер, UDP, частоту ?
1) по TCP скорость получения состояния порта 127-140 в секунду (это на 3.03 версии, извините, обновиться физически не могу) - медленно
Т.е. пожалуйста, если делать абстрактную модель, в которой http сервер будет абстрактным с несколькими методами получения и отправки запросов/ответов, то наверное можно будет сделать отсылку значений не через http и даже через UDP. С меня максимум - уровень абстракции http сервера, когда придет шилд w5100.
-
- Сообщения: 184
- Зарегистрирован: 07 ноя 2011, 08:45
- Откуда: Ступино МО
Re: Предложения по развитию проекта MegaD
Если вы почитаете ветку о голосовом управлении, то Вы поймете, что скажем так, довольно не дёшево и проблематично запихнуть более 3-4 микрофонов в один компьютер...Sergey Borovkov писал(а): Зачем быстрее? Я правда не понимаю. Писать звук при помощи MegaD - нецелевое использование устройства. Для передачи звука или видео есть более подходящие девайсы.
Давайте отойдём от микрофонов.
Буквально на втором мониторе у меня открыт редактор, в нем 3.12beta1
Как отдаются ответы? Просто читаем порт и отдаём... Всё. Чем это не хорошо?
Попробуйте получить все значения портов. Цикл с сервера по каждому порту. Логично, просто, безболезненно...
Пока всё хорошо.
А теперь плохо.
Берем 5-6 серверов. (Допустим у нас большой дом, там медиа сервер, резервный, основной... ну любим железки) =)))
И тут по разным причинам они просят у одной меги значения всех портов...
Пакетики падают в очередь, и ответ Меги вырастает ровно на количество запрашиваемых серверов.... То есть в пять раз. (GSM - модем не берем в рачёт, это ещё дольше)...
Постараюсь на 2 вопроса ответить... почему её надо разгонять и желательно (хотя не обязательно) использовать UDP
Вернусь к исходнику...
Там есть
ISR(TIMER1_COMPA_vect) - и это таймер. что он делает?
что то считает, каждые N тактов (точно сколько не помню) и эта мощь используется только на ожидание ответа от сервера (Если я не прав, не бейте)
Это то место, где на 3 версии прошивки, при заданном ip сервере, при выключенном онном, свет с кнопки включался как раз с задержкой этого таймера... В соседней ветке (не читал), но уверен, что обсуждали эту задержку...
Вариант оптимизаии и исполнение желания на команду get_all =)
в этом таймере собираем все порты, пакуем в 1 пакетик и ОДИН пакетик, отправляем. Поверьте, по сравнению с for(0...14) get port i, это вернёт все значения быстрее, к тому же задержка на обработку 5 запросов будет раза в три, в четыре меньше, благодаря этому таймеру и бОльшему буферу
Так вот, снова о пакетиках. TCP состоит их кучи заголовков, общается просто - отправил запрос, получил, отправил данные, получил ответ...
Если отправляется ОДНО значение порта (цифра от 0...1024) , то 60% ответа на TCP занимают заголовки... Ненужные данные...
UDP - заголовки (что, куда, checksum) + data... и работает так: Взяли порт, взяли адрес и отправили наши данные... что с ними, пришли, не пришли - UDP не волнует...
Разницу чувствуете? ТО есть самой Меге будет легче формировать сетевые пакеты, вырастет время отклика...
А ещё лучше возьмем датчик движения, реагирующий на тепло (тоже аналог) и представим ситуацию...
дома кот, балкон, автоматически открывается/закрывается окно . Задача проветрить помещение, пока вас нет дома и не дать любопытному кошаку вылезти на окно (понимаю, что не упадёт, но жена, например паникует) Задача? Да...
Прибавим второго кота и отправим их бегать по квартире.
Берем несколько датчиков по углам...
Решение: если кот на балконе -> закрыть окно, иначе открыть.
Перемещение кота до меги, как в 24 кадров в секунду, после уже кадров 8-10...
Мега в 30% не среагирует на закрытие окна. Кот пулей пробежит, оставив два - три значения на сервере...
Примеров можно придумать куча, и ещё более реальных.
Вернусь к микрофонам.
Охранная система, как вам?
Голосовое управление?
Голосовые заметки?
Датчики шума? (ребенок ночью проснулся, чем ни уоки-токи)
Всякие хлопушки на свет из любого места где есть микрофон (без нормальной скорости, хлопки = любому похожему звуку, при нормальной - они определяются прекрасно)
Ещё примеры?...
UDP в роутере можно перенаправить на TCP
UDP - это поток данных... Примеры приводил выше.
Не надо менять на UDP полностью, его спокойно можно запрашивать с флагом в заголовке на разрешение буферизации порта.... (или портов) и тогда мега до какого то действия будет отправлять данные...
В общем, всё как работало - так и будет, работать, только быстрее =)
Лень — двигатель прогресса...
Re: Предложения по развитию проекта MegaD
REST-> https://github.com/jjg/RESTduinoArtSamovar писал(а):Немножко похоливарю...
Из предложений - перебрать всю web часть... Кидаться только заголовками. Или реализовать простейшее REST приложение... GET POST
Добавить поддержку UDP (Андрей, не читайте. )
https://github.com/thiseldo/EtherShield_RESTduino
стеки с UDP (правда с ограничениями. бродкаст только в 255.255.255.255)ArtSamovar писал(а): 3) UDP - на сервер вешаем любого демона на одном из (много-много) портов и слушаем мегу... Пусть мега ддосит сервер отправляя UDP пакетики (приблизительно по 4 или 8 кб в секунду - да простят меня математики, если я ошибся), а не на оборот
(на Линухе хоть в файл перенаправляем и обрабатываем аж javascript'ом, хоть сокет, хоть в dev устройство при определённых мучениях ))) echo "11:2" >> /dev/mega ...)
https://github.com/jcw/ethercard
https://github.com/ntruchsess/arduino_uip
у последнего стека полное АПИ от официального шилда на w5100.... правда от этого он стал несколько жирнее.
-
- Сообщения: 184
- Зарегистрирован: 07 ноя 2011, 08:45
- Откуда: Ступино МО
Re: Предложения по развитию проекта MegaD
Поизучаю, спасибо...
Уже спать пора, голова еле думает.
//ip_arp_udp_tcp.c.{h.c}
В нашей Меге максимальные пакетики по 220 байт UDP
и два варианта, либо в ручную заполнять и отправлять, либо выделить буфер и просто отдавать его (хоть наполовину заполненным)
Время считал исходя из этих 220. таймер 10ms (в beta 5ms) 10 (220) * 10 = 2,2 + если поднять частоту, то с натягом примерно 3 кб. (но если по 5ms, то 5(220) * 2 *10 = 4,4 + частота с 12,2 до 16. до 5 кб в секуду.) хотя и 4 хватит с головой, 4000 значений в секунду отправит. с 8 погорячился...
А если отойти от REST и прийти только к заголовкам, как вам?
установка скрипта header("CMD 1,192,168,0,101,path,to,dir,script,php");
некое дерево.
имя -> тип -> порт -> value1 -> value2.....
что будет в меге - представляю, ей парсить по запятой, а дальше тривиальная логика с работой по портам... Генератор форм просто уже будет не нужен - а это только по символам около 2 кб места для буфера
и
header("HTTP/1.0 304 1,192,168,0,101,path,to,dir,script,php"); // ответ сервера, если мы переместили наш скрипт в другое место
мега при этом заголовке пере-конфигурируется сама...
(примеры заголовков тривиальны, не описывают стандарты, но явного запрета в прошивке на них пока не видел)
header("HTTP/1.0 101"); //смена протокола...
от меги header("HTTP/1.0 201"); смена настроек
от меги header("HTTP/1.0 204"); порт выключен
от меги header("HTTP/1.0 205"); сброс счетчиков
и тому подобное...
Такие ответы парсить куда легче на сервере, чем разбирать html регулярками...
Управление ajax'ом... всего одним спец. заголовком, которй мега будет понимать...
Трафик почти в ноль, парсинг команд с обеих сторон проще, да много чего классного...
Заговорился... =) Извнините...
За ссылки спасибо. Завтра и почитаю.
Лень — двигатель прогресса...
Re: Предложения по развитию проекта MegaD
из таймера делают SysTick , по UDP,экомия памяти получится внушительнаяISR(TIMER1_COMPA_vect)
-
- Сообщения: 77
- Зарегистрирован: 22 ноя 2013, 03:17
Re: Предложения по развитию проекта MegaD
По поводу передачи звука - это спокойно пропихивается через tcp, если допустить, что задержка может быть 0.1 секунды. И слать блоками по 200-300 байт. Вешаешься на прерывание ADC и вперед.
Функционал получения за один запрос данных всех ног - надо сделать. Для этого надо в любой момент иметь данные по всем ногам, и все. Т.е. данные по ADC получать в прерывании и сохранять его.
Я бы еще добавил запрос, получить сразу полную конфигурацию устройства.
Функционал получения за один запрос данных всех ног - надо сделать. Для этого надо в любой момент иметь данные по всем ногам, и все. Т.е. данные по ADC получать в прерывании и сохранять его.
Я бы еще добавил запрос, получить сразу полную конфигурацию устройства.
Re: Предложения по развитию проекта MegaD
Добрый день попробывал udp реализацию данного девайса поубирал все формы поуменьшал буфера , вывод следующий за щет удаления форм освободилась много памяти программ , значительно меньше оперативной памяти (особенно если учесть что ее там всего ничего),большого прироста быстродействия не заметил,зато удобства работы значительно поубавилось, вообщем я думаю что не надо выдумывать ничего нового а просто заняться оптимизацией существующего.
-
- Сообщения: 184
- Зарегистрирован: 07 ноя 2011, 08:45
- Откуда: Ступино МО
Re: Предложения по развитию проекта MegaD
/* А если заполнять его в таймере? (или только ацп, или все порты в него и отдать строкой) */alexsis_76 писал(а):...значительно меньше оперативной памяти...
Код: Выделить всё
if ( adc_check_flag == 1 )
{
if ( adc_timer > 1000 )
{
for ( i = 0; i < IO_SIZE; i++ )
{
....
if (_port_type[i] == 2 || port_letter == 'A' )
{
if ( _port_misc[i] < 1024 && _port_m[i] != 0 )
{
...
...
port_misc_cur[i] = my_val;
}
}
}
adc_timer = 0;
}
}
Лень — двигатель прогресса...
Re: Предложения по развитию проекта MegaD
Очень интересное решение,достаточно трудоемкое,но мне кажется в будущем это может окупится! Ну и конечно же при таком пути надо использовать систему контроля версий.1. Можно сделать возможность выбора при компиляции, какие модули нужны. При этом все модули могут не влезать в мегу, но всегда можно будет выбрать наиболее нужные. К примеру - не нужен мне dhtХХ - выпиливаю его поддержку, но нужен bmp085 - добавляю ее. Делается довольно легко define'ами.
Re: Предложения по развитию проекта MegaD
Очень понравился мегадевайс. И возникло такое предложение: пожертвовать двумя пинами и добавить поддержку USART, дав ыозможность серверу отправить туда команду(несколько байт) и получить ответ. Это даст посредством мелкого контроллера (и простой програмки в него) реализовать подключение датчиков (1Wire, IIC , DHT) , LCD , расширение портов , диммер, либо свои собственные задумки . А если еще дать возможность мегадевайсу самому отдавать или принимать команды в/из USART то я с трудом уже представляю, что из этого можно наворотить. Кроме того легко можно сделать гальваническую развязку, прикрутить 485 интерфейс и навешать несколько таких доп.контроллеров на одну шину.