На мой взгляд проще использовать готовый комбо датчик гироскоп/акселерометр, и по алгоритму определять что происходит с аппаратом в текущий момент, благо железо позволяет. И потом твердотельную релюшку дергать, потребление тока у нее небольшое, или транзистор (в зависимости от схематики).
4) Если не удается развернуть, то можно залить приложение вручную. Собрать его и выполнить команду, номер COM-порта и путь к файлу заменить на свои значения:
Используйте проект nanoframework-esp32-scan-wifi все что связано с wifi можете удалить. Или возьмите проект Ssd13xx и замените контакты I2C, они отличаются на плате TTGO:
Клиентские утилиты доступны бесплатно. У них платно оболочка GUI и сервер для Windows.
Утилиты упаковал в архив (github), при установке расширения FastIoT эта папка распаковывается и все работает. Единственный момент в путях Windows необходимо писать для папки C:\RemoteCode => "/cygdrive/c/RemoteCode/...".
Пример копирования папок, все одна строка на выполнение:
Восхитительно! rsync для Windows 7 можно использовать из пакета cwRsync (https://itefix.net/cwrsync) По крайней мере в расширение .NET FastIoT используется для копирования файлов с Windows 7+ на Ubuntu/Debian.
Это уже звучит как оскорбление, тех, кто этим занимается. И на самом деле высокий порог входа не ограничивает некомпетентных людей. Ваше утверждение не более чем голословно. С таким же успехом можно назвать практически всех разработчиков на .NET идиотами, потому что они не пишут на C/C++.
Мало того, чисто технически, сама программа на фреймворке более надежна чем без него, т.к. фреймворк создает некую песочницу за рамки которой разработчик не может выйти, а значит, возможностей совершить ошибки у него будет существенно меньше. Но это справедливо только при утверждении, что сам фреймворк работает без ошибок.
Заливал прошивку ESP32_BLE_REV0. Да, пост не содержит информацию об прошивке, но в название платы фигурирует название модуля - ESP-WROOM-32, что более чем достаточно для понимания выбора прошивки. Предыдущий пост, как раз был посвящен выбору прошивок.
Если для разработки критичных приложений будут использовать такие фреймворки, самолёты будут падать чаще…
Что-то не видна причинно-следственная связь. А системы падают не от фреймворков, а от х..як, х..як и в продакшн. От этого ни одна система, хоть на числом ассемблере, не застрахована.
Генерируемые шрифты это отлично. У меня еще задумка обеспечить возможность легкого добавления/расширения других славянских языков, и если возможно добавить китайский.
Вы описываете некачественный программный код, а его можно написать корявым хоть на ассемблере. Да, безусловно, фреймворк съедает некоторые ресурсы, но весь вопрос, что вы получаете взамен. Возможность снизить порог вхождения, сократить время разработки, обеспечить высокую совместимость и перенос программного кода с большого ".NET", на мой взгляд неплохое подспорье. Применительно к .NET nanoFramework, могу ответственно заявить, ничего не лагает и не тупит. Если у вас что-то не заработало, так давайте вместе разберемся, решим эту проблему, всякое бывает и ошибки случаются, в том числе и в фреймворке.
.NET nanoFramework позволяет с минимальными знаниями начать разрабатывать свое устройство, что открывает большую возможность для творчества и вовлекает большое количество людей. График роста загрузок пакетов и развитие фреймворка доказывает что он интересен сообществу. А раз так, то почему бы не заняться .NET nanoFramework?
.NET вообще не позиционируется как решение для RT. Для меня .NET nanoFramework, это возможность создавать несложные бытовые устройства с минимальными затратами, например умная бытовая техника, сельское хозяйство, мониторинг. Если разработчик знает "большой" .NET, то ему минимум потребуется времени для перехода на nF, плюс к этому будет возможность переноса программного кода. А а люблю платформу .NET)
В первой части об этом идет речь, только не сделал четкое разделение реализации на bare metal и ОС.
Эталонная реализация .NET nanoFramework работает поверх ChibiOS, например для STM32. Но для ESP32 сделано исключение, и работает непосредственно на железе без ОС.
Маловато будет. Я так понял в отличие от .NET nanoFramework на Rust Embedded отсутствует интерактивная отладка во время исполнения приложения, чтобы полностью стек просматривать?
Так вроде уже. Не Си конечно по популярности, но никто и не претендовал. Библиотеки под всё самое используемое есть давно, статьи, на конференциях эмбеддщиков на нём кодят и тд
Тогда ждем посты про Rust на embedded устройствах ;)
Если Rust наберет популярность для embedded устройств, то это будет замечательно, все будут только в плюсе. Под разные задачи разработчик сможет выбрать наиболее для него подходящий инструмент. Применительно Rust к .NET nanoFramework, на Rust для .NET можно писать низкоуровневый неуправляемый код, т.е. нижний слой. И не забываем про критику Торвальдса.
Согласен, в таких проектах обязательно должен быть дубляж критически важных подсистем.
Благодарю! Код уже посмотрел, идеи отличные.
На мой взгляд проще использовать готовый комбо датчик гироскоп/акселерометр, и по алгоритму определять что происходит с аппаратом в текущий момент, благо железо позволяет. И потом твердотельную релюшку дергать, потребление тока у нее небольшое, или транзистор (в зависимости от схематики).
Вместо 2, должна быть 1, т.е.
Можете свой проект NanoFrameworkTest1.nfproj как есть, вместе с бинарниками, отправить мне на почту, я попробую его развернуть на своей плате.
Давайте по порядку:
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:
Исходный проект (без добавления моего кода) - SSD13xx & SSH1106 OLED display family
Шутки у Вас какие-то плоские)
Клиентские утилиты доступны бесплатно. У них платно оболочка GUI и сервер для Windows.
Утилиты упаковал в архив (github), при установке расширения FastIoT эта папка распаковывается и все работает. Единственный момент в путях Windows необходимо писать для папки C:\RemoteCode => "/cygdrive/c/RemoteCode/...".
Пример копирования папок, все одна строка на выполнение:
C:\RemoteCode\cwrsync\rsync.exe --log-file=rsync.log --progress -avz -e "C:\RemoteCode\cwrsync\ssh.exe -i C:\RemoteCode\keys\id_rsa_bpim64 -o 'StrictHostKeyChecking no'" "/cygdrive/d/Anton/Projects/RemoteAppArm64-new/bin/Debug/net5.0/linux-arm64/" "root@192.168.43.208:/root/RemoteAppArm64"
'StrictHostKeyChecking no' - ординарные кавычки
Восхитительно! rsync для Windows 7 можно использовать из пакета cwRsync (https://itefix.net/cwrsync) По крайней мере в расширение .NET FastIoT используется для копирования файлов с Windows 7+ на Ubuntu/Debian.
Это уже звучит как оскорбление, тех, кто этим занимается. И на самом деле высокий порог входа не ограничивает некомпетентных людей. Ваше утверждение не более чем голословно. С таким же успехом можно назвать практически всех разработчиков на .NET идиотами, потому что они не пишут на C/C++.
Мало того, чисто технически, сама программа на фреймворке более надежна чем без него, т.к. фреймворк создает некую песочницу за рамки которой разработчик не может выйти, а значит, возможностей совершить ошибки у него будет существенно меньше. Но это справедливо только при утверждении, что сам фреймворк работает без ошибок.
Заливал прошивку ESP32_BLE_REV0. Да, пост не содержит информацию об прошивке, но в название платы фигурирует название модуля - ESP-WROOM-32, что более чем достаточно для понимания выбора прошивки. Предыдущий пост, как раз был посвящен выбору прошивок.
Что-то не видна причинно-следственная связь. А системы падают не от фреймворков, а от х..як, х..як и в продакшн. От этого ни одна система, хоть на числом ассемблере, не застрахована.
Генерируемые шрифты это отлично. У меня еще задумка обеспечить возможность легкого добавления/расширения других славянских языков, и если возможно добавить китайский.
Вы описываете некачественный программный код, а его можно написать корявым хоть на ассемблере. Да, безусловно, фреймворк съедает некоторые ресурсы, но весь вопрос, что вы получаете взамен. Возможность снизить порог вхождения, сократить время разработки, обеспечить высокую совместимость и перенос программного кода с большого ".NET", на мой взгляд неплохое подспорье. Применительно к .NET nanoFramework, могу ответственно заявить, ничего не лагает и не тупит. Если у вас что-то не заработало, так давайте вместе разберемся, решим эту проблему, всякое бывает и ошибки случаются, в том числе и в фреймворке.
.NET nanoFramework позволяет с минимальными знаниями начать разрабатывать свое устройство, что открывает большую возможность для творчества и вовлекает большое количество людей. График роста загрузок пакетов и развитие фреймворка доказывает что он интересен сообществу. А раз так, то почему бы не заняться .NET nanoFramework?
.NET вообще не позиционируется как решение для RT. Для меня .NET nanoFramework, это возможность создавать несложные бытовые устройства с минимальными затратами, например умная бытовая техника, сельское хозяйство, мониторинг. Если разработчик знает "большой" .NET, то ему минимум потребуется времени для перехода на nF, плюс к этому будет возможность переноса программного кода. А а люблю платформу .NET)
В первой части об этом идет речь, только не сделал четкое разделение реализации на bare metal и ОС.
Эталонная реализация .NET nanoFramework работает поверх ChibiOS, например для STM32. Но для ESP32 сделано исключение, и работает непосредственно на железе без ОС.
Для работы .NET на FPGA, тоже на Xilinx, есть один интересный проект .NET TO FPGA WITH HASTLAYER.
Маловато будет. Я так понял в отличие от .NET nanoFramework на Rust Embedded отсутствует интерактивная отладка во время исполнения приложения, чтобы полностью стек просматривать?
Тогда ждем посты про Rust на embedded устройствах ;)
Если Rust наберет популярность для embedded устройств, то это будет замечательно, все будут только в плюсе. Под разные задачи разработчик сможет выбрать наиболее для него подходящий инструмент. Применительно Rust к .NET nanoFramework, на Rust для .NET можно писать низкоуровневый неуправляемый код, т.е. нижний слой. И не забываем про критику Торвальдса.
Rust все же достаточно низкоуровневый язык, отсутствуют классы и нет систем наследования, по сравнению с C#. И порог вхождения существенно выше.