И года, в данном случае, означают опыт, притом личный.
Без какого-либо подтверждения это пустые слова. Напишите пост о своей работе, тем более раз за вашими плечами такой большой опыт. Гарантированно тогда вам есть, чем поделиться с молодой аудиторией. Напишите чем занимались, какие проекты выполняли, что особенного было в решение задач. Вот это и будет подтверждением вашей квалификации.
А вы не считаете свой тон оскорбительным "можете хоть на лбу у себя публиковать"? Наверное, в шатах для таких профессионалов как вы, такой тон разговора норма. Я то сделаю существенно более серьезнее решение чем ваш шар, у меня все равно подобная задача была в планах. Весь вопрос как Вы будете выглядеть после заявления "Результат покажите, ну, или просто "слейтесь", и больше не трепите языком впустую".
Когда/если соберете, дайте мне знать через "личку" - постараюсь найти и кинуть пример, реализованный на классическом bare metal (если, правда, кто-то подобной ерундой занимается), с использованием всех возможностей чипа по deep sleep, и прочим "фокусам" эффективного энергосбережения.
Без проблем. Промежуточные результаты могу опубликовать в своем блоге. Чужие примеры мне не нужны, вы отвечайте своим кодом. Сами напишите deep sleep, и прочие "фокусы", чужими работами каждый может хвастаться, для этого особого интеллекта не требуется.
То что вы занимаетесь программирование 30 лет ни о чем не говорит, можно всю жизнь "перекладывать бумажки из одной стопки в другую". Вполне возможно, что молодой человек с хорошим образованием и 5 лет практики будет существенно лучше вас разбираться во встраиваемых решениях. Года для меня лишь показатель сколько времени прожил человек на бренной земле, но не более того.
Второе, именно таких молодых с гибким мышлением как John/Вася, профессионально владеющих .NET платформой и чувствующих себя в Visual Studio как рыба в воде, буду нанимать себе в команду вместо людей с большим опытом в возрасте. Потому что двух недель прокачки под микроконтроллеры nanoFramework будет достаточно для готовности писать код под мк на nanoFramework.
Никакой бизнес не проектирует подобные платформы на "ардуинах", будь то C# или C++
Привел два примера серьезных компаний с многолетним стажем работы, ага никто не делает и никому не нужны. Это уже просто без комментариев, это не ко мне.
100% возникнут сложности в работе с командной строкой, выбором и прошивкой нужного firmware, да даже в работе с Visual Studio
Людей совсем за идиотов тоже не надо считать. Значит разбираться с регистрами памяти в мк это просто, а тыкать в окошки и менюшки VS это сложно. Я работал несколько лет преподавателем информационных дисциплин в колледже. Вел занятия у более 10 групп, где в каждой группе было от 18 до 28 человек. Если бы я им сказал, что практический материал в этом посте это на зачет по предмету, да они плакали бы от счастья. Например, одна из лабораторных включала в себя установку IIS, установку .NET и конфигурирование под ASP.NET приложения, развертывание ASP.NET приложения с определенными настройками (мое приложение). И это выполняли студенты у которых компьютер дома появился всего лишь пару лет назад, было конечно же сложно, но все они сдали работы успешно.
Мне кажется, что переходить к оскорблениям диспутантов
Никто Вас не оскорблял. Просто как бы у бизнеса несколько свои причины использования той или иной платформы, которые возможно не столь значимы при разработке DIY, и которые вы не учитываете. Отсутствие драйвера для очередного датчика для бизнеса не будет препятствием. А вот возможность переноса существующего кода на C# "большого" .NET практически один-к-одному на nanoFramework это существенный аргумент для бизнеса. Потому что позволяет быстро надергать необходимый код, и быстро найти разработчиков.
1) Поддержка устройств. Отсутствие поддержки MPU-6050 не является проблемой, если на реализацию драйвера уйдет не более ~5% времени общего времени от написания приложения. У меня есть несколько подобный датчиков, посмотрю из того что имеется в наличие.
2) Сравнивать DIY с промышленным решением по энергоэффективности просто глупость. По той банальной причине, что я не смогу сделать промышленный дизаин платы с напаяным модулем и всем остальным как в серийном производстве, у меня просто нет соответствующего оборудования и минифабрики. Вот когда выпущу на рынок свое мелкосерийное устройство, вот тогда и можно будет сравнить.
3) С другими подобными DIY сравнить можно, без проблем.
4) Код причем будет написан с учетом запуска на .NET 6 Linux на одноплатном компьютере без каких-либо изменений. Вот и поговорим об эфемерности выгоды, как вы потом сделаете тоже самое на Arduino с запуском на Linux.
5) "малая распространенность, отсутствие драйверов" - дело наживное, постепенно появится.
6) "сложность настройки, ..." - вот не понял что сложного в настройке? Приведите конкретный пункт из поста, который у вас вызвал сложность. На мой взгляд, все пункты по настройке в посте вполне осуществимы, даже школьниками. Сложно залить прошивку, установить VS, открыть окошко в VS, вообще непонятно.
Как только привел аргументы, так начинается, ну это другое. Они настолько глупые, что ничего не понимают. Взлетит или не взлетит nanoFramework покажет время. Но я знаю точно, если сидеть сложа руки и ничего не делать, то ничего не взлетит. И вы не привели никаких аргументов причин "не взлета".
слишком сложный bootstrap для "самодельщиков", моментального выигрыша никто не получит,
Звучит очень надумано и не конкретно. Да пока платформа не настолько массовая как Arduino. Но лидерами не рождаются, а становятся.
Посмотрел ваш пример про магический шар, достаточно простой пример. Из оборудования у меня все есть, я думаю лучше сделать немного другой более интересный пример раскрывающий платформу nanoFramework. Устройство GPS-трекер с шагомером и отправкой данных в облако, например в Google Fit, вот это будет гораздо более интересно, чем простой банальный шар.
Ничего фантастического, только факты и ничего более. В первой части был приведен пример решения компании 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 безоговорочно.
Писать на чистом ассемблере? Если это шутка, то это плохая шутка. Что-то я не вижу веб-приложений реализованных на ассемблере как и множества других приложений.
Без какого-либо подтверждения это пустые слова. Напишите пост о своей работе, тем более раз за вашими плечами такой большой опыт. Гарантированно тогда вам есть, чем поделиться с молодой аудиторией. Напишите чем занимались, какие проекты выполняли, что особенного было в решение задач. Вот это и будет подтверждением вашей квалификации.
А вы не считаете свой тон оскорбительным "можете хоть на лбу у себя публиковать"? Наверное, в шатах для таких профессионалов как вы, такой тон разговора норма. Я то сделаю существенно более серьезнее решение чем ваш шар, у меня все равно подобная задача была в планах. Весь вопрос как Вы будете выглядеть после заявления "Результат покажите, ну, или просто "слейтесь", и больше не трепите языком впустую".
Без проблем. Промежуточные результаты могу опубликовать в своем блоге. Чужие примеры мне не нужны, вы отвечайте своим кодом. Сами напишите deep sleep, и прочие "фокусы", чужими работами каждый может хвастаться, для этого особого интеллекта не требуется.
То что вы занимаетесь программирование 30 лет ни о чем не говорит, можно всю жизнь "перекладывать бумажки из одной стопки в другую". Вполне возможно, что молодой человек с хорошим образованием и 5 лет практики будет существенно лучше вас разбираться во встраиваемых решениях. Года для меня лишь показатель сколько времени прожил человек на бренной земле, но не более того.
Второе, именно таких молодых с гибким мышлением как John/Вася, профессионально владеющих .NET платформой и чувствующих себя в Visual Studio как рыба в воде, буду нанимать себе в команду вместо людей с большим опытом в возрасте. Потому что двух недель прокачки под микроконтроллеры nanoFramework будет достаточно для готовности писать код под мк на nanoFramework.
Привел два примера серьезных компаний с многолетним стажем работы, ага никто не делает и никому не нужны. Это уже просто без комментариев, это не ко мне.
Людей совсем за идиотов тоже не надо считать. Значит разбираться с регистрами памяти в мк это просто, а тыкать в окошки и менюшки VS это сложно. Я работал несколько лет преподавателем информационных дисциплин в колледже. Вел занятия у более 10 групп, где в каждой группе было от 18 до 28 человек. Если бы я им сказал, что практический материал в этом посте это на зачет по предмету, да они плакали бы от счастья. Например, одна из лабораторных включала в себя установку IIS, установку .NET и конфигурирование под ASP.NET приложения, развертывание ASP.NET приложения с определенными настройками (мое приложение). И это выполняли студенты у которых компьютер дома появился всего лишь пару лет назад, было конечно же сложно, но все они сдали работы успешно.
Никто Вас не оскорблял. Просто как бы у бизнеса несколько свои причины использования той или иной платформы, которые возможно не столь значимы при разработке DIY, и которые вы не учитываете. Отсутствие драйвера для очередного датчика для бизнеса не будет препятствием. А вот возможность переноса существующего кода на C# "большого" .NET практически один-к-одному на nanoFramework это существенный аргумент для бизнеса. Потому что позволяет быстро надергать необходимый код, и быстро найти разработчиков.
1) Поддержка устройств. Отсутствие поддержки MPU-6050 не является проблемой, если на реализацию драйвера уйдет не более ~5% времени общего времени от написания приложения. У меня есть несколько подобный датчиков, посмотрю из того что имеется в наличие.
2) Сравнивать DIY с промышленным решением по энергоэффективности просто глупость. По той банальной причине, что я не смогу сделать промышленный дизаин платы с напаяным модулем и всем остальным как в серийном производстве, у меня просто нет соответствующего оборудования и минифабрики. Вот когда выпущу на рынок свое мелкосерийное устройство, вот тогда и можно будет сравнить.
3) С другими подобными DIY сравнить можно, без проблем.
4) Код причем будет написан с учетом запуска на .NET 6 Linux на одноплатном компьютере без каких-либо изменений. Вот и поговорим об эфемерности выгоды, как вы потом сделаете тоже самое на Arduino с запуском на Linux.
5) "малая распространенность, отсутствие драйверов" - дело наживное, постепенно появится.
6) "сложность настройки, ..." - вот не понял что сложного в настройке? Приведите конкретный пункт из поста, который у вас вызвал сложность. На мой взгляд, все пункты по настройке в посте вполне осуществимы, даже школьниками. Сложно залить прошивку, установить VS, открыть окошко в VS, вообще непонятно.
Кстати, благодарю за хорошую наводку на следующую тему про nanoFramework, создание GPS-трекера с шагомером и загрузкой данных в облако.
Как только привел аргументы, так начинается, ну это другое. Они настолько глупые, что ничего не понимают. Взлетит или не взлетит nanoFramework покажет время. Но я знаю точно, если сидеть сложа руки и ничего не делать, то ничего не взлетит. И вы не привели никаких аргументов причин "не взлета".
Звучит очень надумано и не конкретно. Да пока платформа не настолько массовая как Arduino. Но лидерами не рождаются, а становятся.
Посмотрел ваш пример про магический шар, достаточно простой пример. Из оборудования у меня все есть, я думаю лучше сделать немного другой более интересный пример раскрывающий платформу nanoFramework. Устройство GPS-трекер с шагомером и отправкой данных в облако, например в Google Fit, вот это будет гораздо более интересно, чем простой банальный шар.
А приведите свой пример законченного приложения для мк на C++, а я его перепишу под nanoFramework, вот и сравним.
Должен вам заметить разница весьма ощутимая между C++ и C#
Ничего фантастического, только факты и ничего более. В первой части был приведен пример решения компании 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 безоговорочно.
Писать на чистом ассемблере? Если это шутка, то это плохая шутка. Что-то я не вижу веб-приложений реализованных на ассемблере как и множества других приложений.
Подразумевалась естественная мотивация для написания более оптимального кода, не учёл рассмотрение этого момента с другой стороны)