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

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

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





например, каких? Сделать свою собственную недо-базу данных? nosql? key-value storage?




Гм. Qt - библиотека для С++ (плюс порты под другие языки) для разработки GUI (в основном).

RAD studio - ИДЕ + компилятор языка Delphi + библиотека стандартных компонентов + (в зависимости от варианта) компилятор C++ + (опять же в зависимости от варианта) возможность сборки для IOS / Android. Среда где-то неплохая, но сильно недешевая, а преимущества delphi по сравнению с той же явой или шарпом мне не очевидны.

Сравнивать одно с другим - это как холодильник с телевизором

Давайте к Малине поближе
А то уходим в сторону постоянно.

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

Хоть и опять не совсем о малине, но сей принцип это только частный подход к делу. 100% годится, когда разработчик де факто фрилансер - делает, что и как закажут а сделав, главное забыть о сделанном и сопровождениии навсегда и взяться за следущее "по ТЗ и в срок". В результате в голове, конечно, останется некий опыт, который возможно, сделает разработчика умнее, но может, и как в анекдоте, и "только опытнее" . Нежели-же разарботчик двигает СВОЙ продукт, то выбор инструментов и не только, становится сложнее и ответственнее.

А я бы сказал что SCADА типа AggreGate Building Automation и концепция умного дома это вообще одно и тоже.
Только "умный дом" почему то ломятся делать своим путем, при этом еще на фоне очевидной обреченности в виду участия в гонке монстров типа Google, Apple, IBM и т.д.

И чтобы не отходить от темы:
Очередные 10 абсурдных проектов на Raspberry

Любой из них можно сделать либо на STM32 либо на мини ПК и будет дешевле и функциональней и быстрее.

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

Ну и эти все помянутые ТОЖЕ идут своими путями. Что теперь, всем отальным переквалифицироваться в инсталляторы виндовсов-линуксов-умныхдомов?

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

Вам не повезло с разработчиками, мне везет больше. С 2000 года сотрудничаю с одним из передовых ВУЗов страны МИФИ. Беру в проекты студентов старших курсов и аспирантов. Некоторые работают в штате по 3-5 лет, некоторые уезжают или переходят в крупные предприятия. Самое интересное, что мне удается приглашать в свои крупные проекты даже тех, кто уехал за рубеж, не говоря уже о тех, кто просто перешел в другую компанию. И никто при этом не пытается "двигать СВОЙ продукт", так как это утопия, когда речь идет о проекте масштаба угольного разреза в другой стране. О каких там СВОИХ продуктах может идти речь? Таким проектом будет невозможно управлять и доводить до конечного заданного результата, если каждый разработчик будет двигать свое.

Пару слов о SCADA, раз уж поддался уходу от темы топика. В моих проектах категорически нельзя применять SCADA в качестве основного ПО верхнего уровня, а внизу, ближе к железу можно. ПО верхнего уровня может быть только свое. А причин здесь несколько.
1) Дело в том, что продвинутый Заказчик не ограничивается приобретением по вашей смете только run-time версий SCADA, он потом покупает design-time, чтобы его программисты могли внести изменения при необходимости. Это самое страшное, когда часть системы состоит из твоего ПО и железа, а верхушку изменяет клиент.
2) Экономически выгоднее и безопаснее делать свое ПО, в которое никто не может сунуть нос, чтобы не порушить систему.


Я бы сказал иначе. SCADA и УД также не похожи, как если бы сравнивали RTOS и OS. В первой всё детерминировано по времени и предсказуемо, во второй все плывет и неопределенно. В УД при применении индустриально стандартных интерфейсов, типа RS-485, даже протоколы используются с непредсказуемым результатом. А все просто, пакеты шлются без квитирования, а зачем, без квитанций же экономичнее.

Пытаюсь вернуться к теме топика
Поэтому сочетание SCADA + Raspberry Pi для себя считаю невероятным, а УД + Raspberry Pi очень даже подходящим.

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

а что, квитирование в умном доме официально запрещено какими-то документами ?

Судя по отсутствию там цен, для дома эта штука мало подходит


И какие решения выдали эти монстры? Может быть когда нибудь и будет какая-то стандартная платформа, но пока ее нет

Если под массштабом понимать помянутый Вами "угольный разрез в другой стране", то об АБСОЛЮТНО соираизмеримых массштабах. Ну разве только у меня не один "угольный разрез" а в идеале и переход дальше на корпоративный уровень.

Эти несколько лет НЕ ЕСТЬ срок жизни продукта и не есть срок его сопровождения. Для такого великолепного заказчивка, как "угольный разрез" работа с ним должна продолжаться ВСЮ его жизнь. Основные деньги реально в сервисе, расширении, модернизации, после того, как заказчик ПОДСАЖЕН на ситсему. Так-что "несколько лет" это печальный результат сотрудничества.

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

1) Свое ПО это тоже может и даже должно быть SCADA, только СВОЕЙ.
2) Заказчик волен ставить сколько угодно других SCADA не SCADA подсистем, а я обязан, поскольку чистое белое поле встречается редко, интегрировать в себя (а потом желательно поглотить и заменить ) уже имеющиеся подсистемы. Условие только одно - ВСЕ остальные общаются строго через базу данных МОЕЙ системы. В крайнем случае совершенно автономных систем, например, монторинга горных ударов, им предоставляются только каналы передачи данных.

Абсолютно фантазийное представление о "детерминированости по времени" . Любые жестко детерминированные по времени действия системы возлагаются на локальные контроллеры или группы контроллеров связанных собственными и дублированными каналами передачи данных, а не на какой-то верхний мозг скады. Такова реальность, например, систем обеспечения безопасности производства. Для вырожденных, систем того-же "угольного разреза" действительно жеского реального времени практически не требуется, ну кроме разве что Proximity Alert System и Geofencing.

One_man_show - Я конечно понимаю, что у вас сложились определенные взаимоотношения с вашим заказчиком, и в принципе Вы правы во всем. Единственное, что SCADA, исходя из ее названия - supervisory control and data acquisition - это система диспетчерского контроля и сбора данных. В нее входят такие функции, как отображение и архивирование данных, посты управления - HMI - ведение различных баз данных и трендов, подключение к рабочей системе автоматизации с помощью различных протоколов, если надо - клиент - серверные решения с несколькими серверами для надежности.
По крайней мере у нас так. В итоге типовыми системами, которые мы используем в наших проектах - это Citect Scada в малых проектах, Codra Panorama - в сложных, и e-terrascada - где-то посередине.
Как видите, о самой системе управления тут даже речь не идет - это всего лишь надстройка над ней. Ессно клиенты получают не только run-time, но и сам дизайн, чтобы они могли интегрировать нашу систему в ихний уровень и изменять дизайн HMI. Ну и конечно, SCADA ни в коем случае не используется как инструмент построения систем управления и автоматизации.

В итоге, то что здесь осуждается - это совсем на SCADA, а система автоматизации зданий.
Ну и второе - Raspberry от SCADA очень далеко.

И второй комментарий:
К счастью и на рынке пост-ссср есть компании, которые разрабатывают свои изделия не исходя из ТЗ заказчика, а исходя из ситуации на рынке и возможных требований. При этом их клиентов не интересует, как изделие устроено, если оно выполняет свои функции, надежно, как часы (т.е. что называется - поставил и забыл), и стоит дешевле, чем альтернатива. Причем это касается не каких-нибудь консумерских штучек, а вполне промышленных вещей со сроками службы по 25 лет, индустриальными требованиями, и ответственностью в случае простоя. И для разработки и вывода этих изделий на рынок, как говорится - все средства хороши. И распбери и ардуино. Естественно - подходить к этому надо с умом и опытом. Многие стартапы в этой области накрываются очень быстро по простым причинам - придумали супер девайс на ардуино по супер цене - типа дешевле конкурентов. Предложили крупной фирме - нашему клиенту, которая в миг от нас переметнулась. Да вот не рассчитали с ЭМС и после грозы полетело аж 30% от ихней партии в ремонты. Клиент в шоке, и после пары таких вот пролетов, возвращается к нам, так как у нас не летит. А в стартапе инженеры разлетаются и он закрывается до лучших времен.
А мы себе потихоньку и распберри и ардуино пользуем, только в финальном продукте это все вырождается в промышленные решения. И время экономится не маленькое.

Что вы называете платформой?
Набор гаджетов на странице в броузере с разноцветными кнопочками? Всю эту лабуду на PHP и JavaScript?

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

GUI я и сам в RAD studio за 5 мин сделаю.
Или вот AggreGate предлагает целые мнемосхемы рисовать.

И как я уже писал есть такой фреймворк - https://allseenalliance.org/



Не стоит так утрировать.
Понятие SCADA с самого появления было больше чем просто мониторинг.
В пакеты SCADA всегда входили realtime контроллеры и на PC в том числе.

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

И если б почитали, то AggreGate ставится и на Rasberry и на BeagleBone и на проч. отладочные платы.

Речь про SCADA зашла потому, что SCADA делает все то что делает MajorDoMo и еще лучше.



Да не поверю. Покажите!

Rasberry не имеет никаких толковых интерфейсов. Даже CAN-а не имеет. Каким концом его в промышленности применить?
Даже c Arduino печальный опыт был.
Поскольку IDE этой свистульки не имеет минимальной внутрисхемной отладки, то малейшее недопонимание API библиотек вызывает простои по несколько дней в разработке.

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

Причем если мы об умном доме, то все это должно быть достаточно бюджетно и взаимозаменяемо.

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


Чем лабуда на яваскрипте отличается от лабуды на дельфи?


Это все здорово, вот только аггрегате, я подозреваю, совместим только сам с собой


Вот это уже что-то. Но как я понимаю, пока в зачаточном состоянии


Правда на порядки дороже

Не совсем понятно зачем? Если действительно уже многие годы занимаетесь промышленным оборудованием, то тогда уже всяких СОБСТВЕННЫХ аппаратных платформ должно уже было накопиться немало и уж если от чего-то плясать иробовать, то от них и на них, а не от каих-то "арудинообразных". Когда, как поминаемые Вами "добрым" словом "стартапы", тогда понятно, что железа нет совсем и на чем-то надо реально начинать. Да и то, железо можно-нужно брать, а на API зачем завазываться-то!

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



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



Интерпретацию в среде броузера от компиляции в нативный код платформы отличаете?
Просто я тут недавно с шумом вытеснил решение по автоматизации производства сделанное в виде WEB приложения на PHP и заменил его на нативное сделанное в RAD studio, причем делая его чуть ли не левой ногой.

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


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


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


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


И какие выводы можно сделать из этого факта? На нашем предприятии, к примеру, итерации были такие - php -> delphi -> 1C

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

Нет. Это слова не потребителя. Никогда потребитель не будет интересоваться протоколами, да никто ему про протоколы и не собирается сообщать.
Потребитель будет видеть только сервисы и то не все.

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




Я просто хотел показать как можно проколоться пытаясь следовать трендам. Программер на PHP так и рассуждал, что дескать это же неизбежно, переход на WEB.
Но заводик использует исключительно Windows. А разработка на RAD на порядки проще. И все, он проиграл.
Поэтому для меня главный индикатор это наличие RAD тулсов.
Вот нет у Rassberry инструментов RAD, значит с Rassberry что-то не то.

Проблему лично я сейчас увидел не в том, что "WEB" или "RAD", а в том, что ЛЕПИЛИ что-то под заказчика. Именно лепили, конечно не на пустом месте, а в меру своего предыдущего опыта. Если-бы у каждого из вас был базовый продукт близкий к "коробочному" для решения подобного класса задач, то тогда и можно было говорить о сравнении результатов ПОДХОДА к делу, а не о сравнении "лепнины".

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

Мне не нравится фраза "ЛЕПИЛИ что-то под заказчика", когда тебе предстоит реализовать весь нижний уровень проекта автоматизации горнотранспортного комплекса. При этом, под нижним уровнем понимается установка базовой станции, точек доступа на жд станциях, бортовых комплексов на каждой единице горнотранспортного оборудования, АФУ, учебные классы, учебное оборудование, системы управления МСУ СЦБ, завязать несколько жд станций на диспетчерскую, установить диспетчерский пульт... Все это у тебя на полке в виде коробочного продукта просто не может быть. особенно когда в процессе реализации проекта заказчик вдруг приобретает 12 самосвалов Коматсу и твои бортовые комплексы также приходится на них устанавливать, хотя они были разработаны для электровозов ))) Именно разработаны, а не взяты в виде коробочного продукта, причем все, начиная с корпуса
Нажмите для просмотра прикрепленного файла

Игорь, мне правда, без поддевки, было бы интересно ознакомиться с Вашим опытом в области угольных разрезов, если не затруднит, дайте какие-нибудь ссылки. Причем, мне интересно всё, в том числе, удалось ли Вам изначально правильно посчитать подобные проекты, не просчитавшись с затратами. которые вылезли по мере реализации. У меня, например, ничего не сошлось именно из-за того, что Заказчик постоянно хотел вносить свои изменения. В результате поездок в год оказалось не 2, как рассчитывал, а более 5. К слову, одна поездка обходилась в 300 тыс.р.

Стоп! Вообще-то слово "лепили" относилось в том контексте исключительно к некоему софту сделанному НЕ Вами для какого-то "заводика". Вы-же почему-то сейчас начали разновор
1) О себе
2) О своем железе.

Напишу в личку. Вечером.

Всё! пора в отпуск

ОК, спасибо!

Я вижу в малинке возможность относительно просто создавать свои устройства с полноценным экраном управления.
(либо тач, либо экран с кнопками по краям).
И именно в Win10, поскольку под Win нарисовано компонентов красивых на порядок больше чем под остальные оси.
Вот нужен мне красивый реал-тайм график. Со всякими модными зумами, красявостями и т.п. Под вин он есть. Под линукс нету.

Еще я вижу в ней относительную простоту сопряжения с низкоуровневыми устройствами.

Вот сейчас есть проект установки, пока кстати выбрали за основу именно J1900. В нем есть несколько тупых исполнительных модулей (из серии PIC18), которыми надо управлять. Как сопрячь их с X86? Ставить плату расширения на кучку RS-232/485?

Дык там очень мало периферии

Еще одно мнение по поводу почему Распберри и Ардуино отличаются от других отладочных плат или в чем их специфика:
Распберри, в отличии от отладочной платы - это как бы реклама. Реклама того, что на нем можно сделать. Т.е. с учетом всех сайтов, приложений и шильдов можно легко найти ответы на вопросы - "А это можно сделать? А вот это? А как это сделать?" - причем в виде примеров и роликов на ютуб. Т.е. человек, покупая распбери, уже знает точно, что на нем можно реализовать, и даже во многих случаях - как. Ведь в 95% случаев нужно просто повторить какое либо решение, а не изобретать новое с нуля. И в оставшихся 5% - немного допилить.

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

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

Наивное заблуждение.
Вся эта ветка свидетельствует об обратном.
Подавляющее большинство проектов Raspberry базируется на самых общих сервисах операционной системы Линукс.
На сетевом стеке, WEB-е, файловой системе, кое каким оконным фреймворкам, и несчастном интерфейсе камеры.
Полное копирование возможностей обычного мини ПК только все урезанное,менее надежное(особенно файловая система) и более медленное.
А далее идет отсылка к линуксовому софту где якобы все можно найти.
Но вот как раз на выяснение что будет там работать, а что нет и что допилить уйдут годы.

Это же просто понты гиков, которые сначала промучились пару лет пока въехали в отдельные пакеты линукса, а потом заявляют, что сделали все за пару минут.
Я открываю какой нибудь опенсорс типа Apache WEB сервер под Pasberry и понимаю, что любого гика решившего это использовать во встраиваемом дивайсе для работы с железом я обгоню с обычным lwIP на STM32.
Причем гик поставив lwIP на Raspberry уроется еще сильней.

Понимаете, годы иногда уходят совсем не на то, что кажется поначалу. Например, очень часто оказывается, что надо вбухать годы в спецификацию или ТЗ, чтобы потом не вбухивать их же(или еще больше) в разработку и тестирование непонятно чего.
Опять же знать все невозможно - я,например, знаю в линуксе только пару команд, а lwIP - тем более темный лес. Но я знаю чего я хочу. Поэтому я запущу макет на Raspberry за вполне определенное время без этих знаний, а потом приду к AlexandrY или другому такому же спецу и скажу "Сделай мне такое же, только на STM32 и чтобы надежно работало". И сделают. И за вполне определенное время. И не сомневаюсь, что во время разработки вы еще десять раз заглянете в исходники Raspberry чтобы посмотреть "а как же там это сделано?". А еще у инженера не будет отмазки по срокам из-за того, что типа не влезло или вообще невозможно реализовать - так вот же есть пример и он работает!

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

1. Есть известная робототехническая платформа REEM-C, представляющая собой человекоподобного двуногого робота.
Нажмите для просмотра прикрепленного файла
Эта платформа очень популярна, и многие Университеты Мира покупают или арендуют эту платформу для проведения своих исследований. Например, недавно Technische Universitдt Mьnchen получил этого робота для проведения своих исследований в Institute for Cognitive Systems.
Специально привожу все ссылки, чтобы было понятно, что это не "детский сад". Хотя, уверен, найдутся собеседники, для которых это не показатель.

2. Если обратить внимание на параметры платформы, увидим, что она выполнена на 100% на основе фреймворка ROS (Robot Operating System). Не буду утомлять примерами других платформ на основе этой ОС, изучив сайт, можно найти множество известных решений, от простых трехколесных тележек, до шагающих с продвинутыми манипуляторами.

3. Заглянув в недра ROS, например, в раздел библиотек для последовательных интерфейсов, которые используются для связи с внешним миром, можно увидеть три популярных для робототехники клиента с точки зрения интерфейса: Arduino, EmbeddedLinux и Windows.
Прошу прощения, тема конечно же про Raspberry, но здесь мы касаемся сразу нескольких трендов, так что пример с Ардуино, на мой взгляд, показателен.

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

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

Ух ты! Классно. А это только у распберри такая уникальная способность - "я ничего не знаю, кроме 2х команд, а сделал и теперь все используют как пример и смотрят как делать".
А если я CPLD не знаю? Или еще чего, тоже смогу?
Надо полагать raspberry в этом уникален. Во всяком случае у меня никогда не получалось ничего сделать, не понимая как это работает.

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

Ну и понятное дело объяснить что надо делать на СТМ32 пока это ни сделано на распберри нет никакой возможности.
Чудесная система, просто чудесная!
Дайте две!

Честно говоря, мне пофиг у кого или чего есть уникальные способности. На сегодняшний день я пришел к такому нехорошему выводу, что эффективность инженера, конечное качество продукта, сроки разработки и т.д. напрямую зависят от ... умения гуглить.
Реально, люди, не умея искать в сети, начинают выдумывать что-то свое, или еще хуже - биться об стенку, хотя в большинстве случаев это уже давно кем-то придумано. Сколько часов отладки было похерено моими программистами, когда они получали "Fatal Exception..." или что-то похожее, пока я не заставил их гуглить.
Вот и с распберри такая ситуация. Погуглил - посмотрел как сделано - сэкономил кучу часов. Если какая-то проблема - вопрос на форуме - решение.

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


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


Почему нету? Берите яву и пишите для расбери. Тулов под яву вагон. Или берите плюсы, тулов тоже вагон

... И?
Какое это имеет отношение специфически к Raspberry PI?

В RAD Studio есть очень давно MIDAS, это то что связывает мини ПК под Windows в системах управления.
Недавно там появился App Tethering. Это то на чем делают видеостриминг на андроиде и прочие интересности.

Покажите мне аналоги этих технологий в среде такой же мощной IDE как RAD Studio, с отладкой, такими же гибкими логами, подключениями к базам данных с такой же быстротой как FireDAC.
QT не предлагать. Eclipse тоже. Ввиду их низкого уровня.
Языки типа "Беритеяву" тоже не предлагать, языки без IDE и фреймворка не имеют никакого значения. Либо конкретно назовите фреймворки.



Честно говоря с большим трудом понимаю зачем нужен ROS. А уж клиенты под ROS вообще темное дело.

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

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

Озвучивает механизм мультипликации дерьма из интернету

Я стесняюсь спросить - вы на все эти продукты покупали лицензию? Во сколько она вам обошлась? Чисто, чтобы сравнить с явой в этом контексте.

Российские вантузятники не знают, что такое лицензия. Им пофиг. Торренты же есть!

$5/девайс

Я на Pi2 Астериск запустил, 5 абонов живут и смски клиентам отправляет после звонка оператора.
Не шумит, не гудит и не греется. За 2500 рублей и 250 рублей за корпус - доволен как слон.

Я тож купил, но ничего покка не делал, просто залил RASPBIAN и к телеку подключил, чтоб просто работоспособность проверить

Вот тут есть какие-то проекты:
http://hackaday.com/category/raspberry-pi-2/

А что Вы с ним/из него сделали?

A FXO и FXS как сделали?


Я заменил на расбери управление в радиоуправляемой машинке, подключил камеру и WiFi. Написал простенькую апликацию на андроиде, для использования экрана телефона в роли джойстика. А к большому экрану (отдельный компьютер) подходит видео от камеры. Теперь могу симулировать луноход.
Правда уже год валяется и не знаю что с этим дальше делать

пошла рскрутка Raspberry Pi Zero. 5$ и вырезаны куча интерфейсов.
так и не придумал куда применить Raspberry Pi обычный, теперь еще больше недоумеваю куда применить новый Raspberry Pi Zero

билд серверы делать на зеро

Такое впечатление, что нужно залежалые АРМ11 куда-то слить по любой цене...

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

Дак в этой плате даже сети нет! Вся прелесть только цена, НО цена в 5 баксов - это только "у них", наши смело в 2 раза накрутят+ транспортные...

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