Идея открытой платформы "Умный дом"

Доброго всем времени суток.
Хочу поделиться с Вами своей маленькой идеей.
Несколько лет назад заинтересовался я Умным домом. Но так складывалось что до реализации чего-то такого что «не стыдно и людям показать» в этом направлении все руки не доходили. И вот сейчас когда после разработок железа на AVR я осваиваю программирование на .Net. Все что я видел для «Умного дома» стоит огромных денег и с применением дорогих ПЛК. А решаемые вопросы реализуем и на более простом железе (имхо плата аналогичная Arduino, может решать порядка 70 — 80% возникающих задач — освещение, водоснабжение, вентиляция).
Теперь чего хочу реализовать.
В основном задачи которые необходимо решать для «Умного дома» не требуют высокой производительности и real-time отклика. Поэтому моя идея реализовать виртуальную машину на С++ для микроконтроллеров (AVR, STM8, STM32 — тяжелая артиллерия)с одинаковым набором команд и приложение для программирования, отладки и тестирования этой платформы на .Net. Коммуникация с PC через RS-232/USB. В будущем для этого всего можно реализовать более высокоуровневый язык который можно компилировать в виртуальный ассемблер.
Со своей стороны хочу написать программу на .Net для написания/программирования/отладки на виртуальном ассемблере. Что хочу получить на выходе — открытая платформа с минимальной себестоимостью повторения и с практически нулевым входом использования(программирования).
Здесь в сообществе хочу найти тех кому интересно принять участие в разработке данной платформы со стороны разработчика аппаратной части.
Те платформы что существуют (которые я находил) на данный момент не поддерживают отладки без специального оборудования.
В комментариях жду вашу критику по поводу идеи и пожелания принять участие в разработке.
Прошу не устраивать холивар на тему С/С++ эта тема не о том.
Если будут вопросы то мои контакты есть в профиле.

UPD

В ходе беседы в комментариях выделились некоторые конечные цели:
  1. Умный дом должен управлять мультимедиа и для этого нужен обязательно малогабаритный компьютер.
    Считаю что полная зависимость от компьютера (ПК) категорически запрещена. Потому что на любом стоит ОС. И при зависании или торможении ПК будет тормозить или вообще не работать Умный дом. Или же нужно для таких целей нужно применять операционные системы реального времени, когда заранее известно в течении какого времени будет обработан ЛЮБОЙ запрос.
  2. Для управления исполнительными устройствами и опроса датчиков необходим отдельный блок.
    Вот такой отдельный блок и предлагаю разработать со средой разработки/управления и встроенными средствами для обмена данными с ПК.
  3. Обмен данными между блоками должен быть как проводным так и беспроводным.
    Считаю что «беспроводность» должна быть доп опцией а не встроенным функционалом. И еще беспроводной обмен заставляет применять шифрованный обмен данными (затраты производительности). А то сосед отключит нечаянно/намеренно воду или электричество. Да и безвредность 2,4 ГГц для организма не доказана.

Теперь по поводу производительности виртуальной машины (ВМ). Есть соображения как оценить минимально-возможный предел падения скорости обработки команд в сравнении с тактовой частотой микроконтроллера.
Плюсы ВМ:
  • Не зависимость от конкретной платы (AVR, PIC, STM и др.)
  • Возможность отладки программы в железе через USB/Com порт
  • Использование в разработке различных методов тестов кода
Минусы ВМ:
  • Снижение производительности
И в связи с этим может быть сегмент 8-ми битных контроллеров будет неприменим.
С другой стороны некоторые модели STM32 всего лишь на 20% (или 1 — 2$) дороже обычных Mega, при этом имея встроенный USB. Цены смотрел на КОМПЭЛ.

UPD 2

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

Резюме

Огромное спасибо Всем кто оставил свое мнение по поводу платформы «Умный дом».
По количеству комментариев вижу что тема интересна не только мне.
Далее предлагаю перенести обсуждение всех вопросов по направлениям на платформу управления проектами.
Что позволит разделить вопросы разработки и параллельно двинуться к поставленной цели.
Приглашаются все желающие по адресу: iqhouse.teamlab.com
Для получения инвайта мне нужно Ваше имя и почта.
Результаты и итоги в вехах разработки будем оформлять здесь.

Теперь по поводу самой платформы.
По обсуждению первое приближение это следующая структура.
Структура платформы "Умный дом"
Помню что были идеи децентрализованной сети но это вопрос который требует отдельного обсуждения.
Пока не определена цель и путь как программировать/конфигурировать/параметризировать платформу. И это тоже требует отдельного обсуждения.
Всем огромное спасибо!
  • 0
  • 22 августа 2011, 23:16
  • Pencroff

Комментарии (153)

RSS свернуть / развернуть
могу помочь только альфа и бета тестами
0
Поясните что значит альфа-бета тесты.
0
ну т.е. помогу потестировать ваш компилятор и открытую платформу на железе (AVR и STM32)
0
По поводу тестирования работы не подумал — спасибо за подсказку. Это обязательный этап после основного кодинга. Учтем.
0
Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

* Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

* Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
0
По данной класификации думаю что нужно альфа тестирование — малый круг разработчиков. Бета — все кому интересно и анализ обратной связи и отзывов.
0
хороша идея, помогу чем смогу. Я тоже начал делать умный дом, с расчетом на максимальную гибкость и универсальность основного блока. Это к слову об ардуино-подобии. Если интересно, почитайте мой пост в тематическом блоге.
0
  • avatar
  • enq
  • 23 августа 2011, 00:08
Умный дом в понимании потребителя — это (IMHO) не только управление воротами гаража, включение полива газона, управление отоплением и освещением лужайки, но еще и управление мультимедиа ресурсами и иными задачами, требующими совсем не тривиальной производительности, и самое главное — это максимальное количество свистелок и перделок на пульте управления с интеграцией интернетов, твиттеров и фейсбуков. Посмотрите самые простые платформы, сертифицированные для установки, первое что там ставится во главу угла — это безопасность в использовании.
0
а управление мультимедиа — это включение-отключение телевизора? =D Все таки сводится к управлению этими 5 вышеперечисленными вещами. А интеграция интернетов нужна далеко не везде. А помимо интернетов, больше ни для чего офигенская производительность (свыше 20МГц) ИМХО не требуется.
0
Можно пример платформы? Я бы своему умному дому не разрешил выходить в интернеты. А то мало ли какой нибудь подросток-хакер заблокирует все системы. И будет как в анекдоте:
Петька прочитал объявление, что меняется 3-комнатная
благоустроенная квартира на любую жилплощадь. А у них с Анкой — коммуналка. Пришел по адресу, открывает Василий Иванович:
— Здорово, Петька, проходи, смотри.
Он осмотрел квартиру, она шикарная! Вдруг Петька захотел в
туалет, подошел к двери, дергает, а она не открывается.
Василий Иванович говорит:
— Петька, да ты свет-то включи, тогда и дверь сама откроется.
Петька зашел в туалет, сделал свои дела, дверь захлопнулась и не
открывается. Он стучался, стучался, а Василий Иванович ему
кричит:
— Петька, ты забыл за собой смыть.
Он смыл, дверь и открылась.
— Василий Иванович, ты что это такую отличную квартиру меняешь?
— Да ты знаешь ведь, Петька, как у нас бывает, то воды нет, то
света...
Да и целью этой системы не есть управление мультимедиа (на данный момент). Для этого есть компьютеры — нынче они ой какие миниатюрные
0
Ну намного проще будет работать и реализовывать многие фичи, когда есть хотя бы тот же FrendlyARM­
И привинтить запрос погоды с гисметио для управления шторами и форточкой, с вебморды или ssh ­спросить слился фильм или нет, и смской сказать что в доме происходит, и с видеопотоками работать­, сообщить что этой ночью будет минус 10, и если дома никого нет закрыть балкон, или через вебморду или той же смс сказать что делать. Да и устойчивость всей системы в целом будет меньше зависеть от отдельных компонентов. А вот лепить вышеописанное на сети из тини и одной\двумя\подставить требуемое число и название/ меге, при этом запиливая полсотни своих протоколов и прочих костылей будет только ярый фанат =)
Вобщем доводов много можно привести, все зависит в первую очередь для чего ты клепаешь умный дом, для лампочки в коридоре и душкой от телевизора, или же нормальную автоматизированную систему, которая осилит звякнуть пожарным в случае пожара или в доблестную полицию/соседу/охрану если в вебкамере появится неопознанное тело с монтажкой и сумкой из икеи.
своему умному дому не разрешил выходить в интернеты
Боишся, чо он накачает прона и будет смотреть без тебя?)))
А то мало ли какой нибудь подросток-хакер заблокирует все системы
Так не стоит делать дуршлаг с большой красной кнопкой посередине
0
По моему мы с Вами сейчас говорим о абсолютно разных уровнях в этих самых системах автоматизации.
Давайте возьмем классическую систему промышленной автоматизации (поправьте меня если есть не точности):
I Уровень датчиков и исполнительных устройств
II Уровень контроллеров, реле времени, ПИД-регуляторов, таймеров и множество других управляющих устройств
III Уровень SCADA система общего управления управляющими устройствами и отображения их состояния.
Вы никогда не будите подключать напрямую датчик температуры к SCADA системе. Потому что если есть необходимость просто измерить температуру то для этого не нужна SCADA.
А теперь давайте вернемся к нашим баранам.
Выше я уже говорил что идея системы в ее доступности и низкой себестоимости (хочу зарабатывать не на продаже платформы а на стоимости своих работ внедрения и сопровождения). Если следовать вашей логике то даже для простого управления теплым полом и вентиляцией то обязательно сразу ARM плату за 100$ — 200$ что бы она сама всем рулила.
Но если мы разнесем это на разные уровни и построим сеть из 2-3-5 плат на Мега и при необходимости добавим домашний сервер с WiFi/Синим зубом/Интернетом и другими плюшками который сможет контролировать работу нашей сети на Mega то получим гибкую систему как по функционалу так и по стоимости.
осилит звякнуть… в доблестную полицию/соседу/охрану если в вебкамере появится неопознанное тело с монтажкой и сумкой из икеи
— это задача только для полноценного компьютера с распознаванием образов никакие Mega этого НИКОГДА не осилят.
И теперь по поводу уязвимости компьютеров — если есть выход в интернет, то соответственно существует вероятность взлома системы, допустим даже не для какого либо удаленного управления чужим домом а просто формирования сети ботов что бы генерировать BitCoins. И если Ваш компьютер повиснет то остановиться ВЕСЬ дом. Если же эти уровни разделены то дом продолжает работать в своем нормальном режиме даже без компьютера.
при этом запиливая полсотни своих протоколов и прочих костылей
Зачем же запиливать свои протоколы и костыли — реализуем промышленно устоявшиеся ModBus, 0-10V, 4-20mA.
В предложенной мной подходе в топике ModBus реализуем на уровне виртуальной машины а передача данных на уровне виртуального ассемблера. Но это все следующие шаги. Первый шаг это простая плата с виртуальной машиной которая может управлять портами ввода-вывода и осуществлять простые арифметические операции а так же просто программироваться и отлаживаться без Спец оборудования: плата — шнурок — компьютер.
0
А по моему все было проще!
0
Зачем же запиливать свои протоколы и костыли — реализуем промышленно устоявшиеся ModBus, 0-10V, 4-20mA.
Свои протоколы все равно нужно будет пилить. Дело в том, что тут вы говорите о протоколах разных уровней: канальных и транспортного (см. Модель OSI).

Мне кажется с канальным уровнем проблем не будет, выберем. А вот хорошо реализовать верхние уровни это довольно сложная и заслуживающая внимания задача.
0
Modbus Application Protocol — протокол прикладного уровня, Modbus Serial Line Protocol — протокол канального уровня.
0
Да да, так оно и есть — поддерживаю, а из готовых протоколов для конечных устройств есть еще DCON от ICP-DAS, он проще modbus, и есть у них готовые модули с 485 интерфейсом к которым можно подключать датчики и испольнительные ус-ва, кстати, готовые датчики с выходами 0-10в и 4-20мА относительно дороги и оправданны на промышленных объектах с проводами по 50м, дома проще подключать простые аналоговые датчики напрямую к модулю аналогового ввода.

А вообще норально поставить Linux-машину, не медиа-центр а именно рулилку оконечными девайсами (хоть по CAN, хоть по RS485) и с modbus до машины собственной со скада — вот код под Linux действительно легко переносим и широк в возможностях, и веб-морду пришить проще.

Но как мне сказал один знакомый архитектор — умный дом это в первую очередь центральный пылесос :)
0
mio-ra — прав.
Я занимался анализом рынка «Умных Домов». Сейчас в понятие Умный Дом потребитель услуги больше вкладывает понятия управления медиаконтентом.
Hi-end — это беспроводные сенсорные панели, по аналогии с iPad, с своим красивым интерфейсом.
Mid-lvl — Это встроенные сенсорные панели.
и самые бюджетные решения — это управления функциями через SMS, web-интерфейс, кнопочные панели (выключатель) и т.д.
Функционал так же зависит сегмента. Если в бюджетных вариантах и правда нужно только открыть-закрывать, информировать о данных с датчиков и вкл-выкл бытовую технику, то уже начиная с среднего сегмента появляются задачи управлением мультимедией ака «Мультирум». Тут возникают проблемы в дорогостоящем оборудование для построения инфраструктуры помещения с возможностью мультизонального управления HDTV-контентом.

Что же касается бюджетного оборудования, то для примера есть GSM контроллер «GSM контроллер CCU6225-H1-M1» — который имеет демократичную цену и подходит для построения функционала «Умного Дома» как на даче, там и в квартире. ИМХО, он больше подходит для дач т.ч. это больше охранный контроллер.

Для дома есть более дорогой вариант, опять же от русских товарищей, фирмы Insyte, но имеющий расширенный функционал, поддержка 1-ware и ZigBee и более-менее стандартный набор остальных функций. Первая версия контроллера работала на ModBus — о котором появилось ряд статей . Вторую версию пока не удалось помусолить в руках.

Бывают еще зарубежные не дорогие варианты, но это если интересно уже будет, спрашивайте. Рынок считаю интересным и перспективным, но в РФ пока даже не зародившимся. Кол-во проектов квартир и загородных домов с системами «Умный Дом» минимально, в то время как на Западе их кол-во постоянно растёт.

Есть проект будет иметь конкретные цели, могу помочь, чем смогу.
0
Я занимался анализом рынка «Умных Домов». Сейчас в понятие Умный Дом потребитель услуги больше вкладывает понятия управления медиаконтентом.
Hi-end — это беспроводные сенсорные панели, по аналогии с iPad, с своим красивым интерфейсом.
Mid-lvl — Это встроенные сенсорные панели.
и самые бюджетные решения — это управления функциями через SMS, web-интерфейс, кнопочные панели (выключатель) и т.д.
Функционал так же зависит сегмента. Если в бюджетных вариантах и правда нужно только открыть-закрывать, информировать о данных с датчиков и вкл-выкл бытовую технику, то уже начиная с среднего сегмента появляются задачи управлением мультимедией ака «Мультирум». Тут возникают проблемы в дорогостоящем оборудование для построения инфраструктуры помещения с возможностью мультизонального управления HDTV-контентом.
Абсолютно с Вами согласен. Давайте посмотрим на это с другой стороны. Сколько стоит на текущий момент — LanDrive SPIDER2.
И проясните пожалуйста что значит
порт RS-232 для управления сетью ресиверов Мультирум
какой функционал позволяет реализовать данная опция? C помощью каких интерфейсов SPIDER2 взаимодействует с iPad/iPod/iPhone?
0
LanDrive SPIDER2 — должен стоить около 15к рублей с доставкой. ИМХО цена демократичная, особенно если посмотреть сколько функций имеет базовый блок. В других системах только GSM-gate стоит порядка 1к$.
порт RS-232 для управления сетью ресиверов Мультирум
Почти все ресиверы для Мультирумов имеют RS-232 вход и набор команд для управления им. Для этого и порт, чтобы сразу по RS-232 можно было подключить ресивер или любое другое устройство.
C помощью каких интерфейсов SPIDER2 взаимодействует с iPad/iPod/iPhone?
Честно, точно не помню. Там по Ethernet подключаем контроллер к Wi-fi роутеру вроде.
0
Хорошая идея… я сам давно хочу нечто подобное реализовать.
сейчас разрабатываю сигналку с GSM-модулем и DTMF-декодером, для управления нагрузками, снятием постановкой на охрану. такое подобие «умного дома».
есть и более глобальные идеи. Предлагаю сотрудничество в разработке
0
:) для управления можно взять любой Android-планшет с платкой Android IOIO, для управления организовать сеть Modbus, поднять локальный сервер для раздачи контента и управления по WiFi. Сейчас заканчиваю свои варианты IOIO и Modbus-узлов.
0
Я думаю, на основном блоке должна стоять солидная ось, что б заново велосипед не изобретать. Посмотрите в сторону Linux MCE linuxmce.org/
0
Кроме того умеет работать со всякими сенсорниками, смартфонами, КПК.
0
Кроме того умеет работать со всякими сенсорниками, смартфонами, КПК. wiki.linuxmce.ru/
0
Поэтому моя идея реализовать виртуальную машину

Чтобы окончательно добить те немногие вычислительные ресурсы, которые предоставляют МК? Извращение однозначно. Под МК надо писать только в нативном коде. Лучше напишите пристойный, точный и полный эмулятор планируемой платы со всей периферией, кушающий AVR-hex. Человечество будет Вам благодарно.

***

Как и многие, занимаюсь проектированием умного дома для себя любимого. Все, что говорилось по поводу мультимедиа — правда. Потому я остановился на следующей топологии: во главе будет стоять x86-комп (mini-ITX на атоме), который втыкается в домашнюю сеть и предоставляет WEB-интерфейс для управления. Параллельно он будет качать торренты, показывать видео и т.п. Сервер интерфейса будет общаться с программой, обслуживающей высокоуровневую логику, которая, в свою очередь, через COM будет слать команды специальной железяке, которая уже непосредственно будет управлять датчиками и исполнительными механизмами.
0
  • avatar
  • _YS_
  • 23 августа 2011, 13:08
во главе будет стоять x86-комп (mini-ITX на атоме), который втыкается в домашнюю сеть и предоставляет WEB-интерфейс для управления
Это, наверное, самый оптимальный вариант для того что бы не платить килобаксы ))) и реализовать все задумки.
0
Абсолютно согласен с Вами что виртуальная машина (ВМ) съест часть ресурсов у микроконтроллера. К сожалению не представляю как оценить процентное соотношение производительности. Но на уровень ВМ планируется вынести уровень логики, а операции по работе с оборудованием на уровне native кода. Тогда падение производительности не должно быть таким сильным.
Да и использование ВМ позволит одни и те же программы исполнять на разных микроконтроллерах: AVR, PIC, STM.
0
позволит одни и те же программы исполнять на разных микроконтроллерах: AVR, PIC, STM.

Правильно написанный на С код портируется достаточно легко. Особенно, если вынести в отдельный файл специфичные макросы и определения. Так что смысла извращаться с VM нет никакого.
0
Боюсь что не правильно все объяснил. ВМ нужна для разделения уровня логики управления от работы с аппаратурой и протоколами. Здесь я это указал
0
Дыг тогда это не VM, а, скорее, поддержка скриптов.
0
Не понимаю что значит поддержка скриптов.
Чем на Ваш взгляд скрипт отличается от байт кода?
0
Чем на Ваш взгляд скрипт отличается от байт кода?

Спектром возможностей и областью применения.

Байт-код VM эмулирует именно машину целиком, с по возможности полной абстракцией от реального оборудования. Скрипт же — что-то вроде продвинутой команды системе.
0
Скрипт — это встроенный язык программирования. VM — типичный метод его реализации, как наиболее оптимальный. Врядли разумно делать на МК полноценный интерпретатор скрипта в текстовом виде. Впрочем, интерпретатор скрипта тоже можно рассматривать как VM, только исполняющую непосредственно ЯВУ.
А VM и байткод могут быть произвольной степени абстракции. Скажем, инсталлятор NSIS — VM. Имеет команды типа «распаковать файл», «записать в реестр» и т.п. В принципе VM даже не обязана поддерживать скажем ветвления, хотя без них, конечно, смысла довольно мало.
Разница тут скорее в том, умеет ли система что-то делать кроме исполнения скриптов. Например, lua.exe — это среда исполнения языка программирования lua, а вот farcry.exe — это игра, некоторые аспекты которой реализуются скриптами на lua. Хотя и там и там одна и та же VM lua.
0
Если писать интерпретатор скриптов — то получим действительно медленную или даже очень медленную программу потому что она будет на микроконтроллере анализировать какие либо лексемы скрипта. Это слова английского — русского языка.
Байт код это уже закодированные одно — двух байтовые лексемы которые очень легко распарсиваются структурами Swich...case.
Не совсем понятно чем отличается полная или не полная абстракция от оборудования?
На мой взгляд должны обязательно быть следующие группы комманд:
1. Работа с ОЗУ.
2. Работа с встроенной периферией.
3. Арифметические операции
4. Логические операции.
5. Ветвление и переходы.
6. Битовые операции.
7. Расширения команд: для работы с сетью, для высокоуровневых расчетов (тот же ПИД для автоматизации).
0
Ты только не забывай, байткод не более читабелен чем машинный код. Так что и желаемого тобой плюса — воткнулся в контроллер, слил прошивку, поправил и залил обратно — он не даст. Так что тут куда проще и лучше подойдет фреймворк.
А слил-поправил-залил — это либо нечто, у чего исполняется непосредственно исходник (скриптик, ага — интерпретатор или компилятор+вм, ну или схематический язык — в файле хранятся блоки с параметрами и их взяимосвязи, исполнятор работает прямо по ним, редактор эти блоки и связи отрисовывает и позволяет редактировать), либо просто настраиваемый девайс.
0
В первом приближении: редактируем мнемоники (аля ассемблер), заливаем байт код с подставленными адресами вместо имен. Имена храним как метаданные. Слил — редактируем мнемоники. Если все заработает и будет устраивать производительности то можно на байт-код и компилятор добавить.
0
С тем же успехом можно залить в качестве метаинфы .map файл от нативного асссемблера. Да и писать на асмообразном языке никакого желания. Один раз я уже сделал генератор текстур с описанием на асмоподобном языке. В общем, это было плохой идеей) Работоспособно, но ОЧЕНЬ неудобно.
0
А в чем тогда профит, если язык будет асмоподобен? Породить еще одну архитектуру, более медленную и ущербную?
0
Кстати, при грамотном использовании макросов, осмысленных именах и адекватных комментариях и родной асм отлично читается.
0
Медленную — да.
Ущербную вряд ли. Асм никогда не сможет послать одной коммандой сообщение. Или скрыть от пользователя буферезированный обмен данными.
А доп. слой абстракции необходим для более гибкого конфигурирования контроллера и возможности редактировать программу под измененные нужды.
Пока что доводы за и против ВМ равносильны. И более точного определения чем МЕДЛЕННО и НЕУДОБНО против ВМ не было высказано. А язык ассемблера очень даже нормальный и понятный язык. Уважаемый DiHalt когда только начал вести блог все примеры приводил на ассемблере и всем все было понятно. Но это только мое ИМХО.
0
Ущербную вряд ли. Асм никогда не сможет послать одной коммандой сообщение. Или скрыть от пользователя буферезированный обмен данными.
MOV R0, MSG_SOMETHING
RCALL SendMessage

оборачиваем в макрос и отправляем сообщение одной командой SENDMSG MSG_SOMETHING.
А язык ассемблера очень даже нормальный и понятный язык.
На ассемблере не видна структура программы. Язык write-only. Использовать его для VM можно, но писать на нем — глупо, никаких плюсов по сранению с родным асмом нет. Так что если и делать VM, то либо с компилятором (но тогда вынутую из МК прошивку править будет нельзя), или делать VM, исполняющую структурный язык. Проги при этом будут выглядеть примерно как в лабвью или симулинке.
И более точного определения чем МЕДЛЕННО и НЕУДОБНО против ВМ
Второго пункта достаточно. Ибо, на минуточку, а нахрена вообще VM кроме как для того, чтобы было удобно? Так что если не придумаешь удобную в применении VM — это просто индусские понты.
0
Поддерживаю проект, могу помочь в тестировании на STM32, только следует точнее поставить задачу и требования к функциям «Умного дома»
0
По роду профессии работаю много с инженерными системами разного рода (спектр оч широк — СКУД и ОС/ОПС на Болиде, управление конференц-залами на AMX, диспетчеризация зданий на Шнайдере (в последнем проекте модикон в связке с адвантисами юзали).
Но что бы ни строили суть всегда одна — централизованное управление чем/либо по ethernet/rs-485(модбас в основном) — стоит контроллеру заглохнуть и всё. приплыли.
А народ тут активно желает навешать все функции на писюк… я понимаю, что для СЕБЯ, что домашний писюк месяцами не выключается и его никто не трогает, или может быть это какой нибудь перепрошитий коммутатор DIR/ASUS, но всё равно…
Всё предлагаю взять на вооружение технологию LON — когда между устройствами организуется единая информационная шина, в которой некоторые устройства могут быть передатчиками (выкидывать в шину сообщения типа — «я девайс номер ХХХ, у меня на вход ХХ пришёл сигнал Х) и приёмниками, которые эту шину слушают и сконфигурированы так, что при появлении определённого сообщения в сети выполняют какую-либо реакцию (включают/выключают свои бортовые реле например). Простейшим каналом передачи данных является всё тот же RS-485, но было бы неплохо настроить обмен по PLC (по силовым сетям). Тогда интеграция систем упростится в разы — например, схема включения „умного“ выключателя будет такой же как у любого другого устройства „фаза+ноль“, и больше ничего. Не нужно ни подводок витой пары, ни штроб… только ноутбук для конфигурации ;)
А если потребуется тач-панель например, то она включается в любом месте этой шины и работает как сниффер/эмулятор.
Плюсы системы — живучесть, масштабируемость, относительное удешевление (особо заметно при создании малых систем)
Однако срзу же возникают вопросы о защищённости сети, об адресации, о разрешении колизий, о системе событий и команд, помехоустойчивости и проч. и проч.
0
Чем ZigBee не угодил? Сейчас полно как SoC (те же самые STM32W), так и готовых модулей (XBee, Jennic и т.д.). Может, на ZigBee попробовать реализовать? Кто сталкивался? Стоит ли вообще начинать?
0
Идея интересная, и похоже востребована. Сам тоже подумываю об «умном доме», все собираясь начать реализовывать. Сразу оговорюсь, для меня «умный дом» это прежде всего устройства для комфорта, экономии и безопасности (в техногенном плане, а не криминальном). Готов помочь с железом, правда какой-то специализации в контроллерах у меня нет, изучать буду по ходу дела.

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

По интерфейсам. Идея с PLC кажется удобной для потребителя, тогда есть смысл смотреть в сторону уже развитого протокола X10. Хотя, если честно, мне почему-то больше нравится RS-485 ну или ZigBee, последний правда будет дороже. В этом случае нужно будет думать свой протокол.

По поводу виртуальной машины. Тут у меня опыта мало, конфигурационное ПО нужно. Но в каком виде его делать — вопрос.
0
К сожелению X10 очень медленный протокол:
Около 3/4 секунды занимает передача адреса устройства и команды.
(с)Wiki
Я тоже считаю что всю сеть нужно делать на RS-485. Вот с протоколом засада — открытый ModBus поддерживает всего одного мастера. Для разработки полноценного высокоскоростного PLS — я не обладаю необходимым опытом и знаниями. Если кому это по силам выскажите свое мнение.
0
А что мешает сделать несколько «подмастерьев»? т.е. провести не одну линию, а отдельные для каждого подмастерья, а они все будут на одной линии мастера. подмастерья аккамулируют информацию своих линий и отдают её мастеру.
0
Усложнение системы обязательно скажется на его надежности. И ИМХО, централизация не есть хорошо.
0
А как еще можно реализовать. Ваше предложение?
0
Можно взять к примеру принцип Ethernet, думаю это самый оптимальный и отработанный вариант. Каждый участник в сети полновправен. По-умолчанию слушает линию и отвечает, если к нему обратились. Может сам отправлять сообщения в сеть, когда от него этого требует ситуация. Естественно, неизбежны коллизии, когда одновременно появляются два мастера одновременно. В этом случае производится повтор сообщения через рандомное время. Другие варианты разрешения коллизий: использовать не рандомное, а как-то привязанное к адресу время задержки, либо выделение таймслотов на передачу каждому устройству (понадобится некоторый мастер, но его роль может брать на себя любой участник сети), либо использование «токена» (разрешения на передачу), который будет передаваться по кругу (как например в какой-то из кольцевых сетей).

В любом случае считаю что нужно ориентироваться на принципы, заложенные в сети передачи данных, в том числе и беспроводные.
0
Я абсолютно за построение систем где несколько устройств может быть по очереди мастерами. Но как при этом оставить совместимость с текущими устройствами которые уже работают по протоколу ModBus с 1-м мастером.
Да и вопросы производительности сети будут сказываться при усложнении протоколов обмена.
0
Но как при этом оставить совместимость с текущими устройствами которые уже работают по протоколу ModBus с 1-м мастером.
В «своем умном доме» я совместимость не предусматривал. То есть, в моих планах было создание практически всего необходимого железа. Мне как железячнику хотелось строить «новый мир» с блек-джеком и т.п., и я в нем не старался ориентироваться на существующие решения. Немного утопично, но опять же, это для себя. В крайнем случае можно сделать устройство типа «клиент нашей сети»-«мастер ModBus». Тут все зависит от того сколько ModBus-оборудования планируется подключать к сети. Если один-два, то вполне сгодится описанный мной вариант, если много — то тогда нужно думать что то другое.

Да и вопросы производительности сети будут сказываться при усложнении протоколов обмена.
К сожалению, да. Призводительность упадет. Тут нужно смотреть уже конкретные числа. Ведь компьютеры все еще работают =) А тем не менее, Ethernet сеть перестает работать, если в ней происходит больше 40% коллизий (точно не помню, кажется такая цифра, но точно небольшая).
0
Я так и думал что бы строить многоуровневую систему когда у контроллеров может быть 2 порта RS-485. И в одной сети он master, а в другой slave.
0
Все чё-то опять прилипли к RS-485… и называют его modbus. Не правильно оно. 485 — это только лишь транспорт, по которому модбас бегает, а организация протокола может быть любая. У Болида тож 485 основным позиционируется, а попробуй — разбери — что там происходит… голову сломишь. оно и понятно — охранные системы всётаки.

Я тут порой вспоминаю 1-Wire от Даласа, когда в датчике DS18b20 передача по аларму настраивается — система проходит инициализацию при пуске, и потом все дружно затыкаются, пока какой-либо из датчиков не зажарился/замёрз. Тогда он посылает в шину посылку, которую услышит тот, кому нужно (мастер/«подмастерье»/контроллер или же исполнительный блок)
Перед тем, как начать что-то изобретать своё нужно изучить то, что уже создано… а потом доработать напильником ;)

А вообще не люблю я провода. Монтажникам нашим всё равно — им чё нарисуешь — то они и сделают — хоть по 25-парнику в каждую розетку/распредщит дотянут;) а для своей квартиры… в ближайшее будущее ремонт делать не намерен, и вскрывать штробы в панельном доме не собираюсь) Поэтому или PLS или какой-либо радиоканал… сложно и то и другое.
Кстати, недавно на презентацию Эмерсона попал — они беспроводное оборудование для нефтяной промышленности выставляли новое (на основе самоорганизующейся сети). Оч интересное решение — каждый модуль автономен по электропитанию и живёт 4 года. Собирает инфу со своего датчика (давления, температуры, вибрации и т.п.) и вещает в эфир. Далее, по динамическому маршруту, данные идут от одного модуля к другому (модуль и как повторитель работает). Если один маршрут упёрся в тупик (модуль недоступен) система найдет новый путь. На мой взгляд оч интересно, но на коленке такое организовать невозможно)
0
Очень интересно узнать подробнее о самоорганизующихся сетях. Быть может организуете нам статью для начинающих?
0
Очень интересно узнать подробнее о самоорганизующихся сетях. Быть может организуете нам статью для начинающих?

UPD:
Я тут порой вспоминаю 1-Wire от Даласа, когда в датчике DS18b20 передача по аларму настраивается — система проходит инициализацию при пуске, и потом все дружно затыкаются, пока какой-либо из датчиков не зажарился/замёрз.
Кстати, да. Сеть «умного дома» это не сеть передачи данных, и сообщения в ней появляются так же редко как метеоры в небе. Потому опасения по поводу производительности и большого количества коллизий не сильно актуальны.
0
мои пять копеек — хотите красивые и недорогие панельки и хоть какую то стандартизацию используйте стандартные протоколы например — Modbus. Ну и самый дешевый и простой транспорт RS-485.

зы я не агитирую, это моя личная точка зрения, просто щас сильно сижу в этом и панельки и варианты всякие пересмотрел дешевле и распространенней modbus ничего нет пока — особенно на просторах нашей родины.
0
Повторюсь, но ModBus не устраивает лично меня по той причине, что он предназначен для централизованных систем. Ну и массивы данных по нему неудобно передавать (хотя может и не понадобиться). Мне хочется сделать распределеннцю сеть, где нет «мастера», который может выйти из строя и все станет.
0
не все так плохе как кажется :)
обычно мастером является дисплей или скада -они просто показывают и меняют уставки а шалабушки работают сами по себе, если даже мастер как то синхронизирует работу контроллеров на сети (обычно это делают по минимуму) то в худшем случае просто все работают по старому (в пределах алгоритма есссесвенно)
Если хочется чисто распределенный ввод вывод (без алгоритма на шалабушках) то при любом протоколе при отвале какого то из устройств что то не будет работать.
0
Хех, если честно не понял, как система будет работать без мастера и почему при отвале устройства что-то перестанет работать.
0
если не делается тупой распределенный ввод вывод то остальным контроллерам — как правило наплевать что с сетью (у них свои задачи определенные в загруженном алгоритме) и даже при отвале мастера они продолжат работать.
А с ethernet что тогда он тоже ненадежен — отвалися хаб что делать?
Есть правда несколько исключений — например свет и его выключатели
На самом деле из жизни правильно сделанные контроллеры горят редко так что чтобы отвалился именно мастер это надо постараться.
Как правило наиболее уязвимы каналы связи и трансиверы
Ну и в крайнем случае можно сделать — отступление от стандарта и повесить дублирующий мастер — нет обмена на шине он заработал.
0
Что ж, вы сами и доказали, что распределенная сеть будет надёжней: из практики, всегда всё равно отваливается всё, а каналы связи они будут в любом случае.
0
еще раз повторюсь я не агитирую за modbus и rs-485.
Но точ то вы гноворите imho с точностьюдо наоборот :)
1.Если выжигается трансивер то rs-485 как правило падает и неважно клиенты или слейвы -мастеры
2.Если умирает или отключается хаб то ethernet тоже падает
3. Просверлят стену с проводом тоже привет…

Просто хочу сказать что при прочих равных мастер-слейв проще в реализации и диагностике чем например тот-же BACnet MS/TP (BACnet конечно перспективней но дороже по всему)
Если конечно не ограничивать себя во времени и средствах… то имхо BACnet
0
1. Ну, я не думаю, что у вас настолько большой дом, чтобы в нем понадобился трансивер RS-485 =)
2. Я же не имел в виду, что нужно использовать топологию Ethernet, я говорил о принципах взаимодействия участников. Для RS-485 не предусмотрено другой топологии кроме линейной общей шины.

Но я так понял мы просто по-разному называем одни и те же вещи, или разные вещи одними и теми же словами. Предлагаю закончить флуд =)

PS: пошел читать о BACnet
0
1. трансивер это тоже что и драйвер — MAX1487,MAX487, ADM485, ADM3485 и так далее стоит в каждом узле
2. Можно дерево через репитеры

ps BACnet это ад… :)если не найдете пишите есть один из стандартов
0
Вот вопрос не в тему: а почему никто не говорит про UART? Чую, есть причина, но какая?
0
Потому что UART или правильнее RS-232 это уровень физической передачи сигналов. И помехозащищенность обеспечивается разностью уровней передаваемого сигнала (+/- 12 — 15 В — как раскачает микросхема интерфейса). RS-422 или RS-485 абсолютно совместимы с RS-232 по формату передаваемого пакета только передача идет по витой паре что соответственно увеличивает помехозащищенность. По ссылкам почитаете о скоростях и расстояниях.
0
Если посмотрим что такое UART, то увидим, что это устройство. Устройство которое что-то там передает (сейчас нам неважно как), то есть именно та штуковина, которое обеспечивает нам физический уровень модели OSI, а именно — передачу сигналов по двум проводам.
0
УД это конечно хорошо, но многие разработки (по собственному опыту) заканчиваются тем, что все упирается в надежность, где основную роль играет протокол обмена данными. Т.е. сделал, как-то запустил, но работает с перебоями + видишь что сеть легко может заглючить и всё, это создание ни себе ни людям. Поэтому изначально надо закладывать надежность в одно из главных требований, а следовательно никаких самодельных протоколов, ну хотяб на физическом и канальном уровнях. Сейчас смотрю в сторону CAN, долго смотрю, всё руки не доходят… :) И конечно буду использовать stm32 тем более там есть поддержка CAN, да и на реал тайм ось ресурсов хватит. Сеть вижу только распределенной (децентрализованной). Причем основную часть буду реализовывать в щитке на DIN рейке… задумок хватает, но сначала нужно делать ядро — сеть.
В основном понимание структуры УД у меня схоже с автором, но я незнаком с виртуальными машинами, можно поподробнее что вы подразумеваете под этим, какова функция?
0
  • avatar
  • AntiL
  • 24 августа 2011, 16:59
я незнаком с виртуальными машинами, можно поподробнее что вы подразумеваете под этим, какова функция?
Когда вы пишете программу для какого либо контроллера, то после компиляции она представляет собой набор низкоуровневых команд свойственных только данному микроконтроллеру. И что бы изменить целевую платформу то нужно учитывать нюансы данной платформы. Если же сделать виртуальную машину (ВМ) для двух различных платформ (AVR32 и STM32) то однажды написанная программа и оттранслированная в объектный код будет исполняться и на той и на другой плате. Так же хочу снабдить ВМ возможностью более медленной работы, но пошагового режима исполнения. Соответственно можно производить отладку программы без специального программатора/отладчика в реальных условиях. В целом ВМ скрывает тонкости работы с оборудованием и работает на уровне послать сообщение используя ModBus/CAN, а ВМ соответственно выдерживаетвсе необходимые временные интервалы и подает соответствующие сигналы на внешние микросхемы преобразования интервейсов (UART -> RS-485).
0
Ну то есть это будет либа которая будет отвечать за поддержку протокола от канального до прикладного уровня + возможность пошаговой отладки?
А пошаговую отладку тоже хотите по сети делать? с трудом себе это представляю, загрузку прошивки по сети — это понятно зачем, но отладка…
0
Отладка не по сети. Отладка и прошивка по USB|COM порт. Прошивка по сети это отдельная тема. Я о ней даже не думал.
0
чтобы не изобретать велосипед советую посмотреть на eLua, GraspForth, Riscy Pygness, Armpit, или еще лучше — на Android
0
Спасибо за библиотеки.
но вот что нашел по этому поводу:
Скажем LUA на 100..200 МГц ARM-е работает с той же скоростью, как нативный код написанный на C и скомпилированный компилятором Hi-Tech работающий на PIC16xx
ссылка
Для андроида нужны мегабайты памяти и на недорогой ARM его не поставишь.
0
Ну а с чего ты взял, что твоя машина будет быстрее? Да и не нужна в большинстве задач там производительность выше чем бейсик на спекки) А где нужна — там уже обычно и меги мало. Ну и для стандартных критичных к ресурсам задач, типа общения по сети, можно (точнее нужно) сделать нативные функции.
0
Брррр… ужосы пишешь какие-то. Для чего менять целевую платформу среди белого дня? И при этом использовать ВМ… — т.е. переносить старые наработки (и баги в том числе) от версии к версии.

Представь презентацию такой продукции:
" — Это пульт на АТМЕГА64 — умеет то-то и то-то, и тупит там-то и там-то.
— А это пульт на СТМ-32 — так как в нём стоит та же ВМ мы просто перенесли софт. Железка новая, а глюки старые".
Бу-га-га)))

Это крайне нерационально, как мне кажется. Лучше тогда изначально заложить платформу с достаточными ресурсами для модернизации, и чётко наметить пути таковой модернизации.
Как пример горячо-любимое оборудование Болид: во все железки заложены PIC-и, значит инженеров распылять не требуется для изучения граблей/костылей, трюков и прочих особенностей разных контроллеров. В пульте (С2000-М), с самого его появления запаяны две банки памяти ЕПРОМ по 512кбит — поначалу они ничего не давали. Потом прошивочка появилась 2.04 — в ней сценарии/разграничения прав и проч вкусности организовались… заранее заложеный ресурс позволил))
И вообще ребята чешут на опрежение — недавно с помощью их софта хотел конфу набрать на пульт, и позабыв номер текущей версии забил 2.05 — софт открыл мне рыбу «пульта будущего», о котором я даже ещё не читал — там и считыватель заложен, и локальные реле. И удивило именно то, что платформа, софт конфигурации, да и цена у них практически не меняется от версии к версии — только добавляются новые фишечки и исправляются старые баги, коих и так не много. И это есть большой плюс
0
с помощью их софта хотел конфу
где можно посмотреть их софт?
0
По поводу оборудования БОЛИД. Все железки работают на охранный/охранно-пожарный комплекс. Основная суть — часть железкок наделены шлейфами (а-ля входами) — охранный, дымовой, комбинированый и проч, с возможностью появления различных событий на них (для дымового шлейфа характерны события — «внимание» — это сработка одного извещателя, «пожар» — сработка двух извещателей, «неисправность» — КЗ или обрыв шлейфа). К таковым, например, относится прибор С2000-4. А ещё есть часть железа наделеного реле (а-ля выходами) с различной тактикой работы — прибор С2000-СП1 к примеру. Есть и комбинированые приборы — Сигнал-20 — в нём более 10 шлейфов и около 5 реле. В системе обязательно есть контроллер — будь то пульты С2000 (более новый С2000-М) либое же АРМ ОРИОН (автоматизированое рабочее место) на посту охраны. В контроллере с помощью программы PPROG конфигурируется связь — по сути сопоставляются события со шлейфов определённым тактикам на реле. Но в большинтсве случаев приборы способны работать в автономном режиме, а контроллер всего-лишь логирует события — например С2000-2/С2000-4 в качестве контроллера доступа; С2000-АСПТ — для управления установками газового пожаротушения; РУПОР — как генератор речевых сообщений для эвакуации персонала при пожаре (кстати может менять тактики в зависимости от изменения ситуаций). Все железки конфигурируются программой URPOG. Весь вышеперечисленный софт для настройки оборудования бесплатен по природе. АРМ ОРИОН без ключа работает 4 часа — потом вылетает. Для экспериментов и отладки самое отлично ;)
Если понять философию Болида, то работать оч приятно. За час набить конфу для небольшого офиса и отладить всю систему не составит большого труда (в последнем проекте на 12 шлефов, 40 извещателей монажники в трёх местах попутали провода, за полдня налобал конфу, высек все косяки и накотал инструкцию пользования). А по началу туго давалось… и их доки, и софт, и отладка.
0
Уточнение...
Подскажите если не применять виртуальную машину. Как конфигурировать логику работы контроллера?
Пример из реальной жизни: Датчик температуры — ПИД регулятор — Нагреватель/Холодильник
Если Применить ВМ то будут команды типа:
1. Получить температуру датчика
2. Посчитать мощьность Исполнителя
3. Нагреватель/Холодильник Вкл/Выкл.
И это конфигурирование можно делать без изменения прошивки контроллера.
Использование же только найтив кода — или Задача=Блок, или Высокая квалификация разработчика/внедренца.
И очень интересно как конфигурируется упоминаемый Вами "Болид"
0
В нативном коде это решается стандартизованной подборкой библиотек. Годный пример — ардуино. Тот же С, компиляция в нативный код, но благодаря библиотекам все очень просто.
И тогда будет код в духе:

t=getTemp(SensorPin);
p=calculatePID(t, ...);
analogWrite(HeaterPin, p);
0
Высокая квалификация разработчика/внедренца.

Я думал, мы собираемся делать умный дом для себя, а не для домохозяек. :-)
0
Нет, тема как раз-таки подразумевает попытку создания платформы «для всех».
0
Плюсы ВМ:
Не зависимость от конкретной платы (AVR, PIC, STM и др.)
Возможность отладки программы в железе через USB/Com порт
Использование в разработке различных методов тестов кода
1 — а нужно ли оно? Да и опять же, С плюс библиотеки позволяют скрыть различия между МК не хуже.
2 — а она и так есть, у PIC вроде OCD даже в младших моделях и есть открытый программатор-отладчик пиккит, у армов вообще с отладкой в железе прекрасно, туго с ней тока у авр из-за того, что покупать атмеловские тулзы дорого, дебагвайр еще не отреверсили, а имеющийся JTAG поддерживается в 3.5 моделях и страшно тормозен.
3 — а что мешает то же делать на нативке?
Минусы ВМ:
Снижение производительности
И весьма солидное. К тому же она обычно требует для своей работы прилично памяти.
0
  • avatar
  • Vga
  • 25 августа 2011, 20:12
Спасибо за комментарии. Но пока четко для себя не могу определить ВМ или не ВМ.
Согласен что если идти по пути Arduino, то цель доступности и высокой производительности будет достигнута на 100%.
Но возникает вопрос, как работают современные ПЛК. Зачем существует Список инструкций (IL)
Как конфигурируется тот же С2000-М или LanDrive SPIDER2
И если компилировать все в native код, то как через 3-6-12 месяцев «подкорректировать программу» или как клиенту не быть зависимым от одного внедренца.
Ведь встречал в своей практике когда программист пишет код понятный только ему и этим удерживает клиента.
Код ВМ можно вычитать обратно из микроконтроллера, откорректировать и снова залить.
0
Можно подумать, ПЛКшники не зависят от внедренца.
Как конфигурируется тот же С2000-М или LanDrive SPIDER2
Не смотрел, но возможно оно даже не программируется, а просто настраивается. В духе «включить термостат на 25 градусов, на вход термометр на линии 5, на выход нагреватель на линии 7».
Еще есть сети LonWorks.Инфы по ним по тем линкам что я смотрел весьма немного, но схемы намекают на то, что с точки зрения юзера сеть — не более чем замена проводков, которыми соединяется выход термометра с входом термостата — как в каком-нить симулинке. Т.е. протянул сеть, воткнул в нее все девайсы и затем конфигурируешь схему из блоков со стандартными входами-выходами.
0
В духе «включить термостат на 25 градусов, на вход термометр на линии 5, на выход нагреватель на линии 7»
а что от умного дома то вообще хотят???
Любое устройство в конечном итоге имеет входа и выхода.
Логика же сводится к: «Если на одном входе XXX, значит на выходе нужно сделать YYY». А что это будут за входа, что за выхода — это уже слабо интересует хоть управление котлом и трёхходовым вентилем, что просто включение лампочки на кухне.

Поэтому, прежде всего, нам нужно нужно заложить основные принциипы умного дома. На мой взгляд их три.
Автоматическое управлене/регулирование;
Ручное управление;
Мониторинг/логирование.

Подробно сложив для себя — что мы хотим от каждого пункта мы уже обрисуем топологию, за ней принципы программирования/конфигурирования/параметрирования системы, и в конце придём к пониманию — на чём оно будет всё будет крутится, как обмениваться данными и т.п.
0
Подробно сложив для себя — что мы хотим от каждого пункта мы уже обрисуем топологию, за ней принципы программирования/конфигурирования/параметрирования системы, и в конце придём к пониманию — на чём оно будет всё будет крутится, как обмениваться данными и т.п.
Хе-хе, а вот это-то на самом деле и есть самое главное и сложное)
0
с этого и нужно начинать;)

Нужно было топик назвать — «основные концепции умного дома» — глядишь дело бы продуктивней пошло))
0
Согласен, сначал необходимо определиться чего мы хотим. А то сразу взялись за обсуждение протоколов, интерфейсов, распределенных сетей.

А я вот начал думать зачем нужна распределенная сеть и… не придумал. Возможно она и не нужна для этой задачи.
0
Код ВМ можно вычитать обратно из микроконтроллера, откорректировать и снова залить
Обычно он не полезнее, чем слитый оттуда же дамп бинарной прошивки. Тебе вот это много о чем говорит?
Proc [59] Export: ISCRYPTCHECK 16
 [0] PUSHTYPE 19(Class) // 1
 [5] ASSIGN Base[1], GlobalVar[6]
 [16] PUSHVAR Base[-1] // 2
 [22] CALL 47
 [27] POP // 1
 [28] POP // 0
 [29] COND_NOT_GOTO currpos + 12 Base[-1] [51]
 [39] CALC Base[-1] AND GlobalVar[8]
 [51] RET
0
Тут Я с Вами не согласен есть инструменты которые из IL кода делают C#.
Но я не об этом. Для меня Важно что бы можно было как в 1С: Предприятии (извините за сравнение, но на мой взгляд революционная штука для учета) пришел подправил типовую конфигурацию. Через время пришел еще откорректировал. И не нужно хранить исходный код или для нового клиента разрабатывать то что у него уже есть и корректировать под новые потребности.
PS 1С: Предприятие
0
Тут Я с Вами не согласен есть инструменты которые из IL кода делают C#.
Да. И для жабы. Для прочей мелочи их никто не делает — слишком сложно. Конечно и это (это результат декомпиляции байткода ROPS — и на исходный паскаль он похож довольно слабо) можно восстановить до более читабельного вида — тут есть некоторая метаинформация (о типах и именах переменных, кроме локальных, например, о прототипах функций), да и оптимизатор если и есть — не столь хитрожопый, как в С++, но это не так-то просто. Кстати, шарп и ява восстанавливаются не полностью — например, не восстанавливаются комментарии. Хотя результат декомпиляции можно скомпилировать и оно будет работать — это действительно круто.
Для меня Важно что бы можно было как в 1С: Предприятии
Это или языки, где скомпилированный не отличается от исходника (графические, да) или как 1С — хранить исходные тексты. Но никто не мешает хранить на МК исходные тексты залитой в него прошивки на С :)
Или же разрабатывать свой графический язык (или реализацию имеющегося), но тогда стоит сразу закладывать МК, у которых много памяти.
0
После всех замечаний по поводу производительности и малой разницы в цене я склонен к STM32. Но изначально планировал что на каждой плате будет стоят порядка 1 Мбайта spi flash в котором и будет храниться вся необходимая информация.
А по поводу «графического языка» можно по подробней?
0
Почти все, на чем программируются ПЛК — когда программу не пишешь, а рисуешь как схему/блоксхему. Файл исходника при этом реально не текстовый, а бинарный, и вполне можно оптимизировать его как для удобного и быстрого выполнения, так и для удобного редактирования.
0
Pencroff, мне кажется что использование термина «ВМ» сбивает с толку и приводит к лишним дискуссиям. Поправьте меня, если ошибаюсь, но я задумку понял не как ВМ, а как скриптовый язык описания логики работы устройств. Как я себе это представляю. Создаются исполнительные устройства, датчики, интерфейсные устройства и т.д. У каждого свой микроконтроллер, с готовой прошивкой. Когда нужно внедрить всё это в реальный дом, мы не трогаем прошивку. А только заливаем в требуемые модули наборы правил поведения. Правила простые, не требуют навыков сложного программирования и не зависят от конкретной реализации модуля. Например, умной кнопке делаем скрипт «при нажатии — отправить в сеть код Х», а реле лампы «при обнаружении в сети кода Х — включить лампу». Если так, то полностью идею поддерживаю, кроме названия «Виртуальная машина».
0
  • avatar
  • ACE
  • 25 августа 2011, 23:08
Дык скрипты и исполняются виртуальными машинами. Это куда выгоднее по производительности, чем напрямую работать с исходным кодом. Та же lua скрипт компилирует в бинарный файл своей ВМ, и только его уже и исполняет. Это быстрее, экономит память, да и сам скомпилированный скрипт гораздо компактнее.
Скриптовых движков, которые работают без VM крайне мало.
0
Виртуальная машина подразумевает полноценную вычислительную среду и соответствующий скриптовый язык. LUA уже скорее язык программирования, я же имею ввиду что-то гораздо более простое. Что-то типа машины состояний. Состояние — вход — реакция — новое состояние. Я бы всё-таки виртуальной машиной это не назвал.
0
Вы все правильно описали. Только другого термина как «Виртуальная машина» не существует. Моя идея аналог этого только для недорогих микроконтроллеров (скорее всего ARM)
0
Я бы ограничился аналогом FCL, вполне достаточно. Это не геймдев, где актуален допил и дебаг скриптов без перезапуска игры (да и компилируется она всю ночь на кластере). Фреймворк позволит снизить сложность работы на С до уровня начинающих и скрыть многие, а то и все, платформенные различия. С точки зрения тех же ардуинщиков меги 8, 88 и 168 и 2560 отличаются только количеством памяти под скетч.
0
Зачем? Какой смысл делать виртуальную машину с функционально полным языком программирования? Имхо это должен быть даже не скрипт, а набор простых правил. Для централизованной системы, как при использовании ПЛК в промышленном управлении, это актуально. Там и задачи шире, и все алгоритмы в одном месте. Если система децентрализована — отдельные блоки должны не столько программироваться, сколько настраиваться.
0
Полностью с тобой согласен по поводу децентрализованных систем — ни о каком программировании и си-подобном коде для конечного интегратора в таких системах не может быть и речи. Она должна быть простая как молоток, с чётко зашитыми блоками правил, и основная задача интегратора сводится только к параметрированию этих блоков и заданию связей. Иначе «открытая» платформа будет открыта только для ограниченого круга лиц))))
0
А если организовать систему так: пусть каждое устройство в умном доме будет представлять собой автономное устройство, таких устройств несколько стандартных типов (10-20), аппаратная реализация не является принципиально важной.
Далее устройства могут быть объединены в сеть, каждое из которых имеет набор входных параметров и выходных данных — то есть имеет стандартный интерфейс.
Центральным устройством является ПК, пишем программу для конфигурирования всей системы, в ней каждому из стандартных устройств соответствует виртуальный блок с соответствующим интерфейсом, в программе можно задавать требуемые параметры устройств, задавать связи, отслеживать состояния, отключать/подключать устройства. Тогда настройка системы будет предельно простой.
Главное, что мы не думаем о том, как реализовано каждое устройство, лишь бы оно предоставляло стандартный интерфейс. По аналогии с классами в ООП.
0
И получаем LonWorks?
0
упрощённо да, если сравнивать с s-technology.com.ua/a/lonworks.php, то в нашем случае на каждом устройстве обычный микроконтроллер, и сеть устройств централизована
0
И получаем LonWorks?

Центральным устройством является ПК

На LON не сильно похоже))) Скорее опять на тот же modbus

Или может я туплю, и wolff имел в виду ПК только для конфигурирования системы, а работать она самостоятельно?
0
Лююди ау!
Объясните сирому что вы хотите построить и за сколько сотен человеко лет и для чего все это надо?

зы до железа дело то дойдет?
0
Далее предлагаю вести обсуждение и разработку по направлениям.
Обратите внимание на Резюме.
0
имхо схема в резюме не совсем ясна т.к. кроме конфигурирования нарисовано еще и — web что это значит?
почему тогда только usb? идеологически просится еще либо Ethernet/wifi или rs485
имхо usb может быть удобным дополнением например для быстрого старта и работы на столе

ps у подобных современных контроллеров обычно два порта на одном он слейв на другом мастер — это наиболее удобная схема позволяющая гибко строить систему
0
Приглашаются все желающие по адресу: iqhouse.teamlab.com
Запишите меня, пожалусйта: jack.krieger(at)gmail.com
Имя пусть будет Krieger, хотя предпочитаю пользоваться OpenID
0
Мне главное создать Вам профиль а там и подключите OpenID
Я тоже через аккаунт твиттера вхожу.
0
Кто интересовался BACnet вот ссылка на стандарт 2004 года
www.onlinedisk.ru/file/721585/
0
А еще обратите внимание на CAN
0
Зачем нужна ВМ?
Пример.
Есть две системы отопление и вентиляции.
Отопление: датчик температуры, ПИД, нагреватель.
Вентиляция: датчик влажности, ПИД, задвижка и вентилятор.
Для простоты программы считаем что интерфейс датчиков одинаков.

По сути программа:
1. Считать с датчика;
2. ПИД расчет;
3. Исполнитель.

Но есть маленькое отличие вентилятор в системе вентиляции.
Если мы пишем на native коде то существует несколько вариантов:
1. Отдельно плата под несколько систем отопления и аналогично отдельно плата под несколько систем вентиляции.
2. Одна плата но программа жесткопрописанаспециалистом внедрения, и изменение конфигурации аппаратуры может привести к написанию НОВОЙ программы.
3. ВМ. Еще один уровень абстракции. Программу может откорректировать другойвнедряющийили опытный пользователь. Уровень абстракциикомандскрывает тонкости взаимодействия с аппаратурой — датчик, исполнитель, сложный расчет. А так же программа может описать любые логические связи или доп. параметры системы (которые могут конфигурироваться внешним ПО).
0
При наличии исходника спокойно можно поправить программу пункта 2. Программу же на языке VM той же луа без исходников ты не поправишь. Насколько мне известно, декомпилятор луа сравнимого с JAD качества написать еще никто не удосужился. То же самое будет и на твоей вм, если только она не будет кормиться непосредственно исходным кодом.
0
Знаю два подхода
1.Предопределенные объекты исполняются из оперативки — обертка п/о для конфигурации объектов и связей и создания имейджа этих объектов для загрузки по сети — сам предпочитаю этот вариант

2.Все исполняется из flash как обычно — как в codesys те обертка для i/o и обработки более функциональная но и более требовательна к программисту — но по сути компилятор
0
Поясни а то совсем не понятно. Что за подходы?
0
1.строятся массивы объектов — структкр в по на компе заводятся связи между членами, но типы объектов предопределены и не могут быть изменены пользователем
2. компиляторный подход пишутся функции io к разным интерфейсам и собственно любой пользовательский код в пределах таргета
как то так
0
Дома бывают разные.
Например – однокомнатная квартира.
Например – четырехкомнатная квартира с двумя санузлами.
Например – дачный сарай с совмещенными спальней и кухней и удобствами на улице.
Например – дачный домик на три комнаты.
Например – трехэтажный коттедж площадью 110 кв.м.
Например – трехэтажный коттедж площадью 2000 кв.м.
Например – имение с парком, площадью 2 гектара.
И так – до бесконечности.
Наивно полагать, что система (пока я назову это системой, потому, что пока непонятно, что это такое) управления такими разными домами будет одинаковая.
Соответственно, первое, что нужно сделать – это определить – а чего мы, собственно, хотим? В каждом конкретном случае.
Хотя, на самом деле, еще важнее сначала определить – система делается для себя – любимого или для ее презентации клиентам? (Как я понял из обсуждения, основная масса участников сообщества думает именно о своих домах).
И еще. То, что предлагается сделать – это для жизни или для понтов?
Это я к тому, что сначала должна быть разработана концепция. Как система должна функционировать, какие возможны варианты. В квадратиках. Или пунктах большого списка. С вариантами. А потом уже переходить к конкретной реализации и виртуальным машинам.
Теперь по поводу дискуссии о виртуальных машинах.
Я за виртуальные машины.
Конечно, если я делаю систему для себя и не предполагаю, что еще кто-нибудь будет ее настраивать и ремонтировать, то я могу ее сделать так, как мне хочется. Особенно если я крутой программист и пальцы у меня веером летают по клавиатуре. Но неплохо бы подумать и о тех, кто придет после нас. А тем более, если система делается для клиентов.
С точки зрения разработки, отладки и сопровождения системы, виртуальная машина очень удобна. Она позволяет унифицировать язык программы управления независимо от применяемой элементной базы. Датчики и исполнительные устройства могут использовать любые контроллеры и программироваться на любых языках. Главное, чтобы был стандартный интерфейс подключения и описаны (и, желательно, стандартизированы) команды управления и обмен данными.
Виртуальные машины применяются гораздо чаще, чем мы предполагаем. Вспомните хотя бы JAVA машины – они реализованы практически во всех компьютерах и мобильных телефонах. И никто от этого пока не умер.
А я бы посоветовал обратить внимание на интересную серию оборудования фирмы «Фрактал» www.fractal.com.ru/index.php?p=price&sp=price&ssp=all.
Посмотрите их линейку – в первую очередь модули вычислителей (16-битная серия выпускается так же под маркой «Мастер Кит»). У меня есть их вычислители предыдущего поколения – MCU4-6 на AT89S53 и MCU42-3 на AT89C55. Очень интересные устройства. Программируются на Бейсике. Стандартные интерфейсы — в частности RS485 с поддержкой Modbus. И конструктив на DIN-рейку удобен для монтажа в шкаф или на щит. Последние вычислители на STM32 гораздо быстрее, но язык остался прежний. Я не настаиваю на их использовании, но можно попробовать сделать нечто аналогичное. Или применить как основу.

В качестве бонуса для любителей программирования для PC могу порекомендовать контроллеры от ПК Пролог www.codesys.ru/sc23. Можно установить ДОС — и вперед.

Но, в любом случае, сначала — концепция.
0
  • avatar
  • mzw
  • 31 августа 2011, 13:46
Хотя, на самом деле, еще важнее сначала определить – система делается для себя – любимого или для ее презентации клиентам?
Моя идея сделать платформу для клиентов (на которой потом еще можно заработать денег). Может конечно не верный подход в плане открытой разработки но самому пилить — всей жизни не хватит :)
И еще. То, что предлагается сделать – это для жизни или для понтов?
Для жизни конечно же. Не дорогие модули которые будут доступны ВСЕМ. И тогда умный дом будет в квартире (доме) у каждого.

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

А за Ваше мнение спасибо. Еще раз убедился что все ВЕЛОСИПЕДЫ уже изобретены. То что я долгое время вынашивал в голове ужереализованофракталом на 95%. И не важно что там интерпретатор, а не виртуальная машина и байт код. Идея уже реализована и продается.
0
0
  • avatar
  • mzw
  • 31 августа 2011, 14:07
имхо Бейсик это зло для асутп :)
там несколько иная парадигма.
0
А дом не подходит под это определение?
Автоматизированная система управления технологическим процессом.
0
И в чем зло?
0
обычно в таких системах идет много «параллельных» процессов — особенно задержек и проще/удобней делать программирование функциональными блоками.
И еще один момент — инженеры асутп как правило не мыслят категориями «Си/Байсик/Паскаль» — неудобно. Категории -датчик, вход, задержка, выход, привод им более понятны
0
А взаимодействие между категориями как описывается? На IL или ST. Или я что то не так понимаю?
На мой взгляд абсолютно не важен язык (в 1С например вообще программируют на РУССКОМ языке а предмет Учет), а главное его подмножество для предметной области, в частности датчики, вход, выход и т.д.
0
Скорее на LD, SFC и FBD. Последний кстати я по сути и предлагаю сделать.
0
согласен FBD — наиболее удобен для таких вещей и тут главное создать адекватный набор объектов.
0
Я бы прежде всего заглянул в спецификацию FBD и уволок оттуда все стандартные объекты. Или вообще весь язык.
Алсо, есть смысл сетку делать так, чтобы удаленные девайсы выглядели как обычный FBD-блок. Будет как раз нечто лонворкс-образное) Хотя, тогда конфигурация сетки будет задаваться прямо при программировании устройств, а не с мастер-конфигуратора. Возможно это и не лучшая идея и на уровне устройств стоит тока реализовать «сетевые переменные» аля лонворкс (или собсвна лонворкс — совместимость со стандартами лишней не бывает).
0
Lon имхо не имеет смысл делать имхо дорого (посмотрите цены на трансиверы и инструментарий), сложно и привязка к производителям
да и дофига уже устройств на лоне рынок перенасыщен ими.
+стандарт скажем так не имеет будущего по статистике в развитых странах наблюдается падение уровня lon инсталляций и рост BACnet

ps я так и не понял за сколько времени хочется что то сделать?
0
Протоколы открытые, так что можно реализовать лон-сеть на чем угодно. То что дофига устройств — напротив, плюс — их легко можно будет интегрировать. Кроме того, эта сеть разрабатывалась профессионалами, которые учли многое, о чем мы и не вспомним.
BACnet еще не изучал, ничего не могу про него сказать.
0
«Протоколы открытые, так что можно реализовать лон-сеть на чем угодно» — поясните пожалуйста ибо я знаю только двух производителяч нейрон чипов — Cypress Semiconductor and Toshiba
www.echelon.com/communities/developers/lonworks/neuron.htm
0
Насколько я понял, Lon — стандарт открытый, документация есть и реализовать можно на чем угодно, не обязательно на нейронах. ЕМНИП об этом даже сам производитель говорит.
0
  • avatar
  • Vga
  • 01 сентября 2011, 14:50
не совсем понимаю о чем вы если есть ссылку в студию но как минимум производитель как мне кажется лукавит ибо зачем тогда было делать чипы…
Даже если и есть все спеки на lonworks то это опять же адская работа (вспомним чипы) по его созданию которая ведет в никуда.

зы я не против Echelon на определенном этапе это была передовая технология, но сейчас есть альтернативы да и финансово это невыгодно будет трансивер с чипом на каждое устройство ~30usd +lonmaker ~2000usd
0
Вот, например:
Dedicated microprocessor. Invented by Echelon, this processor (also known as the Neuron core) is highly optimized for devices on a control network. Neuron cores have three or four 8-bit processors: two are dedicated to the communications protocol and one is a general-purpose applications processor. Series 5000 Neuron cores add a fourth processor for interrupt servicing. A number of chip manufacturers market the Neuron family of microprocessors.
* The protocol can be ported to the processor of your choice. The market currently includes ports of the protocol to Altera's Cyclone III FPGA and National Semiconductor's LISA chip.
Упоминается это и в прочих источниках, той же вики.
Сам LonWorks мне нравится во первых, самой идеей конфигурации сети как виртуальных проводков, соединяющих блоки на схеме, причем тянуть их можно как угодно, с точки зрения топологии сети озаботившись только тем, чтобы все девайсы были физически подключены к ней (как я понял), во вторых — это децентрализованная Р2Р сеть, ну и в третьих — это стандарт и под него есть оборудование, да и проработан он куда лучше, чем свой велосипед.
но сейчас есть альтернативы
Ну и на них надо посмотреть, да. А какие есть альтернативы вообще, кроме BACnet (который я пока вообще никак не курил)?
0
  • avatar
  • Vga
  • 01 сентября 2011, 15:44
«Cyclone III FPGA and National Semiconductor's LISA chip» — а в чем плюс то перед newron chip? у вас ведь нет этих портов? Да и цена и применимость не думаю что будет хорошей
0
-_-'
У меня есть руки и мозг, чтобы при желании это реализовать на STM32. Если конечно оно не требует ресурсов кора 2. Хотя сам нейрон — трехядерный восьмибитник (из них два ядра на сеть и работают).
0
  • avatar
  • Vga
  • 01 сентября 2011, 18:08
ок ждем результатов :)
0
От меня? Врядли. Я слишком ленив и пока не особо собираюсь умным домом заниматься. Тем более что даже и не знаю, что мне от него нужно.
Так что разве что если накатит вдохновение поковырять лон лулзов ради и не кончится прежде, чем появится хотя бы что-то ;)
Но если бы мне было надо — я бы посмотрел именно в сторону реализации lon или другого стандартного протокола.
0
  • avatar
  • Vga
  • 01 сентября 2011, 19:15
«другого стандартного протокола.» -золотые слова однако
0
Так это и нужно.
0
Ещё хочу высказать свое мнение об идеологии построения системы.

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

По поводу каналов связи. Они должны быть только проводными. Беспроводные системы очень чувствительны к помехам и их работа может быть легко нарушена как злоумышленниками, так и самими хозяевами по незнанию.
Пример – к нам на работу принесли посмотреть беспроводную видеокамеру (диапазон 2,4 ГГц). При ее включении сразу умер Wi-Fi.
Проблем нет сделать мощный передатчик помех на диапазоны 433, 868 МГц и другие (а они широко известны) – и вся система рухнет. Попытка съэкономить может кончиться плачевно.
0
  • avatar
  • mzw
  • 31 августа 2011, 19:58
По поводу основной идеи полностью согласен. В сети необходимо выделить подсистемы (охранка, пожарка, свет, климат и т.п.). Но вот интерфейс у них должен быть общий. чтобы и пожарному извещателю и к датчику освещения можно было обращаться одними и теми же командами.
0
В принципе, как я понимаю, связь системе нужна в основном для мастер-управления и контроля, сами блоки предполагается сделать довольно автономными (т.е. весь скажем контроллер отопления собран на одном процессорном модуле), а отвал его не столь уж страшен. Радио упрощает развертывание, так что стоит как минимум предусмотреть вариант радиоканала. И еще — канал через PLC. Ну и в принципе, никто не мешает развертывать смешанную сеть — критичные линки проводные, некритичные и неудобные — по радио.
0
Контроллер отопления должен получать информацию из комнат (если это именно контроллер системы отопления, а не контроллер котла). Так, что он будет использовать линии связи. То же для сигнализации, охраны и прочего.
0
Меня добавьте, пожалуйста!
Const_D
d110272@yandex.ru
0
И меня добавьте, плиз
Admiral
admiral(dog_with_tail)tut.by
0
И меня добавьте, плиз
Admiral
admiral(dog_with_tail)tut.by

По поводу выбора связи — я считаю, что лучше беспроводная. На примере ZWave (самоорганизующаяся сеть с маршрутизацией).
Плюсы в том, что можно постепенно наращивать функционал своего дома, притом не надо прокладывать заново проводку. Это ОЧЕНЬ большой плюс.
К примеру тот же датчик движения — чуть сделал перестановку в квартире — его надо перевешивать, а провода-то в то место не проложены.
Проводной вариант годится только в случае ремонта во всей квартире.
Читал отзывы про Х10 — тоже не очень лестные. Мало того, что оборудование бешеных денег стоит (фильтры, мосты между фазамии т.п.) так и скорость вообще никакая. Да еще и обратной связи нет.
В общем мое имхо — только беспроводная связь.
0
Я уже начал реализацию оного, Поэтому свои 5 копеек (тезисно).
Основа — (http://www.ebay.com/itm/Development-Board-STM32F107VCT6-128M-Flash-LCD-/300602751019?pt=BI_Electrical_Equipment_Tools&hash=item45fd51f82b#ht_7548wt_1344) — аналогов куча.
Причина — цена, поддержка большинства протоколов, малое энергопотребление.
Цель — возможность связи извне по GSM,Ethernet и во внешку по почте, смс и голосовому каналу.
Связь с периферийными модулями (тоже на STM32) по IRDA, 1-Wire, RS-232 в зависимости от задачи (управление котлом, бензоагрегатом, сигнализацией, видеорегистраторами, метеостанция).
Контроллеры великолепно питаются от разницы напряжений между землёй и нулевым проводом, резервирование можно акк. от сотового.(замерьте у себя эту халяву) у меня 6V. (цепи step-down и защиты в наличии).Резервирование — бесперебойник + запуск агрегата по необходимости при подтверждении запроса.
Не претендую на истину в последней инстанции, но я вижу концепцию именно так(пока).
0
Вот еще про умный дом smartliving.ru
0
Как я понимаю, дело заглохло? Или проект продолжается? Хотелось бы почитать более подробно. По роду своей деятельности много работаю с современными сигнализациями. Теперь настало время заняться своим домом… Инвайты еще раздаются? :)
0
Там практически сразу движуха заглохла.
0
С другой стороны некоторые модели STM32 всего лишь на 20% (или 1 — 2$) дороже обычных Mega, при этом имея встроенный USB
сомнительное преимущество. ИМХО USB для «умного дома» — зло. Имеет склонность к мертвому зависанию (подумайте что будете делать находясь в отъезде когда все «хозяйство» зависнет или начнет глючить)… Максимум — USB-RS232 на коротком проводе, дальше — обязательная гальваноразвязка…
0
Юра, ты рушиш наши стереотины, не будь так беспощаден. ;)
Так сам ЮСБ «Имеет склонность к мертвому зависанию» в зависимости от его реализации, а если быть точнее, то, от того как программист напишет. А с учетом как извратились в СМТ32, если верить статьям и отзывам, то виновник тут не ЮСБ получается, а реализация ЮСБ в конкретном случае.
Я за всю жизнь не видел ни одного зависания ЮСБ.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.