Comments 118
Нет ничего лучше, чем научиться разрабатывать приложения на C# для микроконтроллеров, где у тебя нет гигабайтов оперативной памяти и n-количества ядер процессора
Есть кое что лучше - научиться разрабатывать такие приложения, которые умеют с пользой задействовать n ядер процессора.
Подразумевалась естественная мотивация для написания более оптимального кода, не учёл рассмотрение этого момента с другой стороны)
Да вы всё правильно написали. Это я так, о наболевшем - параллельные и конкурентные программы зело сложны!
Там не может быть оптимального кода, там интерпретатор... ардуино рвёт его в клочья.
А так, да, память экономить можно, и процессорные циклы. В nF каждый If стоит столько, что диву даёшься.
Я так посмотрю Вы прям эксперт в области программирования, особенно понравилась фраза "ардуино рвёт его в клочья". У вас есть конкретные результаты тестов или вы как попугай повторяете что уже было сказано? Нет там никакого интерпретатора, и быть не может. Сборка компилируется в байт-код для среды исполнения nanoCLR.
Я в старой статье писал уже Вам, что разберитесь сначала, как оно работает. Байт-код как раз и интерпретируется. Экспертом Вы тут прикидываетесь...
Если код читать не умеете, то посмотрите на название репозитория: https://github.com/nanoframework/nf-interpreter
А результаты тестов будут? Если Вы такой грамотей, то что в вашем портфолио нет ни одного поста? Вы же себя считаете профессионалом. Или вы написать пост не в состоянии, максимум интеллекта хватает только строчить комментарии?
А результаты тестов будут?
Если Вы такой грамотей, то что в вашем портфолио нет ни одного поста?
А не люблю я посты писать, что ж поделать, таким уродился... Или это неотъемлемая часть становления человека?
Вы же себя считаете профессионалом
Простите, где я такое писал? Считать себя профессионалом это звёздочку словить, ЧСВ тешить. Профессионалом не сам становишься, а другие величать начинают.
Или вы написать пост не в состоянии
Зачем? Вы же написали, спасибо Вам за это, я просто указал на неточности. Хотите можем приватно подискутировать, приглашаю на официальный Discord nanoFramework. Там можно много чего узнать про реализацию nF.
максимум интеллекта хватает только строчить комментарии?
Ох, юношеский максимализм, простите, что поджёг Вам пукан.
Что-то по вашей ссылке нет никаких тестов сравнения платформ, вообще она ссылается на commit.
Или это неотъемлемая часть становления человека?
Безусловно. Иначе цена его жизни = 0. Каждый человек в течение жизни получает полезный опыт который он может передать потомкам или поведать обществу, или что-то должен сделать значимое. Если Вам поведать не о чем, тогда понятно.
Что-то по вашей ссылке нет никаких тестов сравнения платформ, вообще она ссылается на commit.
Там и написано, что компилированный код работает в 5 раз быстрее интерпретируемого. И причём тут платформа, когда я говорил об Arduino на ESP32. Посмотрите код библиотеки, везде вызывается компилированный C, а на C# всего несколько функций, включая мой коммит.
Каждый человек в течение жизни получает полезный опыт который он может передать потомкам или поведать обществу, или что-то должен сделать значимое.
Тут я с Вами полностью согласен, но один из главных критериев, что опыт должен быть положительный. А Ваша статья вводит людей в заблуждение, так сказать искажает его черед призму и амбиции рассказчика, позволяет сделать не верные выводы. Результат статьи потраченное время зря, как и большинство материалов в Интернет. Комментарии под статьёй подтверждают мои выводы. При этом nF очень хорош для прототипирования и DIY, но реально коммерцию делать можно на простых задачах, аля современные стартапы по формуле 1 идея = 1 девайс. У nF ещё очень много ограничений, с которыми будет не приятно столкнуться в проде, но о которых Вы красиво умолчали... И на всякий случай, я пишу на нём, мне нравится, но я прекрасно осознаю его нишу.
Если Вам поведать не о чем, тогда понятно.
То есть у меня нет статей на хабре и мне поведать не о чём получается? Лол, у Вас какой-то узкий слишком мирок. Ну и смотря на Ваш ограниченный круг мышления, что тот же сталевар, не пишет статьи, значит он бесполезен? Профессию можно заменить на любую другую, не из современных.
При этом nF очень хорош для прототипирования и DIY, но реально коммерцию делать можно на простых задачах, аля современные стартапы по формуле 1 идея = 1 девайс.
Время покажет.
У nF ещё очень много ограничений, с которыми будет не приятно столкнуться в проде, но о которых Вы красиво умолчали
Так напишите разоблачение, с удовольствием почитаю Ваши замечания, пока кроме кратких комментариев на горизонте ничего невидно.
тот же сталевар, не пишет статьи, значит он бесполезен
Сталевар в отличие от Вас конкретным делом занимается и приносит людям пользу.
А Ваша статья вводит людей в заблуждение, так сказать искажает его черед призму и амбиции рассказчика, позволяет сделать не верные выводы. Результат статьи потраченное время зря, как и большинство материалов в Интернет.
В каждой последующей публикации по nanoFramework буду обязательно Вас упоминать до тех пор, пока не напишите разоблачение на мою статью, о написанных мною заблуждениях по nF.
Сборка компилируется в байт-код для среды исполнения nanoCLR.Почему не стали компилировать в машинный код?
Нет ничего лучше, чем научиться разрабатывать приложения на C# для микроконтроллеров, где у тебя нет гигабайтов оперативной памяти и n-количества ядер процессора
Зачем для моргания светодиодов гигабайты оперативной памяти?
Есть же ESP-IDF с кучей готовых примеров, поддержкой от производителя, почему все пытаются начать программировать esp на php, js...?
Код на таких языках как C# писать много быстрее и проще. Сам писал под ESP и на C++ и на C#, и для себя решил, что C++ это боль. Создавая код на C++ постоянно раздражаешься от излишних сложностей. Даже такие мелочи как объявления методов отдельно от реализации, необходимость соблюдения порядка методов в классе в порядке их вызова начинают бесить после опыта с C#. Ну и отсутствие нормальных проверенных библиотек для C++ IoT приводит к трате тонн времени на написание и отладку собственных велосипедов. В итоге постоянно прорубаешься через джунгли с мачете вместо того чтобы проехать по шоссе эффективной разработки с C#.
А так как большинство задач IoT сейчас совсем не про экономию памяти или тактов процессора, а про скорость разработки, наглядность и доступность в изучении, то потому и выбор в основном в сторону более доступных языков и платформ.
Потому что такие платформы как nanoFramework позволяют обеспечить кроссплатформенность между различными микроконтроллерами. Рассмотрим такую ситуацию. Допустим, некий предприниматель нанял разработчиков для создания одного устройства и в качестве МК выбрали один из серии ESP32. В какой-то момент времени главный разработчик сказал предпринимателю, что возможностей ESP32 им не хватает, необходимо использовать STM32. Что в этом случае делать предпринимателю? Сделать в устройстве гибрид двух МК ESP32 и STM32, или все заново переписать? Возможность переноса кода между различными аппаратными платформами существенно развязывает руки в первую очередь бизнесу. Если вдруг поставщик МК существенно повысит цены, то можно с минимальными потерями перейти на другой МК. Мало того, программный код переносим между МК и .NET IoT под Linux. Вы можете написать код на C# и перенести его с Raspberry Pi на nanoFramework, и наоборот. С нативной платформой от производителя МК вы таких фокусов не добьетесь.
и в качестве МК выбрали один из серии ESP32. В какой-то момент времени главный разработчик сказал предпринимателю, что возможностей ESP32 им не хватает, необходимо использовать STM32.
не совсем корректно такое сравнение, но имеет право быть. Не коректно потому что, ESP32 это все же про WiFi в первую очередь. STM32 же на борту радиомодуля не имеет. НО, как пример переноса между архитектурами это хорошо.
Если вдруг поставщик МК существенно повысит цены, то можно с минимальными потерями перейти на другой МК
Скорее в условиях дефицита приходится брать что есть, а не то что дешево. Тут пока заказ по электронной почте шел в отдел снабжения 6000 stm32l476 внезапно исчезло из продажи. Подбираешь новой и опять лотерея, успеешь купить или нет.
Мало того, программный код переносим между МК и .NET IoT под Linux. Вы можете написать код на C# и перенести его с Raspberry Pi на nanoFramework, и наоборот. С нативной платформой от производителя МК вы таких фокусов не добьетесь.
ммм, код верхнего уровня и алгоритмы можно переносить спокойно. Отличаться же будет нижний слой, где идет доступ в регистры. я некоторые алгоритмы в Qt отлаживал при программировании ses
UPD. Прочитал первую часть, так оно и есть.
о, боже, чибиос, рантайм, сборщик мусора, дотнеты... в stm32! Там для интернета вещей mbed есть, чтоб сразу в браузере кодить, а потом бинарь как на флэшку в микроконтроллер залил и дело сделано!
Кодить в браузере, дело вкуса на мой взгляд. Разработка в VS под nanoFramework мне очень понравилась, все работает из коробки включая отладку.
в браузере кодить под mbed - это фича самого mbed, но можно его поставить локально как фреймворк и работать в IDE, это дело вкуса. Я к тому, что mbed для STM32 и есть тот самый слой абстракции для IoT и прочих модных вещиц, любезно предоставленный самой ST.
Так мы говорим об одних и тех же вещах, о создание абстракций для разработчиков. mbed прекрасная платформа, сам немного программировал. Мне очень понравилась функция подтягивания необходимой библиотеки из общего репозитория в свой проект. nanoFramework в каком то смысле альтернатива платформе mbed. На мой взгляд наличие выбора платформ исходя из запросов пользователей только делает лучше и привлекательнее разработку для встраиваемых систем.
Первый абзац Вашего комментария тоже применим и к nanoFramework. Кодовая база с библиотеками появится позже, Arduino старше, исторически так сложилось. Про переносимость библиотек на Arduino не скажу что так прекрасно, в большинстве случаев да, но вы забываете про тайминги. Иногда библиотеки все же приходится править. Крупные разработчики микроконтроллеров всерьез не рассматривали появление Arduino, а зря. Когда подход Arduino начал их теснить, сами вынуждены были примкнуть. В результате так появилась серия отладочных плат ST Nucleo с Arduino совместимыми контактами.
открыл первый же пример, подключил свою "ардуину" или ESP32, добавил LED, запустил программку и "наслаждаешься" мигающей лампочкой
Но.... Зачем? Всё это конечно может быть весело, но очень быстро наскучивает, потому что трудозатраты на решение "прикладных" задач гораздо выше покупки готового устройства.
Вы рассматриваете "трудозатраты" достаточно однобоко. Если нет драйвера под новый датчик, то пошел нафиг с новым годом. Под платформу Arduino безусловно существует несоразмерно гораздо больше различных драйверов для датчиков, чем под nanoFramework. Сейчас если пользователю необходимо быстро прикрутить датчик, то скорее всего он возьмет Arduino. Но давайте рассмотрим nanoFramework с позиции бизнеса. Для любого предприятия необходимы разработчики. Прелесть nanoFramework заключается уже в наличие практически готовых разработчиках на рынке труда. Любой .NET разработчик может писать код под nanoFramework, ему нет необходимости изучать отдельно Arduino C-подобный код. И еще раз повторюсь про переносимость кода между nanoFramework и .NET IoT для Linux, вообще считаю шикарной вещью. Кодовая база для больших приложений уже готова, и в этом случае написание драйвера уже становится не насколько значимой вещью.
Ничего фантастического, только факты и ничего более. В первой части был приведен пример решения компании 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++ не совсем уместно.
Как только привел аргументы, так начинается, ну это другое. Они настолько глупые, что ничего не понимают. Взлетит или не взлетит nanoFramework покажет время. Но я знаю точно, если сидеть сложа руки и ничего не делать, то ничего не взлетит. И вы не привели никаких аргументов причин "не взлета".
слишком сложный bootstrap для "самодельщиков", моментального выигрыша никто не получит,
Звучит очень надумано и не конкретно. Да пока платформа не настолько массовая как Arduino. Но лидерами не рождаются, а становятся.
Посмотрел ваш пример про магический шар, достаточно простой пример. Из оборудования у меня все есть, я думаю лучше сделать немного другой более интересный пример раскрывающий платформу nanoFramework. Устройство GPS-трекер с шагомером и отправкой данных в облако, например в Google Fit, вот это будет гораздо более интересно, чем простой банальный шар.
1) Поддержка устройств. Отсутствие поддержки MPU-6050 не является проблемой, если на реализацию драйвера уйдет не более ~5% времени общего времени от написания приложения. У меня есть несколько подобный датчиков, посмотрю из того что имеется в наличие.
2) Сравнивать DIY с промышленным решением по энергоэффективности просто глупость. По той банальной причине, что я не смогу сделать промышленный дизаин платы с напаяным модулем и всем остальным как в серийном производстве, у меня просто нет соответствующего оборудования и минифабрики. Вот когда выпущу на рынок свое мелкосерийное устройство, вот тогда и можно будет сравнить.
3) С другими подобными DIY сравнить можно, без проблем.
4) Код причем будет написан с учетом запуска на .NET 6 Linux на одноплатном компьютере без каких-либо изменений. Вот и поговорим об эфемерности выгоды, как вы потом сделаете тоже самое на Arduino с запуском на Linux.
5) "малая распространенность, отсутствие драйверов" - дело наживное, постепенно появится.
6) "сложность настройки, ..." - вот не понял что сложного в настройке? Приведите конкретный пункт из поста, который у вас вызвал сложность. На мой взгляд, все пункты по настройке в посте вполне осуществимы, даже школьниками. Сложно залить прошивку, установить VS, открыть окошко в VS, вообще непонятно.
Когда/если соберете, дайте мне знать через "личку" - постараюсь найти и кинуть пример, реализованный на классическом bare metal (если, правда, кто-то подобной ерундой занимается), с использованием всех возможностей чипа по deep sleep, и прочим "фокусам" эффективного энергосбережения.
Без проблем. Промежуточные результаты могу опубликовать в своем блоге. Чужие примеры мне не нужны, вы отвечайте своим кодом. Сами напишите deep sleep, и прочие "фокусы", чужими работами каждый может хвастаться, для этого особого интеллекта не требуется.
А вы не считаете свой тон оскорбительным "можете хоть на лбу у себя публиковать"? Наверное, в шатах для таких профессионалов как вы, такой тон разговора норма. Я то сделаю существенно более серьезнее решение чем ваш шар, у меня все равно подобная задача была в планах. Весь вопрос как Вы будете выглядеть после заявления "Результат покажите, ну, или просто "слейтесь", и больше не трепите языком впустую".
Мне кажется, что переходить к оскорблениям диспутантов
Никто Вас не оскорблял. Просто как бы у бизнеса несколько свои причины использования той или иной платформы, которые возможно не столь значимы при разработке DIY, и которые вы не учитываете. Отсутствие драйвера для очередного датчика для бизнеса не будет препятствием. А вот возможность переноса существующего кода на C# "большого" .NET практически один-к-одному на nanoFramework это существенный аргумент для бизнеса. Потому что позволяет быстро надергать необходимый код, и быстро найти разработчиков.
То что вы занимаетесь программирование 30 лет ни о чем не говорит, можно всю жизнь "перекладывать бумажки из одной стопки в другую". Вполне возможно, что молодой человек с хорошим образованием и 5 лет практики будет существенно лучше вас разбираться во встраиваемых решениях. Года для меня лишь показатель сколько времени прожил человек на бренной земле, но не более того.
Второе, именно таких молодых с гибким мышлением как John/Вася, профессионально владеющих .NET платформой и чувствующих себя в Visual Studio как рыба в воде, буду нанимать себе в команду вместо людей с большим опытом в возрасте. Потому что двух недель прокачки под микроконтроллеры nanoFramework будет достаточно для готовности писать код под мк на nanoFramework.
Никакой бизнес не проектирует подобные платформы на "ардуинах", будь то C# или C++
Привел два примера серьезных компаний с многолетним стажем работы, ага никто не делает и никому не нужны. Это уже просто без комментариев, это не ко мне.
100% возникнут сложности в работе с командной строкой, выбором и прошивкой нужного firmware, да даже в работе с Visual Studio
Людей совсем за идиотов тоже не надо считать. Значит разбираться с регистрами памяти в мк это просто, а тыкать в окошки и менюшки VS это сложно. Я работал несколько лет преподавателем информационных дисциплин в колледже. Вел занятия у более 10 групп, где в каждой группе было от 18 до 28 человек. Если бы я им сказал, что практический материал в этом посте это на зачет по предмету, да они плакали бы от счастья. Например, одна из лабораторных включала в себя установку IIS, установку .NET и конфигурирование под ASP.NET приложения, развертывание ASP.NET приложения с определенными настройками (мое приложение). И это выполняли студенты у которых компьютер дома появился всего лишь пару лет назад, было конечно же сложно, но все они сдали работы успешно.
И года, в данном случае, означают опыт, притом личный.
Без какого-либо подтверждения это пустые слова. Напишите пост о своей работе, тем более раз за вашими плечами такой большой опыт. Гарантированно тогда вам есть, чем поделиться с молодой аудиторией. Напишите чем занимались, какие проекты выполняли, что особенного было в решение задач. Вот это и будет подтверждением вашей квалификации.
Вы не умеете прислушиваться к чужому мнению
Ваше мнение ровным счетом ничего не стоит без подтверждения квалификации, и я не понимаю к чему тут прислушиваться. Я работаю с платформой .NET и сворачивать с этого пути не собираюсь, потому что я вижу большой потенциал в этой платформе. .NET позволит реализовать мои задумки существенно быстрее и проще чем подобные системы, поэтому я и выбрал эту платформу для себя. Тут нет никакого фанатизма, мною руководит только четкий расчет.
Серьезных?! "Лолшто"?! Они даже по российским местечковым параметрам просто мелкие "старые стартапы" из нескольких человек и с копеечным оборотом: тыц и тыц.
С вас финансовый аналитик как с меня балерина. Источник этих данных указан? Там есть налоговая отчетность? Исходя из этого источника получается, что в компании работает меньше 25 человек. Вы серьезно так думаете? То железо и представленный софт способно сделать менее 25 человек из которых руководитель, бухгалтер, юрист, кадровик? Привели в пример какой-то желтый сайт, просто детский сад.
Кстати, благодарю за хорошую наводку на следующую тему про nanoFramework, создание GPS-трекера с шагомером и загрузкой данных в облако.
Сложно сказать, что «взлетит» или «не взлетит». .net framework тоже все пророчили скорую гибель. Однако вот уже .NET 5-6 с GRPC и ProtoBuf в коробке.
Да и как вы сами сказали: некоторые крупные корпорации иногда используют «странное» в мк.
Какого проекта? Этого nanoFramework? Ну так и apple начиналась с гаража :) А сам дотнет так вообще «буквально вчера» появился на гитхабе. Так что спорный показатель эта «народная любовь». К тому же корпорациям до неё не всегда есть дело.
Тут у ребят, как я понял, ещё даже не релизная версия, так что рано хоронить.
Да, честно говоря, все аргументы у вас это лишь набор «жизненного опыта». Ну ок, я понял. Тема закрыта.
Да кто вам хамит то? :) Я и то вон пропустил мимо ушей ваш пируэт про «наличие ума» :) Не вижу смысла дальше разговаривать по теме, удачи.
Ваша проблема в том, что вы ошибочно считаете себя профессионалом. Ваши же «сентенции» про «потешить своё ЧСВ» скорее применительно к вам. Я лишь указал на то, что определять будущее того или иного проекта - не в вашей и не в моей компетенции.
Ну ок, давайте разберём «проблему» с драйверами для шара. Нет нужного драйвера для дотнета? Подключу библиотеку/драйвер на C++. Благо дотнет это не запрещает. Эта проблема решена. Далее.
Нужно использовать узкоспециальные платформенные фичи? Дотнет это уровень абстракции, который не закрывает нижележащие слои. Можно прям посреди C# начать писать хоть на ассемблере, хоть на OS API (если есть ОС). Да, вы лишаетесь мультиплатформенности, точно так же, как и при использовании нативного апи. Так что это не аргумент. Откройте ради интереса код любого крупного приложения на дотнет (да даже сам дотнет) и посмотрите - он весь утыкан директивами прекомпилятора для использования платформозависимых фич.
Так что вся оптимизация - это по большей части мастерство оптимизатора. Дотнет позволяет быстрее написать медленный код, в то время как нативный язык позволяет быстрее отстрелить себе ногу.
Покоя вам не даёт мой шар :) Хорошо хоть я шар могу показать, а что можете показать вы? Все ваши «проблемы» дотнета я только что решил за 0.5наносек в комментарии выше. Я боюсь что не вам судить об успешности запусков стратостатов.
Немного странно слышать от человека про решение проблем «языком» когда все его достижения - это перепечатывание новостей на хабре.
Нуштош, хобби придумал не я. В соревнованиях я ни в каких и не участвовал, цель проекта была в другом: составить инструкцию по самостоятельной сборке и запуску (с полным циклом и разрешениями) на территории РФ. Эта цель достигнута. И такого больше нет нигде. Не верите? Ну, погуглите :) Все что вы найдёте это посты в духе ваших: «некий Вася запустил стратостат на 700км». Как запустил, что запустил, куда ходил? Как мне, простому человеку, имея ничего, сесть и сделать «такое же»? Поищите, а я подожду.
Раз уж вы в самом деле решили опуститься до попыток принизить чьи-то достижения (хотя весь этот тред вы именно с них и начали), то вам, для начала, следовало бы обзавестись какими-то контрмерами. Пока что вы просто поливаете всех подряд г@вном, не принимая во внимание контраргументов и не имея ничего «за спиной»
просто в новом проекте перед покупкой проверять совместимость нужно.
.net framework тоже все пророчили скорую гибель.Если подразумевать проприетарную версию Microsoft, то так и произошло — пал смертью open-source :-)
А MicroPython и Espruino взлетели?
В Си в коде есть какие-то непонятные символы * и &.
А каков итог по размеру - интересно ?
Может уже проще NOMMU Linux туда запихать как собственно на ESP32 и сделали ?
Все работы выполнялись в VMWare Workstation по причине невозможности работы Device explorer в Windows 7. А Windows 10 вместе с VS в виртуальной машине не сказать что шустро работают, поэтому минимизирую нагрузку на CPU. Можно использовать Far, он еще быстрее работает.
это такая пасхалка
Первый релиз C# был в 2002 году.
Сам уже лет 15 использую Total Comander 7.04, это первое что переношу на новый ПК или после установки системы :), причем даже без инсталляции, просто копирую папку.
Причем тут Javascript? Особенно учитывая факт крайней ограниченности языка. Когда рассматривал вариант выбора языка для расширения VSCode между Javascript и TypeScript, выбор пал на TypeScript безоговорочно.
Писать на чистом ассемблере? Если это шутка, то это плохая шутка. Что-то я не вижу веб-приложений реализованных на ассемблере как и множества других приложений.
Не хватает самого главного, а именно сравнения потребляемых ресурсов и перформанса. Было бы очень интересно увидеть сравнение размеров и производительности какого-нибудь сферического бенча на pure с, arduino, nanoNet и microPython.
Это не настолько главный параметр. Создание бенчмарка для микроконтроллеров не простая задача. Если у вас есть какой-нибудь подобный тест для всех платформ, тогда обязательно попробую его исполнить. Каждый слой в программном обеспечении съедает аппаратные ресурсы и увеличивает время отклика, по другому не бывает. Весь вопрос, что вы получаете взамен. Для примера возьмем Windows 11 и Windows 7. Для меня Windows 11 не привносит в мою работу ничего нового, зато сжирает неимоверно много аппаратных ресурсов и еще принудительно обновляется. А если взамен вы получаете существенное сокращение времени разработки решения, переносимость кода между микроконтроллерами включая .NET IoT, то есть смысл жертвовать ресурсами, тем более учитывая экстенсивный путь развития электроники, еще больше ядер и больше ОЗУ. И в какой-то момент времени потеря производительности уже граничит на уровне погрешности.
тем более учитывая экстенсивный путь развития электроники, еще больше ядер и больше ОЗУ. И в какой-то момент времени потеря производительности уже граничит на уровне погрешности
Я думаю, что вы путаете причину и следствие. По факту нежелание изучать традиционные для uC языки вынуждает вас брать все более жирные камни. Не наоборот. По итогу мы имеем дичь вроде arduino совместимых плат на чипах Cortex A серии.. а это как микроскопом гвозди забивать, т.е. очень очень очень неэффективно.
Я не путаю причину со следствием, просто вы очень однобоко рассматриваете данный момент. До массового распространения микроконтроллеров радиолюбители тоже говорили зачем использовать мк когда тоже самое можно сделать на транзисторах. Но однако микроэлектроника пришла к программируемым чипам и упаковки всего и вся в отдельные готовые микросхемы. Теперь мы не занимаемся пайкой усилителя радиосигнала, а просто вставляем в плату готовый чип. Просто вы не учитываете что стоимость человека-часа разработчика с течением времени увеличивается, и появляется потребность в предоставления более высокой абстракции для более быстрой разработки. Ключевой фактор увеличение производительности мк и появления nanoFramework это желание сократить время на разработку и тем самым сократить расходы человека-часов. Кто быстрее вытолкнет на рынок отличный девайс, того и тапки. А вы попробуйте "получать удовольствие" разрабатывая сложное устройство только на С, посчитайте сколько у вас уйдет времени.
Главный или нет, но сравнение все равно было бы интересно увидеть :)
Основная задача мк управлять контактами GPIO и осуществлять передачу данных по имеющимся шинам. На мой взгляд, единственный наиболее репрезентативный тест заключается в оценки скорости переключения контактов GPIO. Сравнение на одном и том же мк, например ESP32/STM32, какая будет частота переключения на коде Arduino, FreeRTOS, и C# (nanoFramework). Можно будет замерить дельту приращения времени которая добавляется слоем nanoCLR. Подобный вопрос в комментариях поднимался и для .NET IoT для Linux. У меня пока нет достаточно точных контрольно-измерительных устройств для проведения замеров.
Спасибо. Давно знал про nanoFramework, но всегда боялся пробовать его ставить, для меня казалось это(установка и настройка) больно сложным и муторным. Теперь тоже хочу его попробовать.
Сейчас прогаю в стунии на с++ с visualmicro. Это удобно, но порой с++ просто выводит из себя, когда для простейших задач надо десяток лишних операций сделать. Иметь возможность использовать С# для некоторых задач, это то что надо.
Еще пол года назад было не так удобно, но в последнее время команда разработчиков nanoFramework серьезно продвинулась. Они уже подготовили Preview версию плагина для новой Visual Studio 2022
Должен вам заметить разница весьма ощутимая между C++ и C#
А приведите свой пример законченного приложения для мк на C++, а я его перепишу под nanoFramework, вот и сравним.
Банально создать класс. Надо создать h фаил, там дифайны от двойного включения, прототипы функций. Какой-то смысловой нагрузки все эти действия не несут.
Второй пример, это event из функции одного класса в другом классе. С++ для этого надо делать глобальную функцию или с биндами мудрить. В добавок стандарты везде разные и каждый раз что-то не работает и приходится делать по другому.
Без прототипа у вас на некоторых компиляторах не будут видны функции и классы, которые находятся ниже того, где вы их используете.
По второму. Пример. У вас есть класс программного таймера, у него есть событие по окончанию. И второй класс, который, например, поливает растение. Мне нужно подписаться второй класс на событие срабатывания таймера, что бы включить полив.
а зачем вообще эти объявления, если то же самое в самой функции написано. сами объявления нужны же.
Это прям очень хорошо :) Раньше видел только кривые реализации недо-шарпа без фреймворка.
Только может где-то проглядел, какая версия C# поддерживается?
Была задача использую плату ESP32-WROOM оцифровать звук с микрофона. Для этого читал аналоговый сигнал с пина подключенного к микрофону. Чтобы охватить весь слышимый диапазон нужно читать с частотой 44кГц. При использовании nanoFramework удалось достичь только 3кГц, что очень мало. Espruino показал вообще 0.25кГц. Arduino справился лучше всех - 12 кГц.
Это все хорошо, но есть 2 вопроса:
Что насчёт сред разработки под не только одну ОС? Можно удобно запустить хотя бы в кроссплатформеном vsc?
Можно какое-то сравнение производительности? А то на js ещё удобнее под всякие esp писать, а потом слайд-шоу на адресной ленте.
VS CODE EXTENSION FOR .NET NANOFRAMEWORK
GitHub - nanoframework/nf-VSCodeExtension
Visual Studio Code Extension - .NET nanoFramework (Preview)
Уже доступна разработка под VSCode в том числе и под Linux, более детально в следующих публикациях.
Код на C# работает медленее, чем на Arduino в связи с интерпретацией. Об этом было написано выше в комментариях. Для себя пока не ставлю задачи сравнения производительности, необходимо для начала разработать максимально репрезентативную методику.
Программируем микроконтроллеры ESP32 и STM32 на C# (nanoFramework)