Да, интересные размышления, правда я не совсем согласен.
Ты описываешь ситуацию, когда маркетолог или продавец начинает программить МК используя Arduino не понимая того, что происходит вокруг микроконтроллера (да и наверное в самом микроконтроллере).
А вот если радио электронщик начинает изучение программирования с Arduino — помойму не так уж плохо :) Шансов создать работающее решение гораздо больше.
Может и так, хотя в Европе мне кажется такие фокусы не проходят.
Сам по себе чип прошел сертификацию FCC и CE
Вы про Silverlight, про Script#, или про In-browser WPF? Сори, они все умерли.
Эти, да умерли. А вот ASP.NET реинкарнировался в ASP.NET Core 1.0, ушел в OpenSourse и портировался на Linux.
Ну и Xamarin теперь стал частью Microsoft, так что с кроссплатформенностью все в порядке. У тебя в этом сценарии нужно иметь 3 группы разработчиков (Embedded\Web\Client), которыми ты покрываешь разработку прошивки, бекенд для Windows\Linux, Толстый клиент для Windows 10 (Phone, PC, Tablet, Xbox, Hololense) + Android + iOS.
При этом все 3 группы работают на одном языке программирования. Чем плохо ?
Нет, бесплатен.
Так вот в чем корень зла :)
ОК, попробую связку netmf + штатный бутлоудер.
У тебя есть защита самого чипа от чтения прошивки.
Дока
Давайте посмотрим сюда: Дока 2
п.3.11 — Включение Read Out Protect, после чего чтение FLASH становится невозможно.
п.3.12 — Выключение Read Out Protect, в этом случае FLASH стирается, и потом включается чтение (пустого FLASH)
Иными словами, после того, как ты включил Read Out Protect, вариантов стырить прошивку путем подключения к UART — нет.
Что касается обновления по воздуху:
Прежде чем отдать чип клиенту, включаем Read Out Protect
Теперь задача, защитить прошивку от перехвата. Реализуется например HTTPS протоколом обмена данными между сервером и микроконтроллером.
Перехватить ее даже между GSM модулем и микроконтроллером нельзя, т.к. трафик расшифровывается непосредственно в микроконтроллере.
Файл с новой прошивкой попадает в девайс, девайс бутается с новой прошивкой.
Или я чего-то не понимаю, или мы о разных вещах говорим.
Если ты про защиту прошивки, например от кражи, то она обеспечивается по другому, на уровне микроконтроллера.
А что касается обновления по воздуху, описанные тобою проблемы релевантные только для процесса скачивания новой версии прошивки. Тут ключевой момент, наличие свободной памяти для закачки файла с новым firmware. Целостность скачиваемой информации можно контролить например чек сумами.
На самом деле, тип транспорта для доставки прошивки может быть любым, но опять таки, контроль целостности закачиваемого файла на тебе.
А уж если новая прошивка была закачана полностью, то и обновится должна без проблем не зависимо от того, есть ли связь с внешним миром, или нет. Для обновления firmware в Netmf есть специальный класс MFFirmwareUpdate.
на .net я бы ни за какие деньги не взялся его писать ))
Так и не надо, он написан. Бутлоудер передает управление netmf, который запускает приложения.
Причем есть 2 варианта: использовать boot loader, который написан Microsoft-ом, или тот, который поставляется вместе с чипами от STM.
Например в STM32F1 с целью экономии памяти, используется встроенный bootloader.
На сервере чето збойнуло, залил новый код и все поехало. А если промахнулся в прошивке в девайсе, то отзыв партии на сервисное обслуживание, перепрошивка и отправка обратно заказчику. А если со схемотехникой промахнулся — вообще печаль...
Вот по этому рисковая.
Минорная она в контесте затрачиваемых ресурсов на проектирование этого самого харда (получение первого работающего прототипа). Чаще всего, больше ресурсов уходит на создание бэкенда для этого харда.
Если у тебя есть обратные примеры, приводи.
Ну там датчики тоже есть в списке (в разделе Other Hardware Peripherals -> Sensors), в частности и 11й и 22й, со ссылками на примеры.
Проверяют там правильно на правильных Rohde&Schwarz-ах, в безэховой камере и т.д. (это тоже из личного опыта)
Неа, не уверены. Я тебе больше скажу, даже если ты покупаешь китайский GSM модуль, типа сертифицированный, то не факт, что он действительно прошел сертификацию.
Вот эти штуки построены на базе ESP8266, вроде как в Европе продаются.
К стати, Rohde&Schwarz наш партнер в лаборатории, даже мастеркласс на эту тему читали, как раз таки и рассказывали про их оборудование, кое что даже показывали.
Реле — странный пример, его можно решить вообще чем угодно, хоть аналоговой схемой.
А Ethernet в примере с реле тоже в аналоге сделаешь? Тут основной затык с удаленным управлением. Мы же про IoT сценарии говорим.
Датчики отпечатков пальцев по всей стране — 10% работы над датчиками
Так а во многих IoT хардвар кодинг — это и есть 10%. Мы же не осцилограф делаем. В этом то как раз тема: действительно, набрал готовых датчиков или вообще какой-то OEM девайс готовый, нашел програмера, который не вникая в особенности микроконтроллера на C#\Java изобразил тебе код и вопрос закрыт. А уж на сервере да, надо постараться. Инновация может лежать только в плоскисти серверного бэкенда. Аналитика, машинное обучение и прочее.
Хард — это минорная часть IoT, но самая рисковая. На сервере чето збойнуло, залил новый код и все поехало. А если промахнулся в прошивке в девайсе, то отзыв партии на сервисное обслуживание, перепрошивка и отправка обратно заказчику. А если со схемотехникой промахнулся — вообще печаль... Чем больше ты берешь готовых модулей под свое устройство, тем проще и дешевле тебе обойдется его производство.
Хотя если брать какие-то большие производственные комплексы, типа сталелитейных заводов (навеяло недавним визитом в одно из таких предприятий), там и запросы другие, т.к. специфика харда другая, там китайскими модулями не отделаешься. Схемотехнический хардкор :)
А со спецом, опять таки, смотря какого ищешь. .Net\Java — коих 70% среди всех, или C\C++ под STM платформу.
Вообще, эту статью я писал дабы на нее ссылаться в последующих статьях. Так сказать «для тех, кто не в теме».
Сейчас, кстати, есть ещё вещи наподобии esp8266
Крутая вещь. Из всех продуктов для IoT ее на первое место ставлю.
А прежде чем писать «булшит», посмотреть слабо?
Codeplex,
netmf toolbox,
netmf toolbox
Тебе под что конкретно библиотека нужна?
Ну и в конце концов, если используешь что-то экзотическое, у тя есть SPI, UART, I2C, ADC\DAC, PWM на уровне библиотек самого фреймворка. Я ж писал, было дело не нашел подходящей библиотеки для SIM900 модуля (вернее она была, но не понравилась), ну ничего, такое бывает, иногда надо и самому че-то изобразить.
Ну и уж совсем на худой конец — netmf бесплатен и с открытым кодом, равно как и Arduino, библиотеки от которой тоже приходится дотачивать, убирать лишнее. Это жизнь.
Я тоже так думал, пока не увидел, как чуваки Arduino nano не вставляют в девайс и не продают это в красивой коробке.
Какая разница твоему клиенту, что там внутри. Главное, чтоб работало.
А какой смысл использовать JAVA\.NET на Linux\Windows? Ведь есть же C++ и там и там?
Ты ж про температурный датчик спрашивал :)
Подожди... А в чем обман? Обман — это если ты заявил набор функций, а их в устройстве нет.
А если твое устройство делает то, что ты обещаешь, то в чем вопрос?
А по поводу
и — так можно написать код моргания светодиода, смонтировать все на маленькую платку и продавать на разных ивентах с логотипами организаторов, или в аэропорту, приезжим туристам в корпусе «I Love Kiev», или на собачий ошейник вешать, чтоб в темноте видно было, или в темном лесу световые маячки ставить, на велосипед в заднюю фару. И в какой-то момент ты становишся монополистом на локальном рынке продуктов, которые моргают и нещадно убываешь конкурентов демпингуя за счет объемов :) Чем не бизнес? Убогий, но зато работает :)))Ценность программы (хотя я бы тут говорил про продукт) определяет спрос на нее.
А у стартапов нет проблем создать что-то качественное и полезное. Они потом не могут это монетизировать, и причин тут много: отсутствие цели и стратегии, незнание реальных проблем заказчиков, неумение донести value proposition, отсутствие связей и контактов и т.д.
Потому мы занимаемся тем, что у нас получается лучше (это я про страну в целом): развиваем техническую экспертизу и продаем ее зарубежным заказчикам, а не создаем собственные продукты и продаем их. Конечно, есть ряд весьма успешных ISV, но они выжили только потому, что не боялись рисковать и четко понимали кому и как продавать свое решение.
Но возвращаясь к IoT: прелесть в том, что вместе с железом, ты продаешь и сервис (подписку), а соответственно от каждого проданного устройства получаешь регулярный доход. Таким образом, закрывая узкую проблему в определенной индустрии ты обеспечиваешь себе постоянный доход, а не доход от разовой продажи железа.
А вот то, сколько стоит твой сервис, зависит от того, какие данные ты предоставляешь. И может оказаться, что обработанные данные и построенные на их основе прогнозы стоят дороже, чем проданное железо.