Rust для ESP32C3

[nikolz]

Захотелось собрать примеры Bare-metal ESP32C3.
Примеры на zig работают, но нет примеров с Deepsleep.
Решил собрать примеры на Rust.
но проблемы с установкой RUST для Windows.(см картинку)
Кто знает как решить проблемы.
В инете проблема указана, а решения нет.
Поделитесь опытом установки RUST для ESP32

 

[pvvx]

Software - Embedded Rust on Espressif

Ferrous Systems' Embedded Rust on Espressif training material

docs.esp-rs.org

 

[pvvx]

> Примеры на zig работают, но нет примеров с Deepsleep.

Кто такой "zig"?
И есть куча примеров со sleep в ESP-IDF. И их можно включить в любой другой проект.
Зачем лишний код в виде Rust?
Rust — язык программирования, которым пользуются для написания приложений, кода для высоконагруженных серверов и блокчейна.
В конечном счете, выбор между Rust и C++ зависит от конкретных требований вашего проекта. Если вы ставите во главу угла безопасность, опыт разработчика и современные концепции программирования, Rust — сильный претендент . Однако для чистой производительности, больших существующих кодовых баз и устоявшихся библиотек C++ остается доминирующей силой.

 

[pvvx]

Для ESP не годится ни C++ ни Rust, ни даже чистый СИ, если используется HEAP. Это гарантированный сбой работы системы в сложных проектах, когда HEAP не в 100 раз превышает по сумме все объемы запросов памяти всех сразу процедур. Если HEAP 1МБ и проект мигания светодиодом с отключенными сообщениями отладки, тогда критическая дефрагментация HEAP может и не произойти.
У ESP нет MMU с виртуализацией RAM. По этому все промышленные или более серьезные проекты с SoC не имеющими MMU с виртуализацией адресов используют только статические буфера в RAM.

 

[pvvx]

И вам уже десяток постов накалакал, почему в ESP32-C3 deep-sleep не выгоден по соображениям производительности и потребления в сферах WiFi/BLE/Zigbee. Получить выгоду от deep-sleep возможно только в случае использования на длительных периодах, что не входит в штатную работу (тайминги) WiFi/BLE/Zigbee. Т.е. только с потерей или отключением связи на длительный период и нового соединения после.

В других случаях применяется простой sleep, без отключения всего в SoC.
По этому таких примеров с deep-sleep нет. Возможно что такие примеры есть у извращенцев, которые что-то шарят в программировании, но не в hard-ware.

 

[nikolz]

И вам уже десяток постов накалакал, почему в ESP32-C3 deep-sleep не выгоден по соображениям производительности и потребления в сферах WiFi/BLE/Zigbee. Получить выгоду от deep-sleep возможно только в случае использования на длительных периодах, что не входит в штатную работу (тайминги) WiFi/BLE/Zigbee. Т.е. только с потерей или отключением связи на длительный период и нового соединения после.

В других случаях применяется простой sleep, без отключения всего в SoC.
По этому таких примеров с deep-sleep нет. Возможно что такие примеры есть у извращенцев, которые что-то шарят в программировании, но не в hard-ware.

Да Вы написали много. Но зачем?
Я спросил конкретный вопрос.
А вы поплыли.
все что есть в esp-idf я уже протестил. Результаты показал.
-------------------
Отвечаю на ваш вопрос: Zig - это язык программирования а-ля СИ.
-------------------
Отвечаю на ваш вопрос. Примеры в ESP-idf не устраивают так как хочу bare metal на ESP32, аналогично тому, который использую на ESP8266 на основе rboot. Для этого нашел лишь вариант на Rust и ZIG.

 

[pvvx]

Каким образом другой язык программирования изменит время старта SoC и заполнит кэш процессора после deep-sleep?

При этом наиболее контролируемым языком после ASM является СИ. Контролируемым по производительности и используемых ресурсах.

 

[impfromliga]

deep-sleep не выгоден

тут еще важно уточнить общую структуру таймингов при любом сетевом deep-sleep. Кроме времени холодного старта ESP ядра, есть старт Wireless стека до приема пакета (который у ESP закрыт в отличии от каких-нибудь NXP в который можно залезть что бы оптимизировать протокол - в чем собственно и соль), плюс довольно критичным у многих МК есть еще дрейф таймера (например была история что deep-sleep делался на NXP со внешнего RTC от DALLAS - у которого точность 2ppm)

 

[pvvx]

Кроме времени холодного старта ESP ядра, есть старт Wireless стека до приема пакета

Время старта программных частей всегда можно оптимизировать.
Время аппаратного страта RF на прием или передачу обычно меньше чем всё другие стартовые процедуры.
Единственное что там может увеличивать потребление и время активности чипа - это подкалибровка. Но это тоже зависит от ваших умений писать оптимальный код.
В готовых библиотеках предоставляемых для данного чипа в этом никто не заинтересован.