Comments 37
Embedded - последняя область, которая сопротивлялась засилию жирных тормозных фреймворков, но вот и она пала. Ждём лагающих микроволновок и загружающихся по 10 секунд автомобильных приборных панелей. Хотя, стоп, о чём это я, оно ведь уже здесь, уже лагает и тупит. Короче, в Embedded пока ещё не совсем всё всрато, но мы уверенно движемся к тому, чтобы всё было как на ПК и смартфонах.
С другой стороны, для той же микроволновки производительности микропроцессора обычно более чем достаточно. В таком случае почему бы не взять более удобный язык и существующий тулсет вокруг него?!
Вы описываете некачественный программный код, а его можно написать корявым хоть на ассемблере. Да, безусловно, фреймворк съедает некоторые ресурсы, но весь вопрос, что вы получаете взамен. Возможность снизить порог вхождения, сократить время разработки, обеспечить высокую совместимость и перенос программного кода с большого ".NET", на мой взгляд неплохое подспорье. Применительно к .NET nanoFramework, могу ответственно заявить, ничего не лагает и не тупит. Если у вас что-то не заработало, так давайте вместе разберемся, решим эту проблему, всякое бывает и ошибки случаются, в том числе и в фреймворке.
.NET nanoFramework позволяет с минимальными знаниями начать разрабатывать свое устройство, что открывает большую возможность для творчества и вовлекает большое количество людей. График роста загрузок пакетов и развитие фреймворка доказывает что он интересен сообществу. А раз так, то почему бы не заняться .NET nanoFramework?
Нет. На ассемблере корявый код можно написать только специально, а на всех этих фреймворках он встречается сплошь и рядом. И вы правильно указали основную проблему: "с минимальными знаниями начать разрабатывать свое устройство". На ассемблере или на С будет писать опытный и толковый человек со знанием архитектуры железа и протоколов, и у него получится хороший код. Бонусом можно будет взять микорконтроллер дешевле и сэкономить на серийном производстве. А человек "с минимальными знаниями" напишет всё кое-как, не учтёт кучу возможных ситуаций и произведёт на свет очередной тормозной виснущий говнодевайс, который, если повезёт, окажется в электронной поздравительной открытке, а не в системе управления лифтом.
Вы троллите или серьезно так считаете?
Просто достаточно взглянуть на недавнее (в рамках истории) прошлое и увидеть падавшие самолеты из-за ошибок в ПО, марсоходы, разбивающиеся о поверхность планеты, неправильно работавшие системы ПВО и ПРО, аппараты для лучевой терапии, сжигавшие людей. И все ПО для них писалось на ассемблере или Си, иногда на более специфичных, но таких же низкоуровневых языках.
Неужели все это были вредители, которые специально хотели как можно больше людей поубивать, да попортить имущество таким вот интересным способом? А может таки человек - существо неидеальное, и допускает ошибки, и выбор более сложного в использовании инструмента - не снизит их количество?
Может быть я бы так не шутил, если бы не встречал достаточно серьёзных устройств, типа управления станков на Ардуино. При чём, без понимания архитектуры микроконтроллера и понимания, что компилятор может давать ошибки. И там такое было, что шевелятся волосы.
Касательно ошибок в коде, все ошибаются. Но реально, если вы разделите количество программных аварий на общее количество устройств и умножите на сто, то будут доли процента (сотые). А тут есть шанс выйти в проценты.
Буду рад, если я заблуждаюсь и это повысит надёжность.
Вообще то ЯВУ и проверенные библиотеки резко повышают надежность.
Вот с производительностью будет тут печально, уровень Питона.
Но никто не отменял области обучения, прототипирования, простых поделок.
Если для разработки критичных приложений будут использовать такие фреймворки, самолёты будут падать чаще…
Что-то не видна причинно-следственная связь. А системы падают не от фреймворков, а от х..як, х..як и в продакшн. От этого ни одна система, хоть на числом ассемблере, не застрахована.
Чем выше порог входа в дело, тем меньше в этом деле идиотов и тем ниже вероятность ошибки.
Это уже звучит как оскорбление, тех, кто этим занимается. И на самом деле высокий порог входа не ограничивает некомпетентных людей. Ваше утверждение не более чем голословно. С таким же успехом можно назвать практически всех разработчиков на .NET идиотами, потому что они не пишут на C/C++.
Мало того, чисто технически, сама программа на фреймворке более надежна чем без него, т.к. фреймворк создает некую песочницу за рамки которой разработчик не может выйти, а значит, возможностей совершить ошибки у него будет существенно меньше. Но это справедливо только при утверждении, что сам фреймворк работает без ошибок.
Как раз наоборот, чем сложнее - тем больше ошибок....
Ну и тру прогеры кладут болт на SDK и регистры в ручную пернекладывают, что за чушь... А SDK такие багнутые есть, что мама не горюй...
Тру-прогеры пишут свой SDK и HAL, в котором учитывают все особенности архитектуры и делают всё качественно и оптимально. Они знают как поведёт себя та или иная функция, и если она в каком-то случае будет слишком неоптимальна, то они проведут оптимизацию или напишут новую функцию, оптимальную для нового применения.
Я то про "труъ" разрабов от конторы железной говорил, что не SDK, а не пойми что... Например, тот же ESP32 и их попытки починить ADC... Лучше их никто ESP не знает...
В ответственных применениях типа авиа, авто и мед техники применяются специфические стандарты и требования к коду, где при хорошем подходе нельзя просто так взять и подсунуть левую либу, но это в идеальном мире...
А Вы не суйте левые либы) Вы думаете в авиа, авто и мед нет open-source кода? Есть и предостаточно. Все требования на самом деле упираются в зону ответственности. Первый сыр-бор с автопилотом для авто, был именно из-за этого, т.е. кого винить в случае проблем?
Например, решили вы сделать свою вундервафлю. Взяли железку от крупного вендора, а не китайскую на три рубля. Сделали прошивку на Windows 10 IoT вместе со своим приложением. А потом бац! И клиент из-за вашей вундервафли получил убытки. Вы проводите экспертизу и выясняете, что ваш код отработал без нареканий, проблема возникла из-за системного драйвера Windows. В этом случае, клиент взыскивает компенсацию с поставщика решения, т.е. с вас. А вы в свою очередь с Microsoft, потому что проблема возникла из-за ОС.
В случае использования open-source, вся ответственность лежит на ваших плечах, вот и весь разговор.
ESP32 -- довольно "жирный" чип: много рам, флэш, мегагерц, два ядра и масса оборудования. Помимо дотнета, видел для него фреймворки на гоу, расте и даже на джаваскрипте. Не вижу ничего плохого, что есть ещё один возможный фреймворк, который может кому-то помочь реализовать какую-либо идею с микроконтроллером. Так что, одобряю.
На счёт шрифтов могу предложить посмотреть как я это сделал в своём компоненте (своя графическая библиотека). https://github.com/jef-sure/ili9341_dgx/tree/main/components/dgx Компонент сделан подходящим к ESP-IDF. Там есть шрифты и, кстати, драйвера к SSD1306 для SPI и I2C вариантов. Файлы шрифтов получаются конвертером там же в проекте ili9341_dgx/font2c/font2c.c. Конвертер берёт TTF-файлы и производит подходящие к моему компоненту Си-исходники.
Генерируемые шрифты это отлично. У меня еще задумка обеспечить возможность легкого добавления/расширения других славянских языков, и если возможно добавить китайский.
Я же привёл пример моего компонента. Там любые Unicode диапазоны можно подключать в любой комбинации. То, что каждый кодепоинт приходится искать по списку диапазонов, практически никак не влияет на скорость рисования. То есть, этой частью повышенной трудоёмкости можно смело пренебречь, по крайней мере, в условиях микроконтроллеров. Время на работу с собственно дисплеем намного больше, чем на поиск глифа.
Мой простейший тест с оптимизацией рисования линии вертикальными/горизонтальными кусочками против "чисто по точкам" на ESP32 даёт "среднее" ускорение в два раза. Но при тесте на писи, когда вместо рисования точки формальная запись в рам/фреймбуфер, сравнение алгоритмов даёт наоборот, замедление в два раза.
У меня такая платка естьTTGO, и на работе я пишу на.NETтак что решил попробовать.
Сначала я решил попробовать сCODE, так как не хотел устанавливать студию.
Нигде не нашёл какая прошивка к какой плате, в статье тоже не указана кстати.
Устанавливал ESP_BLE_REV0 и REV3
REV3 даёт подсказку
Seems that the firmware image that's about to be used is for a revision 3 device, but the
connected device is ESP32-D0WDQ6 (revision 1). You should use the 'ESP32_WROOM_32' instead.
Но такой платы в списке нет (позже удалось установить и эту прошивку с помощью nanoff.exe)
Скачал с GitHub примеры, блинк загрузился, но светодиод не засветился,
Нашёл, что порт должен быть 16, поменял, и тоже мимо
попробовал пример сканер вайфая, не загружаетсяDeploying 119416/120608 bytes.
Deploying 120428/120608 bytes.
Failed memory check @ 0x001B0000.
*** ERROR deploying assemblies to the device ***
Write failed.
Exit with return code 1
Ладно, поставил 2019, установил плагин, но не поставил desktop development
после того как установил, проект компилируется, девайс показывается, но старта нет, студия предлагает attach to process..., пришлось переставлять плагин.
блинк заработал, тот же самый блинк что запускал из CODE.
Вайфай сканер не заработал, 1>------ Deploy started: Project: nanoframework-esp32-scan-wifi, Configuration: Debug Any CPU ------
1>Getting things ready to deploy assemblies to .NET nanoFramework device: ESP32 @ COM12.
1>Adding nanoframework_esp32_scan_wifi v1.0.0.0 (11492 bytes) to deployment bundle
1>Adding System.Threading v1.0.4.3 (3884 bytes) to deployment bundle
1>Adding nanoFramework.System.Text v1.1.3.3 (5828 bytes) to deployment bundle
1>Adding System.Net v1.9.0.1 (20852 bytes) to deployment bundle
1>Adding System.Device.Gpio v1.0.4.3 (5896 bytes) to deployment bundle
1>Adding System.Device.I2c v1.0.3.3 (1756 bytes) to deployment bundle
1>Adding System.Device.Wifi v1.4.0.16 (7244 bytes) to deployment bundle
1>Adding nanoFramework.Runtime.Events v1.10.0.3 (3412 bytes) to deployment bundle
1>Adding System.IO.Streams v1.0.0.2 (6728 bytes) to deployment bundle
1>Adding nanoFramework.Hardware.Esp32 v1.3.6.3 (4160 bytes) to deployment bundle
1>Adding Iot.Device.Ssd13xx v1.1.0.0 (17524 bytes) to deployment bundle
1>Adding mscorlib v1.12.0.4 (31832 bytes) to deployment bundle
1>Deploying 12 assemblies to device... Total size in bytes is 120608.
1>Deploy failed.
Но, после того как передёрнул питания запустилось.
Заливал прошивку ESP32_BLE_REV0. Да, пост не содержит информацию об прошивке, но в название платы фигурирует название модуля - ESP-WROOM-32, что более чем достаточно для понимания выбора прошивки. Предыдущий пост, как раз был посвящен выбору прошивок.
Помучался ещё вечер,
2 лога ниже, разница в 1 строчку //Init LCD device = new Ssd1306(I2cDevice.Create(new I2cConnectionSettings(2, Ssd1306.DefaultI2cAddress)), Ssd13xx.DisplayResolution.OLED128x64);
device.ClearScreen();
и
//Init LCD device = new Ssd1306(I2cDevice.Create(new I2cConnectionSettings(2, Ssd1306.DefaultI2cAddress)), Ssd13xx.DisplayResolution.OLED128x64);
// device.ClearScreen();
1>Done building project "NanoFrameworkTest1.nfproj".
2>------ Deploy started: Project: NanoFrameworkTest1, Configuration: Debug Any CPU ------
2>Getting things ready to deploy assemblies to .NET nanoFramework device: ESP32 @ COM12.
2>Adding NanoFrameworkTest1 v1.0.0.0 (1092 bytes) to deployment bundle
2>Adding System.Device.Gpio v1.0.4.3 (5896 bytes) to deployment bundle
2>Adding Iot.Device.Ssd13xx v1.1.0.0 (17524 bytes) to deployment bundle
2>Adding nanoFramework.Hardware.Esp32 v1.3.6.3 (4160 bytes) to deployment bundle
2>Adding nanoFramework.Runtime.Events v1.10.0.3 (3412 bytes) to deployment bundle
2>Adding System.Device.I2c v1.0.3.3 (1756 bytes) to deployment bundle
2>Adding mscorlib v1.12.0.4 (31832 bytes) to deployment bundle
2>Deploying 7 assemblies to device... Total size in bytes is 65672.
2>Deploy failed.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========
1>------ Deploy started: Project: NanoFrameworkTest1, Configuration: Debug Any CPU ------
1>Getting things ready to deploy assemblies to .NET nanoFramework device: ESP32 @ COM12.
1>Adding NanoFrameworkTest1 v1.0.0.0 (1064 bytes) to deployment bundle
1>Adding System.Device.Gpio v1.0.4.3 (5896 bytes) to deployment bundle
1>Adding Iot.Device.Ssd13xx v1.1.0.0 (17524 bytes) to deployment bundle
1>Adding nanoFramework.Hardware.Esp32 v1.3.6.3 (4160 bytes) to deployment bundle
1>Adding nanoFramework.Runtime.Events v1.10.0.3 (3412 bytes) to deployment bundle
1>Adding System.Device.I2c v1.0.3.3 (1756 bytes) to deployment bundle
1>Adding mscorlib v1.12.0.4 (31832 bytes) to deployment bundle
1>Deploying 7 assemblies to device... Total size in bytes is 65644.
1>Deployment successful!
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========
Получается выходит за размер памяти, и ничего дельного акромя блинк на этой плате не сделать.
Давайте по порядку:
1) Плата для развертывания - Wemos TTGO WiFi/Bluetooth BLE с OLED-экраном 0.96 дюйма на ESP-WROOM-32. У меня куплена вот прям эта.
2) Прошивка - ESP32_BLE_REV0
3) Проект сканера Wi-Fi который на видео - nanoframework-esp32-scan-wifi
4) Если не удается развернуть, то можно залить приложение вручную. Собрать его и выполнить команду, номер COM-порта и путь к файлу заменить на свои значения:
nanoff --target ESP32_BLE_REV0 --serialport COM3 --deploy --image "C:\Projects\nanoframework-esp32-scan-wifi\bin\Debug\nanoframework_esp32_scan_wifi.bin"
Используйте проект nanoframework-esp32-scan-wifi все что связано с wifi можете удалить. Или возьмите проект Ssd13xx и замените контакты I2C, они отличаются на плате TTGO:
//configure the I2C GPIOs
Configuration.SetPinFunction(5, DeviceFunction.I2C1_DATA); // ESP32 - 21, Wemos TTGO OLED Battery - 5
Configuration.SetPinFunction(4, DeviceFunction.I2C1_CLOCK); // ESP32 - 22, Wemos TTGO OLED Battery - 4 Исходный проект (без добавления моего кода) - SSD13xx & SSH1106 OLED display family
Можете свой проект NanoFrameworkTest1.nfproj как есть, вместе с бинарниками, отправить мне на почту, я попробую его развернуть на своей плате.
Ssd1306(I2cDevice.Create(new I2cConnectionSettings(2, Ssd1306.DefaultI2cAddress))
Вместо 2, должна быть 1, т.е.
Ssd1306(I2cDevice.Create(new I2cConnectionSettings(1, Ssd1306.DefaultI2cAddress))
Правильно я понял что в nanoFramework никаких System.Data.Odbc и odbc-драйверов нету?
Верно. Поддержка баз данных достаточно сложная вещь в условиях ограниченной памяти. Пока для хранения данных можно использовать коллекции. В .NET Micro Framework от GHI Electronics была поддержка SQLite (файл GHI Electronics NETMF Library Documentation.chm). Кстати, можно будет рассмотреть вариант портирования под nF.
А есть где-нибудт список всех сборок/классов?
В идеале степень реализации базовых классов .NET, а если ещё и в сравнении с актуальной версией .NET 6. Смотрел в документации, нашёл только такой краткий список:
Class Libraries - https://docs.nanoframework.net/content/architecture/class-libraries.html
В планах проекта добавить поддержку SQLite. Пока есть черновик, почитать подробнее Draft Feature: Add SQLite.
Ещё есть вопрос по поддержке ESP32. Как на нём работает Framework?
Если точнее то какая там OS, в документации упоминается ChibiOS но только в разделе STM32. А что крутится в ESP32 как-то явно нигде не сказано.
nF на ESP32 работает поверх ESP-IDF, без ChibiOS. Как работает nF в публикации - .NET nanoFramework — платформа для разработки приложений на C# для микроконтроллеров.
А как с лицензированием ESP-IDF. Нашёл у них про лицензию Apache-2.0 license (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/COPYRIGHT.html)
Есть ли ограничения на коммерческое использование?
Судя по: https://github.com/espressif/esp-idf/blob/master/LICENSE
Вроде без ограничений:
Permissions: Commercial use...
Если это не используется для создания биологического, химического, и другого оружия. И еще есть ограничения в медицине, там где присутствует непосредственная связь со здоровьем человека. В остальном для коммерческого применения, сфера использования не ограничена. Недавно в блоге Timeweb, как раз был обзор контроллера Norvi на базе ESP32-WROOM-32, пост NORVI ENET: ESP32 + Ethernet W5500 (а что, так можно было?). Поэтому свою железку для продаж на базе ESP32 + nanoFramework можете сделать без проблем.
Что нового в .NET nanoFramework? Подключаем LCD экран, сканируем Wi-Fi сети