Комментарии 54
Закопайте стюардессу. Ее уже все бросили.
По объективным причинам.
По объективным причинам.
По каким причинам?
Достаточно того, что это интерпретатор байт кода.
В огромном минусе скорость (десятки раз) и, как ни ужимайся, по объемам тоже все равно проиграешь.
В огромном минусе скорость (десятки раз) и, как ни ужимайся, по объемам тоже все равно проиграешь.
MicroPython тоже байткод и тоже немало кушает — но его почему-то никто не хочет закапывать.
Во-первых меньше, а во-вторых и главных — он немного в другой лиге — для скриптовых простых задач, а никак не для реалтаймовых приложений.
Хотя может, это я много требую от С#?
Хотя может, это я много требую от С#?
Не особо меньше — и то и то влезает в 256K ROM, разве что питону достаточно 16K RAM (nano нужно 64K). Но вообще-то никто в здравом уме не будет использовать байт-код и рантайм для рилтайма (в том числе на питоне), самое критичное выводится либо на уровень ОС либо в собственно рантайм.
Впрочем, рилтайм бывает разный — если у нас что-то происходит не чаще чем 10 раз в секунду, да даже 100 (на более продвинутых устройствах) — очень вероятно что на это хватит и интерпретатора, а в "бытовом" IoT вряд ли это нужно чаще.
Так что nano.Net имеет точно такое же право на жизнь как и MicroPython.
Вы к курсе что на смарт-картах (sim карты для телефонов, банковских карты) используется java? Пруф Java Card Platform. Если верить на слово oracle, в настоящее время поставляется более 2 миллиардов устройств с java кодом в год. И Ваш аргумент скорости тоже несостоятелен. Если человек возьмет в руки профессиональный фотоаппарат, это вовсе не означает что каждый его снимок будет шедевром. Можно и на C++ сделать программу, которая будет работать медленнее чем на Visual Basic. Как было в тексте сказано, эталонная реализация .NET nanoFramework работает поверх ОС реального времени ChibiOS. Если сравнивать ChibiOS с FreeRTOS, то у FreeRTOS время отклика до 10 раз больше в сравнение с ChibiOS. Разработчики ChibiOS не даром едят свой хлеб. Поэтому не факт, что время отклика на событие, на одном и том же микроконтроллере, кода С++ будет меньше, чем кода на C# в связке .NET nanoFramework+ChibiOS, либо оно будет несущественным.
Много слов, а лучше предъявлять цифры. Время переключения ОС отличается от времени прикладной программы на пару порядков.
Если посмотреть на свою же ссылку, то 50% Симок с Явой было 10лет назад. АФАИК тема эмбеддед Явы последовательно загибается.
Если посмотреть на свою же ссылку, то 50% Симок с Явой было 10лет назад. АФАИК тема эмбеддед Явы последовательно загибается.
У Вас как то тоже нет цифр. Если возьму STM32NUCLEO-F091RC, то обязательно найду где достать профессиональный осциллограф, и сделаю все возможные тесты на отклик и скорость, с .NET и без него.
Да конечно, Java загибается, прям умерла навсегда, вот почитайте про microej. Пример Hello World на MicroEJ с выводом на LCD. Siemargl, почаще пользуйтесь гугл поиском.
Да конечно, Java загибается, прям умерла навсегда, вот почитайте про microej. Пример Hello World на MicroEJ с выводом на LCD. Siemargl, почаще пользуйтесь гугл поиском.
Вероятно, я слишком резко зашел =)
Можно для начала без осциллографа, просто засечь время цикла опроса периферии с какой либо типовой математикой, вроде расчета скользящего среднего для АЦП.
Про Яву же, я видел где то оф.рекомендацию вместо JavaME использовать JavaSE for Embedded а потом уже и бум, и ее выгнали на опенсорс (тоже дохлый реп).
Собственно Java ME тоже скончалась.
Пример неживого репозитория microej я не приму всерьез.
Можно для начала без осциллографа, просто засечь время цикла опроса периферии с какой либо типовой математикой, вроде расчета скользящего среднего для АЦП.
Про Яву же, я видел где то оф.рекомендацию вместо JavaME использовать JavaSE for Embedded а потом уже и бум, и ее выгнали на опенсорс (тоже дохлый реп).
Oracle Java SE 8 Embedded is the final major release of the Oracle Java SE Embedded product. Starting with JDK 9, Oracle doesn't plan to offer a separate Java SE Embedded product download. Java SE 8 Embedded is now on restricted availability intended for existing embedded support customers only.
Собственно Java ME тоже скончалась.
As of December 22, 2006, the Java ME source code is licensed under the GNU General Public License, and is released under the project name phoneME.....PhoneME project page (original website, currently shut down
Пример неживого репозитория microej я не приму всерьез.
Раз Вы так разбираетесь в этой теме, и скорее всего у вас есть соответствующее оборудование, то оставлю Вам возможность сделать тесты и написать разгромный пост о низкой скорости работы .NET nanoFramework. Тем более что ESP32 стоит недорого, всего 6$. Вот и посмотрим способны ли Вы публиковать что-то кроме комментариев про стюардесс.
Опубликую продолжение темы, как устанавливать и программировать на .NET nanoFramework. А потом будем ждать от Вас «разгромного» поста о .NET nanoFramework.
Опубликую продолжение темы, как устанавливать и программировать на .NET nanoFramework. А потом будем ждать от Вас «разгромного» поста о .NET nanoFramework.
А вы вкурсе насолько обрезана кард платформ по сравнению со "взрослой" явой? Вообще это скорее аргумент в пользу вашего оппонента.
Да ладно. Про это в публикации сказано, если вы внимательно читали. Нет у него никакого аргумента. Аргумент вида:
Признак недалекого мышления. Свою позицию необходимо предельно четко изъяснять. По поводу «обрезанности» не путайте целеполагание платформы. Вы же в мышку Raspberry Pi пихать не будете, не смотря на большие возможности, скорее всего возьмете небольшой недорогой микроконтроллер в задачи которого будут входить снятие показаний с датчиков и передача данных по USB или беспроводному каналу.
Еще раз повторю, центральный смысл публикации и мое мнение: приход Runtime исполнения кода на микроконтроллере неизбежен и будет преобладающим. nanoFramework, .NET Micro Framework, MicroEJ, это все реализации. У кого-то взлетит, у кого-то нет, такое бывает. GHI Electronics мне шлет инсайдерские материалы, они готовят весьма существенное расширение своих решений, которое будет доступно публике через месяц. Siemargl может трижды писать про стюардесс и пингвинов, но продукцию GHI Electronics покупают и компания растет, и это является доказательством, есть спрос есть и предложение. Причем решения GHI Electronics используют в промышленности, OrgPal.Iot в нефтедобычи.
Я разговаривал с так называемыми «экспертами», которые плевались от Arduino. Поделюсь выдержкой «экспертов» по поводу прихода Windows, взамен DOS.
Закопайте стюардессу. Ее уже все бросили.
По объективным причинам.
Признак недалекого мышления. Свою позицию необходимо предельно четко изъяснять. По поводу «обрезанности» не путайте целеполагание платформы. Вы же в мышку Raspberry Pi пихать не будете, не смотря на большие возможности, скорее всего возьмете небольшой недорогой микроконтроллер в задачи которого будут входить снятие показаний с датчиков и передача данных по USB или беспроводному каналу.
Еще раз повторю, центральный смысл публикации и мое мнение: приход Runtime исполнения кода на микроконтроллере неизбежен и будет преобладающим. nanoFramework, .NET Micro Framework, MicroEJ, это все реализации. У кого-то взлетит, у кого-то нет, такое бывает. GHI Electronics мне шлет инсайдерские материалы, они готовят весьма существенное расширение своих решений, которое будет доступно публике через месяц. Siemargl может трижды писать про стюардесс и пингвинов, но продукцию GHI Electronics покупают и компания растет, и это является доказательством, есть спрос есть и предложение. Причем решения GHI Electronics используют в промышленности, OrgPal.Iot в нефтедобычи.
Я разговаривал с так называемыми «экспертами», которые плевались от Arduino. Поделюсь выдержкой «экспертов» по поводу прихода Windows, взамен DOS.
Кренкель Т. Э. ‚ Коган А. Г., Тараторин А, Н. Персональные ЭВМ в инженерной практике.‚ 1992 год. стр. 166-168
После того, как Оракл и Майкрософт перестали развивать свои эмбеддед платформы, как раз признаком недалекого мышления является заявление =)
Пользователи то у таких платформ будут — удобно же для домашней автоматики например, но серьезные пользователи — сомневаюсь.
приход Runtime исполнения кода на микроконтроллере неизбежен и будет преобладающим
Пользователи то у таких платформ будут — удобно же для домашней автоматики например, но серьезные пользователи — сомневаюсь.
Приводить в пример Oracle и Microsoft, в данном случае и других не очень уместно. Тот же самый Microsoft пропустил развитие Internet и переход на мобильные устройства. Свой Windows Mobile просто взял и слил. Причин почему они перестали развивать может быть масса и это не является критерием. Возможно потому что решили полностью переходить в облака, может быть были другие веские причины. Прекращение развития не свидетельствует о бесперспективности дальнейшего развития. Если бы вы внимательно почитали англоязычные материалы, о обратили бы внимание на большое разочарование сообщества на прекращение развития .NET Micro Framework. Было много продолжателей .NET Micro Framework, и только .NET nanoFramework вышел в свет. К аргументу, что .NET Micro Framework никому не интересен.
Если под серьезными пользователями подразумевается промышленное производство, то они и сейчас активно используют nano/micro, примеры приведены. Непонятно о каких «серьезных пользователях» идет речь?
Еще раз повторюсь, критерием истины для меня является наличие прибыли. Компания GHI Electronics на .NET Micro Framework зарабатывает хорошие деньги, а значит есть спрос. Вот с этим аргументом точно никак не поспорите, хоть головой бейтесь. Мало того, GHI Electronics работает в этом направление более 10 лет, с каждым годом только расширяет номенклатуру и улучшает характеристики.
Если под серьезными пользователями подразумевается промышленное производство, то они и сейчас активно используют nano/micro, примеры приведены. Непонятно о каких «серьезных пользователях» идет речь?
Еще раз повторюсь, критерием истины для меня является наличие прибыли. Компания GHI Electronics на .NET Micro Framework зарабатывает хорошие деньги, а значит есть спрос. Вот с этим аргументом точно никак не поспорите, хоть головой бейтесь. Мало того, GHI Electronics работает в этом направление более 10 лет, с каждым годом только расширяет номенклатуру и улучшает характеристики.
Кстати, если посмотреть на сайте GHI Electronics, то там написано
Кроме того, одна небольшая компания — совсем не показатель направления развития отрасли =)
.NET Micro Framework...Not recommended for new designs, replaced by SITCore. and TinyCLR OS.
Кроме того, одна небольшая компания — совсем не показатель направления развития отрасли =)
А вы внимательно посмотрели страницу? Этот текст относится к Visual Studio 2013 NETMF 4.3. Понятно дело GHI Electronics продолжил развивать .NET Micro Framework, после прекращения поддержки Microsoft. И теперь у GHI Electronics два CLR для разных МК: SITCore и TinyCLR OS.
На этой же странице:
То что GHI Electronics небольшая компания, у вас нет никаких аргументов. Потому что нет данных о выручке и объема продаж. Давая оценку «небольшая», скажите критерии большой и небольшой компании. Тем более GHI Electronics не одна, а как же OrgPal.Iot?
На этой же странице:
.NET Micro Framework (NETMF) is a subset of the full .NET Framework. This framework is no longer active — it’s been replaced by the more modern and more secure TinyCLR OS.
То что GHI Electronics небольшая компания, у вас нет никаких аргументов. Потому что нет данных о выручке и объема продаж. Давая оценку «небольшая», скажите критерии большой и небольшой компании. Тем более GHI Electronics не одна, а как же OrgPal.Iot?
Есть контроллеры с аппаратным сопроцессором для джавы, значит можно и для .net сделать. Вопрос массовости
Нету. Вымерли.
Ну допустим, а что мешает сделать микроконтроллер целиком на .net байт коде? Я так понимаю, даже любитель может отработать его на плис и потом заказать шатлом. Если подключится майкрософт, для них это вообще не проблема.
Я понимаю, что гораздо проще научить компилятор создавать нативный код для микроконтроллеров, как он умеет это сейчас для x86/x64/ARM, но чисто теоретически
Я понимаю, что гораздо проще научить компилятор создавать нативный код для микроконтроллеров, как он умеет это сейчас для x86/x64/ARM, но чисто теоретически
В списке поддерживаемых платформ указано AVR, но что-то я не могу найти какие именно устройства? Не ткнёте носом в ссылку?
На AVR работает ChibiOS/RT, порта .NET nanoFramework пока нету. И скорее всего, не будет т.к. нецелесообразно. Принципиальный плюс ARM по сравнению AVR, заключается в наличие отдельного блока обработки сигналов GPIO, который независим от основного потока вычислений. Даже если на ARM загрузить вычислительный блок на 100%, то значения сигналов с GPIO не будут теряться, они будут складываться в буфер и ожидать когда их считают, или просто переполнится буфер. .NET nanoFramework и .NET Micro Framework используют в промышленном производстве, где такое недопустимо.
Принципиальный плюс ARM по сравнению AVR, заключается в наличие отдельного блока обработки сигналов GPIO, который независим от основного потока вычислений. Даже если на ARM загрузить вычислительный блок на 100%, то значения сигналов с GPIO не будут теряться, они будут складываться в буфер и ожидать когда их считают, или просто переполнится буфер.
Очень интересно. За многие годы работы с ARM с таким не сталкивался. Не подскажете где можно почитать про это для ядер Cortex M0/M3/M4?
в промышленном производстве, где такое недопустимо
Недопустимо то, что значения сигналов с GPIO копятся в буфере? Значит в промышленном производстве ARM не используются?
Я бы тоже почитал, где это в cortex m0-3 есть буфер для gpio?
Спасибо за обзор. Была бы интересная штука для моего минипроектика, наСилия там много, столько времени нет, а Lua и Питончик — не самый лучший вариант. Но, к сожалению, не нашел, может ли связку «Mono + Linux» в качестве среды разработки…
Можно. Но только не в качестве среды разработки, а среды исполнения. Разработка будет в Visual Studio Code в Windows, отладка по сети TCP/IP в интерактивном режиме. Платформа .NET, проект dotnet/iot, позволяет запускать код C# на одноплатных компьютерах ARM с Linux. Можно получать доступ к периферии GPIO in/out, шине I2C для работы с датчиками и другими устройствами, и т.д. Причем это не только Raspberry Pi, а и другие платы, например Banana Pi BPI-M64 с SoC Allwinner 64 Bit Quad Core ARM Cortex-A53, можно выбрать и любую другую плату из каталога armbian.com/download/. Сейчас готовлю публикацию, как работать с GPIO используя C# на плате Banana Pi BPI-M64 (Armbian/Linux). Предварительно, если интересно, можно настроить среду разработки и инструменты, как в публикации Удаленная отладка приложения на .NET 5.0 в Visual Studio Code для ARM на примере Banana Pi BPI-M64 и Cubietruck (Armbian, Linux) . И Docker, если собираетесь запускать .NET 5 код в контейнерах.
Спасибо за ответ, к сожалению, меня интересовала именно возможность разработки. Честно, почти с шарпом не работал, так простенькие парсеры / панели управления для отладки железа делал. Как раз, использовал Mono. С консольными вещами — вообще без проблем, с GUI, да, не совсем красиво, GTK. Эх, мечтал бы о такой штуке. Корка заливается на ESP32 однократно, а прикладные программы — по сети, плюс отладка… И, простите за наглость, все равно была бы очень интересна статься, как с 0 до небольшого web сервера ESPшку, например, поднять.
P.S. Да, про скорость — понятное дело, медленней, чем на Си, но иногда цена не так важна для POC, а скорость и удобства разработки выходят на первое место.
P.S. Да, про скорость — понятное дело, медленней, чем на Си, но иногда цена не так важна для POC, а скорость и удобства разработки выходят на первое место.
Погодите, когда C#-приложение устанавливается на обычный компьютер происходит какая-то «оптимизация» под данный процессор.
Возможно компилятор для ESP32 генерирует достаточно оптимальный управляемый C# код, который быстрее Lua/Python и безопаснее голого C?
Возможно компилятор для ESP32 генерирует достаточно оптимальный управляемый C# код, который быстрее Lua/Python и безопаснее голого C?
«управляемый код на C#» — терминология .NET платформы. Управляемый код создается на C#, F#, и т.д. Он работает поверх CLR, который обеспечивает проверку ссылок, контроль указателей, сборку мусора и многое другое. Неуправляемый код на C или C++, компилируется непосредственно в машинный код и исполняется ОС. Безусловно с этой точки зрения код на C# более безопасный, т.к. все операции проверяются CLR, и что то «поломать » в системе просто невозможно. Почитать подробнее на METANIT.COM.
Поясняющая схема
Для нормальной среды используется NGEN. Практически компиляция.
Для nano/micro фреймворков такого нет.
Для nano/micro фреймворков такого нет.
Сейчас готовлю публикацию, как работать с GPIO используя C# на плате Banana Pi BPI-M64
спасибо, очень жду. У меня Banana PI M3 и нет вышеописанных мк, которые по моим меркам невероятно мощные (есть атмеги 328 и стм 103)
Для работы с GPIO на C# вот публикация https://habr.com/ru/company/vdsina/blog/555598/
А так для автоматизации разработки .NET приложений в Linux для ARM почти закончил плагин к Visual Studio Code. Хочу что бы все работало и крутилось не выходя за пределы VSCode, как на Arduino. Все должно быть - Freakin' Easy!
GHI Electronics развивает свою TINYCLR OS, в партнерах nano Framework не значится
Меня как то смущает, что RS 482 устаревший интерфейс, а CAN лучше… Не могу понять в чем?) Или это в оторванной среде МК, вместо ПЛК? Сразу куча вопросов — вот указано применение для нефтянки — а где сертификация МК в РФ, например? Ну и чем это лучше стандартов МЭК?
Из публикации уберу данное утверждение, т.к. выходит за пределы основной тематики и не совсем корректно. Не берусь утверждать про истину в последней инстанции, мнение основано на одной из публикаций CAN против RS 485: почему тенденция направлена в сторону CAN
Про соответствие какого конкретно стандарта Вы говорите? Решения OrgPal.Iot работают на
нефтяных месторождениях в Северной Америке, про Россию не идет речь.
Устройство PalThree сертифицированно как совместимое с Azure IoT. т.е. обмен данными с ажуром, эта железка делает без проблем и ошибок. Это не сертификация промышленного оборудования в соответствие с мировыми стандартами ISO или другими. Сотрудники Microsoft протестировали работу PalThree с ажуром и подтвердили прохождение всех тестов совместимости, по результату выдали серификат.
Про соответствие какого конкретно стандарта Вы говорите? Решения OrgPal.Iot работают на
нефтяных месторождениях в Северной Америке, про Россию не идет речь.
Устройство PalThree сертифицированно как совместимое с Azure IoT. т.е. обмен данными с ажуром, эта железка делает без проблем и ошибок. Это не сертификация промышленного оборудования в соответствие с мировыми стандартами ISO или другими. Сотрудники Microsoft протестировали работу PalThree с ажуром и подтвердили прохождение всех тестов совместимости, по результату выдали серификат.
Оно крутое. Но в мелкой серии, системы с 256кб на борту по стоимости граничат с уже линукс бордами, без геморроя и страха о малом комьюнити и LTS.
Ведь по факту там не 256 а все 512 надо. Что бы это все имело смысл.
Есть места где это охрененно можно применить, сам хожу вокруг да около, да вот стремно…
1) Какая версия .NET может использоваться в рамках проекта под .NET nanoFramework? Т.е. можно ли использовать .NET5 / C# 9.0?
2) Я так понимаю, Microsoft не имеет никакого отношения к .NET nanoFramework, верно? Если так, то есть ли у Microsoft работоспособные/перспективные альтернативы?
Не пинайте если вопросы звучат глупо, я пока совсем не в теме.
И соглашусь с комментариями, было бы ещё интересно посмотреть бенчмарки. Ждём продолжения…
2) Я так понимаю, Microsoft не имеет никакого отношения к .NET nanoFramework, верно? Если так, то есть ли у Microsoft работоспособные/перспективные альтернативы?
Не пинайте если вопросы звучат глупо, я пока совсем не в теме.
И соглашусь с комментариями, было бы ещё интересно посмотреть бенчмарки. Ждём продолжения…
1. Работает через Roslyn, синтаксический сахар некоторый переводит, новые фичи увы. Например, $"".
2. .Net Mircro Framework спонсировался MS, Но похоронен сейчас. В тексте про него есть. Есть ещё dotnet/iot, но он как прослойка к железу, рантайма нет.
2. .Net Mircro Framework спонсировался MS, Но похоронен сейчас. В тексте про него есть. Есть ещё dotnet/iot, но он как прослойка к железу, рантайма нет.
1. .NET nanoFramework и .NET 5 напрямую не связаны. .NET nanoFramework это форк «большого» .NET. Безусловно, некоторые фичи .NET 5 могут быть перенесены.
2. уже есть ответ в комментариях
2. уже есть ответ в комментариях
Поддерживает совмещение управляемого кода на C# и неуправляемого кода на C/C++ в одном проекте.А можно поподробней? Мне проще было написать функции на C#, чем код на C приделать, правда это было довольно давно, потом упростили написание стабов.
А по производительности, каждый if отнимает уйму времени… Ну и для сравнения: string.PadLeft была начала на C#, потом я её код поменял, производительность выросла в 5000(!) раз.
Пара комментов:
ChibiOS не поддерживается ESP32
На ESP32 нет загрузчика
Схема архитектуры .NET nanoFramework — HAL используется от ОС, перед Hardware должна быть ОС.
System.Math вынесен из Core, так как не влезал в какую-то платку у мэйнтейнера…
По совмещение кода будет в продолжение.
Архитектура отраженная в схемах правильная. nanoCLR по факту и является ОС с HAL и остальными модулями ChibiOS. Поэтому и нет на схеме ChibiOS в виде отдельного самостоятельного компонента. Совсем детали, не смотрел, в практической части более детально этот момент распишу. С System.Math на самом деле немного другая история, связанная с кодированием больших типов данных, и оптимизацией арифметических операций. Это интересный момент, постараюсь представить в следующих публикациях.
Архитектура отраженная в схемах правильная. nanoCLR по факту и является ОС с HAL и остальными модулями ChibiOS. Поэтому и нет на схеме ChibiOS в виде отдельного самостоятельного компонента. Совсем детали, не смотрел, в практической части более детально этот момент распишу. С System.Math на самом деле немного другая история, связанная с кодированием больших типов данных, и оптимизацией арифметических операций. Это интересный момент, постараюсь представить в следующих публикациях.
nanoCLR по факту и является ОС с HAL и остальными модулями ChibiOSУвы нет. То, что оно собирается вместе с осью, не говорит о том, что оно выполняет функции ОС. Иначе бы портировать было не реально. По сути это форк .Net Micro Framework.
С System.Math на самом деле немного другая историяС удовольствием выслушаю данную душещипательную историю… А так рекомендую почитать тут: github.com/nanoframework/Home/issues/426
С PadLeft обманулся, посмотрел свой комит, в 5 раз, это у меня в тестах производительность была 5000 вызовов в секунду.
Писал несложную прогу на STM32/SPL, она занимала 4КБ.
Начал её же на STM32/CubeMX, там просто main() занимал 4КБ.
Интересно, сколько занимает моргалка светодиодами под .Net?
Понятно, что для скучных промышленных вещей, вроде опроса небольшого количества датчиков многим будет привычней дотнет. Но, такой работы не так много и с ней ардуино неплохо справляется, полностью отбивая свою стоимость.
В STM32 лично у меня все процессорное время на учете, и постоянно надо еще чуть-чуть разогнаться, туда штука с таким аппетитом — не заедет. Но, если кто-то не считает деньги за железо и не сталкивался с дефицитом чипов (сейчас неподдельный stm32f103cb стоит 900р), да будет так
Начал её же на STM32/CubeMX, там просто main() занимал 4КБ.
Интересно, сколько занимает моргалка светодиодами под .Net?
Понятно, что для скучных промышленных вещей, вроде опроса небольшого количества датчиков многим будет привычней дотнет. Но, такой работы не так много и с ней ардуино неплохо справляется, полностью отбивая свою стоимость.
В STM32 лично у меня все процессорное время на учете, и постоянно надо еще чуть-чуть разогнаться, туда штука с таким аппетитом — не заедет. Но, если кто-то не считает деньги за железо и не сталкивался с дефицитом чипов (сейчас неподдельный stm32f103cb стоит 900р), да будет так
Индустрия ИТ движется в сторону Runtime сред с возможностью переноса кода между платформами. Раньше .NET от MS работал только под Windows, а сейчас на Linux прекрасно себя чувствует. Нативный C++ код в большинстве будет работать быстрее. Но весь вопрос, сколько будет затрачено человеко-часов, и какая квалификация потребуется.
В битве стоимости микроконтроллера и стоимости затрат человеко-часов на разработку ПО в совокупности подготовки разработчика, цена микроконтроллера все меньше имеет значение. Новое время диктует новые требования, необходимо взаимодействие с Интернетом, поддержка различных протоколов связи, поддержка TLS, шифрование, OTA обновление. Все это реализовывать на C++ весьма долго и затратно. Дополнительно, высокая абстракция от оборудования, позволяет конечному разработчику устройства гораздо быстрее сменить сам микроконтроллер. Именно это качество, перенос Arduino-совместимого код на различные микроконтроллеры, изменил индустрию навсегда. Сбив спесь с крупных компаний, потому что теперь светодиодом уже может мигать и школьник.
С++ для микроконтроллеров останется, но будет существенно потеснен. Как в свое время театр потеснил кинематограф. Театр остался, но для особых сценариев, для утонченных дам и господ.
В битве стоимости микроконтроллера и стоимости затрат человеко-часов на разработку ПО в совокупности подготовки разработчика, цена микроконтроллера все меньше имеет значение. Новое время диктует новые требования, необходимо взаимодействие с Интернетом, поддержка различных протоколов связи, поддержка TLS, шифрование, OTA обновление. Все это реализовывать на C++ весьма долго и затратно. Дополнительно, высокая абстракция от оборудования, позволяет конечному разработчику устройства гораздо быстрее сменить сам микроконтроллер. Именно это качество, перенос Arduino-совместимого код на различные микроконтроллеры, изменил индустрию навсегда. Сбив спесь с крупных компаний, потому что теперь светодиодом уже может мигать и школьник.
С++ для микроконтроллеров останется, но будет существенно потеснен. Как в свое время театр потеснил кинематограф. Театр остался, но для особых сценариев, для утонченных дам и господ.
Чисто теоретически, она может занимать и не более 6KiB. Потому что существуют системы с подобной архитектурой (байткод, интерпретатор, сборка мусора, все дела), которые удаётся упихать в такие объёмы. Например, www.ccs.neu.edu/~stamourv/papers/picobit.pdf
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
.NET nanoFramework — платформа для разработки приложений на C# для микроконтроллеров