Ничего фантастического, только факты и ничего более. В первой части был приведен пример решения компании OrgPal.Iot, перейдите и почитайте. Я так полагаю эта компания и является основным спонсором развития платформы.
Устройство PalThree — используется для частого и точного мониторинга нефтегазовых месторождений. Выбор был обусловлен необходимостью использования простого решения с возможностью интеграции с сотнями датчиков. Многие компании использую различные дорогостоящие решения, это приводит к большой стоимости обслуживания и увеличивает время перестройки инфраструктуры. .NET nanoFramework — для данных задач подходит как никак лучше из-за высокой скорости разработки решений и легкости интеграций различных интерфейсов.
Я уже молчу про истоки платформы в лице компании GHI Electronics
GHI Electronics с 2008 года, построила весь свой бизнес на разработке микроконтроллеров и решений на базе .NET Micro Framework. В портфолио GHI Electronics были небольшие микроконтроллеры в стиле Arduino — FEZ Domino и весьма производительные с несколькими мегабайтами ОЗУ (для микроконтроллеров это весьма круто).
То что касается C++ кода, так в Arduino это своя реализация, тут момент скорее всего сугубо академический, вопрос соответствия конкретной версии стандарта. Если вам нравиться писать весь код на C++, пожалуйста, вам же никто не запрещает. А у меня другой подход. Тем более нужно не забывать, что для nanoFramework некоторые "особо важные" задачи можно реализовать на C++, а потом их дергать из C#. Поэтому сравнение лоб в лоб C# и C++ не совсем уместно.
Основная задача мк управлять контактами GPIO и осуществлять передачу данных по имеющимся шинам. На мой взгляд, единственный наиболее репрезентативный тест заключается в оценки скорости переключения контактов GPIO. Сравнение на одном и том же мк, например ESP32/STM32, какая будет частота переключения на коде Arduino, FreeRTOS, и C# (nanoFramework). Можно будет замерить дельту приращения времени которая добавляется слоем nanoCLR. Подобный вопрос в комментариях поднимался и для .NET IoT для Linux. У меня пока нет достаточно точных контрольно-измерительных устройств для проведения замеров.
Так мы говорим об одних и тех же вещах, о создание абстракций для разработчиков. mbed прекрасная платформа, сам немного программировал. Мне очень понравилась функция подтягивания необходимой библиотеки из общего репозитория в свой проект. nanoFramework в каком то смысле альтернатива платформе mbed. На мой взгляд наличие выбора платформ исходя из запросов пользователей только делает лучше и привлекательнее разработку для встраиваемых систем.
А так для автоматизации разработки .NET приложений в Linux для ARM почти закончил плагин к Visual Studio Code. Хочу что бы все работало и крутилось не выходя за пределы VSCode, как на Arduino. Все должно быть - Freakin' Easy!
Еще пол года назад было не так удобно, но в последнее время команда разработчиков nanoFramework серьезно продвинулась. Они уже подготовили Preview версию плагина для новой Visual Studio 2022
Я не путаю причину со следствием, просто вы очень однобоко рассматриваете данный момент. До массового распространения микроконтроллеров радиолюбители тоже говорили зачем использовать мк когда тоже самое можно сделать на транзисторах. Но однако микроэлектроника пришла к программируемым чипам и упаковки всего и вся в отдельные готовые микросхемы. Теперь мы не занимаемся пайкой усилителя радиосигнала, а просто вставляем в плату готовый чип. Просто вы не учитываете что стоимость человека-часа разработчика с течением времени увеличивается, и появляется потребность в предоставления более высокой абстракции для более быстрой разработки. Ключевой фактор увеличение производительности мк и появления nanoFramework это желание сократить время на разработку и тем самым сократить расходы человека-часов. Кто быстрее вытолкнет на рынок отличный девайс, того и тапки. А вы попробуйте "получать удовольствие" разрабатывая сложное устройство только на С, посчитайте сколько у вас уйдет времени.
Вы рассматриваете "трудозатраты" достаточно однобоко. Если нет драйвера под новый датчик, то пошел нафиг с новым годом. Под платформу Arduino безусловно существует несоразмерно гораздо больше различных драйверов для датчиков, чем под nanoFramework. Сейчас если пользователю необходимо быстро прикрутить датчик, то скорее всего он возьмет Arduino. Но давайте рассмотрим nanoFramework с позиции бизнеса. Для любого предприятия необходимы разработчики. Прелесть nanoFramework заключается уже в наличие практически готовых разработчиках на рынке труда. Любой .NET разработчик может писать код под nanoFramework, ему нет необходимости изучать отдельно Arduino C-подобный код. И еще раз повторюсь про переносимость кода между nanoFramework и .NET IoT для Linux, вообще считаю шикарной вещью. Кодовая база для больших приложений уже готова, и в этом случае написание драйвера уже становится не насколько значимой вещью.
Это не настолько главный параметр. Создание бенчмарка для микроконтроллеров не простая задача. Если у вас есть какой-нибудь подобный тест для всех платформ, тогда обязательно попробую его исполнить. Каждый слой в программном обеспечении съедает аппаратные ресурсы и увеличивает время отклика, по другому не бывает. Весь вопрос, что вы получаете взамен. Для примера возьмем Windows 11 и Windows 7. Для меня Windows 11 не привносит в мою работу ничего нового, зато сжирает неимоверно много аппаратных ресурсов и еще принудительно обновляется. А если взамен вы получаете существенное сокращение времени разработки решения, переносимость кода между микроконтроллерами включая .NET IoT, то есть смысл жертвовать ресурсами, тем более учитывая экстенсивный путь развития электроники, еще больше ядер и больше ОЗУ. И в какой-то момент времени потеря производительности уже граничит на уровне погрешности.
Причем тут Javascript? Особенно учитывая факт крайней ограниченности языка. Когда рассматривал вариант выбора языка для расширения VSCode между Javascript и TypeScript, выбор пал на TypeScript безоговорочно.
Писать на чистом ассемблере? Если это шутка, то это плохая шутка. Что-то я не вижу веб-приложений реализованных на ассемблере как и множества других приложений.
Все работы выполнялись в VMWare Workstation по причине невозможности работы Device explorer в Windows 7. А Windows 10 вместе с VS в виртуальной машине не сказать что шустро работают, поэтому минимизирую нагрузку на CPU. Можно использовать Far, он еще быстрее работает.
Первый абзац Вашего комментария тоже применим и к nanoFramework. Кодовая база с библиотеками появится позже, Arduino старше, исторически так сложилось. Про переносимость библиотек на Arduino не скажу что так прекрасно, в большинстве случаев да, но вы забываете про тайминги. Иногда библиотеки все же приходится править. Крупные разработчики микроконтроллеров всерьез не рассматривали появление Arduino, а зря. Когда подход Arduino начал их теснить, сами вынуждены были примкнуть. В результате так появилась серия отладочных плат ST Nucleo с Arduino совместимыми контактами.
Потому что такие платформы как nanoFramework позволяют обеспечить кроссплатформенность между различными микроконтроллерами. Рассмотрим такую ситуацию. Допустим, некий предприниматель нанял разработчиков для создания одного устройства и в качестве МК выбрали один из серии ESP32. В какой-то момент времени главный разработчик сказал предпринимателю, что возможностей ESP32 им не хватает, необходимо использовать STM32. Что в этом случае делать предпринимателю? Сделать в устройстве гибрид двух МК ESP32 и STM32, или все заново переписать? Возможность переноса кода между различными аппаратными платформами существенно развязывает руки в первую очередь бизнесу. Если вдруг поставщик МК существенно повысит цены, то можно с минимальными потерями перейти на другой МК. Мало того, программный код переносим между МК и .NET IoT под Linux. Вы можете написать код на C# и перенести его с Raspberry Pi на nanoFramework, и наоборот. С нативной платформой от производителя МК вы таких фокусов не добьетесь.
Конечно. Первый скриншот как раз показывает точку останова и просмотр текущих значений переменных во время работы. Единственное необходимо помнить, что не все платы поддерживаемые сообществом реализуют все функции nanoFramework, включая отладку.
Это лишь говорит о том, что на Delphi кто то еще пишет, но это не делает его лидером. Вот когда в индексе TIOBE Delphi/Object Pascal хотя бы войдет в десятку, перейдет с жалкого 17 места, вот тогда и появится основание для пересмотра точки зрения. Я как вспомню что объявление переменных только в блоке VAR, так брр аж холодок по коже идет. Поверьте, я не считаю Delphi/Object Pascal плохим инструментом. В свое время на Delphi написал несколько программ для автоматизации медицинского сектора. Программы на Delphi меня кормили в прямом смысле этого слова, и я благодарен за это разработчикам. Но нужно вспомнить время шалтай-болтая когда часть разработчиков стали активно переходить на .NET. Время было потеряно, доверие сообщества было подорвано, и это привело к стагнации. Вы сравните стоимость IDE RAD Studio и MS Visual Studio, и вспомните когда появилась редакция Community Edition. Delphi/Object Pascal исторически устарел, сообщество в основном состоит из людей преклонного возраста, что тут еще добавить?
Я между прочем такого не заявлял, наглая и провокационная ложь. Мое предложение заключалось в использование более современных инструментов т.к. на мой взгляд это более рационально. Но это сугубо мое мнение, не претендующее на абсолют. В комментариях каждый высказывает свое мнение, и дело автора взять во внимание или нет. А за свои слова Вы между прочем не отвечаете, я все еще жду пруфлинки на современные научные публикации в которых расчеты выполнены на паскале.
Так Вы с себя и начните. Пруфлинки на научные статьи на паскале не завезли. Требуете от других, а сами свою позицию не подтвердили. И как к Вам проявлять уважение после этого? Если хотите аргументов, вот пожалуйста. На текущий момент Python находится на первой позиции в индексе TIOBE, а Delphi/Object Pascal на 17 месте. Ну давайте, порасказывайте что Python ничего не стоит и никому не нужен, чего не скажешь конечно же про Pascal. На питоне не пишу, использую C#. Еще важный момент, автор поста не указал архитектуру исполнения. Его робот будет работать на x86 или на ARM? Просто я тоже подготавливаю систему распознавания на .NET с использованием OpenCV на Linux. Система будет работать на одноплатном компьютере banana pi m64, процессор ARM. Датчики, GPIO уже умею подключать. Данные с Web-камеры из .NET кода забираю, по сути осталось прикрутить OpenCV, причем все это работает в Docker контейнерах. И что фантастического в использования OpenCV из паскаля?
А еще себя зарекомендовала палка-копалка со времен зарождения человечества. Между прочем хороший инструмент, сам пользовался когда жил в деревне в далекие 90-е, просто другого не было. С палки-копалки началось освоение космоса,и это факт. Но сейчас используют более современные инструменты. Приведите примеры свежих публикаций из научной сферы с использованием расчетов на паскале, очень интересно будет посмотреть.
Ничего фантастического, только факты и ничего более. В первой части был приведен пример решения компании OrgPal.Iot, перейдите и почитайте. Я так полагаю эта компания и является основным спонсором развития платформы.
Я уже молчу про истоки платформы в лице компании GHI Electronics
То что касается C++ кода, так в Arduino это своя реализация, тут момент скорее всего сугубо академический, вопрос соответствия конкретной версии стандарта. Если вам нравиться писать весь код на C++, пожалуйста, вам же никто не запрещает. А у меня другой подход. Тем более нужно не забывать, что для nanoFramework некоторые "особо важные" задачи можно реализовать на C++, а потом их дергать из C#. Поэтому сравнение лоб в лоб C# и C++ не совсем уместно.
Основная задача мк управлять контактами GPIO и осуществлять передачу данных по имеющимся шинам. На мой взгляд, единственный наиболее репрезентативный тест заключается в оценки скорости переключения контактов GPIO. Сравнение на одном и том же мк, например ESP32/STM32, какая будет частота переключения на коде Arduino, FreeRTOS, и C# (nanoFramework). Можно будет замерить дельту приращения времени которая добавляется слоем nanoCLR. Подобный вопрос в комментариях поднимался и для .NET IoT для Linux. У меня пока нет достаточно точных контрольно-измерительных устройств для проведения замеров.
Так мы говорим об одних и тех же вещах, о создание абстракций для разработчиков. mbed прекрасная платформа, сам немного программировал. Мне очень понравилась функция подтягивания необходимой библиотеки из общего репозитория в свой проект. nanoFramework в каком то смысле альтернатива платформе mbed. На мой взгляд наличие выбора платформ исходя из запросов пользователей только делает лучше и привлекательнее разработку для встраиваемых систем.
Для работы с GPIO на C# вот публикация https://habr.com/ru/company/vdsina/blog/555598/
А так для автоматизации разработки .NET приложений в Linux для ARM почти закончил плагин к Visual Studio Code. Хочу что бы все работало и крутилось не выходя за пределы VSCode, как на Arduino. Все должно быть - Freakin' Easy!
Еще пол года назад было не так удобно, но в последнее время команда разработчиков nanoFramework серьезно продвинулась. Они уже подготовили Preview версию плагина для новой Visual Studio 2022
Я не путаю причину со следствием, просто вы очень однобоко рассматриваете данный момент. До массового распространения микроконтроллеров радиолюбители тоже говорили зачем использовать мк когда тоже самое можно сделать на транзисторах. Но однако микроэлектроника пришла к программируемым чипам и упаковки всего и вся в отдельные готовые микросхемы. Теперь мы не занимаемся пайкой усилителя радиосигнала, а просто вставляем в плату готовый чип. Просто вы не учитываете что стоимость человека-часа разработчика с течением времени увеличивается, и появляется потребность в предоставления более высокой абстракции для более быстрой разработки. Ключевой фактор увеличение производительности мк и появления nanoFramework это желание сократить время на разработку и тем самым сократить расходы человека-часов. Кто быстрее вытолкнет на рынок отличный девайс, того и тапки. А вы попробуйте "получать удовольствие" разрабатывая сложное устройство только на С, посчитайте сколько у вас уйдет времени.
Вы рассматриваете "трудозатраты" достаточно однобоко. Если нет драйвера под новый датчик, то пошел нафиг с новым годом. Под платформу Arduino безусловно существует несоразмерно гораздо больше различных драйверов для датчиков, чем под nanoFramework. Сейчас если пользователю необходимо быстро прикрутить датчик, то скорее всего он возьмет Arduino. Но давайте рассмотрим nanoFramework с позиции бизнеса. Для любого предприятия необходимы разработчики. Прелесть nanoFramework заключается уже в наличие практически готовых разработчиках на рынке труда. Любой .NET разработчик может писать код под nanoFramework, ему нет необходимости изучать отдельно Arduino C-подобный код. И еще раз повторюсь про переносимость кода между nanoFramework и .NET IoT для Linux, вообще считаю шикарной вещью. Кодовая база для больших приложений уже готова, и в этом случае написание драйвера уже становится не насколько значимой вещью.
Это не настолько главный параметр. Создание бенчмарка для микроконтроллеров не простая задача. Если у вас есть какой-нибудь подобный тест для всех платформ, тогда обязательно попробую его исполнить. Каждый слой в программном обеспечении съедает аппаратные ресурсы и увеличивает время отклика, по другому не бывает. Весь вопрос, что вы получаете взамен. Для примера возьмем Windows 11 и Windows 7. Для меня Windows 11 не привносит в мою работу ничего нового, зато сжирает неимоверно много аппаратных ресурсов и еще принудительно обновляется. А если взамен вы получаете существенное сокращение времени разработки решения, переносимость кода между микроконтроллерами включая .NET IoT, то есть смысл жертвовать ресурсами, тем более учитывая экстенсивный путь развития электроники, еще больше ядер и больше ОЗУ. И в какой-то момент времени потеря производительности уже граничит на уровне погрешности.
Причем тут Javascript? Особенно учитывая факт крайней ограниченности языка. Когда рассматривал вариант выбора языка для расширения VSCode между Javascript и TypeScript, выбор пал на TypeScript безоговорочно.
Писать на чистом ассемблере? Если это шутка, то это плохая шутка. Что-то я не вижу веб-приложений реализованных на ассемблере как и множества других приложений.
Подразумевалась естественная мотивация для написания более оптимального кода, не учёл рассмотрение этого момента с другой стороны)
Все работы выполнялись в VMWare Workstation по причине невозможности работы Device explorer в Windows 7. А Windows 10 вместе с VS в виртуальной машине не сказать что шустро работают, поэтому минимизирую нагрузку на CPU. Можно использовать Far, он еще быстрее работает.
Первый абзац Вашего комментария тоже применим и к nanoFramework. Кодовая база с библиотеками появится позже, Arduino старше, исторически так сложилось. Про переносимость библиотек на Arduino не скажу что так прекрасно, в большинстве случаев да, но вы забываете про тайминги. Иногда библиотеки все же приходится править. Крупные разработчики микроконтроллеров всерьез не рассматривали появление Arduino, а зря. Когда подход Arduino начал их теснить, сами вынуждены были примкнуть. В результате так появилась серия отладочных плат ST Nucleo с Arduino совместимыми контактами.
Кодить в браузере, дело вкуса на мой взгляд. Разработка в VS под nanoFramework мне очень понравилась, все работает из коробки включая отладку.
Потому что такие платформы как nanoFramework позволяют обеспечить кроссплатформенность между различными микроконтроллерами. Рассмотрим такую ситуацию. Допустим, некий предприниматель нанял разработчиков для создания одного устройства и в качестве МК выбрали один из серии ESP32. В какой-то момент времени главный разработчик сказал предпринимателю, что возможностей ESP32 им не хватает, необходимо использовать STM32. Что в этом случае делать предпринимателю? Сделать в устройстве гибрид двух МК ESP32 и STM32, или все заново переписать? Возможность переноса кода между различными аппаратными платформами существенно развязывает руки в первую очередь бизнесу. Если вдруг поставщик МК существенно повысит цены, то можно с минимальными потерями перейти на другой МК. Мало того, программный код переносим между МК и .NET IoT под Linux. Вы можете написать код на C# и перенести его с Raspberry Pi на nanoFramework, и наоборот. С нативной платформой от производителя МК вы таких фокусов не добьетесь.
Конечно. Первый скриншот как раз показывает точку останова и просмотр текущих значений переменных во время работы. Единственное необходимо помнить, что не все платы поддерживаемые сообществом реализуют все функции nanoFramework, включая отладку.
Ха-ха, Вы уточните год первого выпуска и приведите ограничения лицензии для этой редакции
Это лишь говорит о том, что на Delphi кто то еще пишет, но это не делает его лидером. Вот когда в индексе TIOBE Delphi/Object Pascal хотя бы войдет в десятку, перейдет с жалкого 17 места, вот тогда и появится основание для пересмотра точки зрения. Я как вспомню что объявление переменных только в блоке VAR, так брр аж холодок по коже идет. Поверьте, я не считаю Delphi/Object Pascal плохим инструментом. В свое время на Delphi написал несколько программ для автоматизации медицинского сектора. Программы на Delphi меня кормили в прямом смысле этого слова, и я благодарен за это разработчикам. Но нужно вспомнить время шалтай-болтая когда часть разработчиков стали активно переходить на .NET. Время было потеряно, доверие сообщества было подорвано, и это привело к стагнации. Вы сравните стоимость IDE RAD Studio и MS Visual Studio, и вспомните когда появилась редакция Community Edition. Delphi/Object Pascal исторически устарел, сообщество в основном состоит из людей преклонного возраста, что тут еще добавить?
Я между прочем такого не заявлял, наглая и провокационная ложь. Мое предложение заключалось в использование более современных инструментов т.к. на мой взгляд это более рационально. Но это сугубо мое мнение, не претендующее на абсолют. В комментариях каждый высказывает свое мнение, и дело автора взять во внимание или нет. А за свои слова Вы между прочем не отвечаете, я все еще жду пруфлинки на современные научные публикации в которых расчеты выполнены на паскале.
Так Вы с себя и начните. Пруфлинки на научные статьи на паскале не завезли. Требуете от других, а сами свою позицию не подтвердили. И как к Вам проявлять уважение после этого? Если хотите аргументов, вот пожалуйста. На текущий момент Python находится на первой позиции в индексе TIOBE, а Delphi/Object Pascal на 17 месте. Ну давайте, порасказывайте что Python ничего не стоит и никому не нужен, чего не скажешь конечно же про Pascal. На питоне не пишу, использую C#. Еще важный момент, автор поста не указал архитектуру исполнения. Его робот будет работать на x86 или на ARM? Просто я тоже подготавливаю систему распознавания на .NET с использованием OpenCV на Linux. Система будет работать на одноплатном компьютере banana pi m64, процессор ARM. Датчики, GPIO уже умею подключать. Данные с Web-камеры из .NET кода забираю, по сути осталось прикрутить OpenCV, причем все это работает в Docker контейнерах. И что фантастического в использования OpenCV из паскаля?
А еще себя зарекомендовала палка-копалка со времен зарождения человечества. Между прочем хороший инструмент, сам пользовался когда жил в деревне в далекие 90-е, просто другого не было. С палки-копалки началось освоение космоса,и это факт. Но сейчас используют более современные инструменты. Приведите примеры свежих публикаций из научной сферы с использованием расчетов на паскале, очень интересно будет посмотреть.