Комментарии 9
Надо было получать состояние gpio пина настроенного на выход из разных тасков. Столкнулся с интересным поведением функции API gpio_get_level. Оказалось, что функция, для пина сконфигурированного на выход, всегда возвращает ноль. Но если читать напрямую бит с регистра состояния пинов, то возвращается правильное состояние. Озадачился.
Почему платформио если вы не используете ардуино библиотеку? Можно установить esp-idf расширеннее, там более гибкие настройки, монитор порта выводит цветные логи и в самом начале базовую информацию о контроллере, а написание кода не отличается
Как-то исторически сложилось, что с PIO я познакомился раньше и, ввиду отсутствия большой разницы между PIO и расширением ESP-IDF, продолжил работать в PIO. К тому же хотелось в этом цикле статей использовать что-то новое — большинство всё-таки работает в расширении ESP-IDF.
Рано или поздно всё равно придется мигрировать с PIO на чистый ESP-IDF.
Одна из предпосылок - система сборки. В CMakeLists.txt можно подключать или отключать конкретные файлы исходного кода или компоненты, и указывать зависимости. PlatformIO подхватывает вообще всё, что может вызвать ошибки из исходников, которые не относятся к конфигурации или циклические зависимости
А если хочется и idf и Ардуино?
Если ты про IDE, то vscode дает возможность создания профилей. Я так и сделал: отдельный профиль (и папка с workspace) под PlatformIO, и отдельный - под ESP-IDF голый.
Отдельный профиль - отдельный набор расширений.
А юнит-тесты на ESP-IDF собираю и провожу через консоль, так как юнит-тест, по сути, проект в проекте, и пока не видел, что он адекватно отрабатывается IDE.
Не помню, начиная с какой версии, но если у тебя поддержки профилей в vscode нет - обнови его.
А если ты про миграцию проекта, при этом не хочешь разом все переписывать, то есть компонент esp32-arduino, добавляется либо в папку components, либо прописывается в манифесте idf_components.yaml
Программирование ESP32 с ESP-IDF в среде platformio #2