ESP32 в окружении VSCode

    В нескольких следующих статьях я хотел бы детально рассмотреть настройку окружения VSCode для работы с фреймворком ESP-IDF. Не совсем популярная комбинация ПО обладает как преимуществами, так и недостатками, которые при детальном рассмотрении мы попытаемся исправить, обойти или превратить в достоинства.

    Изыскания проводятся в рамках разработки программно-аппаратного комплекса полетного контроллера на чистых кватернионах, без применения углов Эйлера.

    Поскольку предполагается многопользовательская удаленная разработка, то мы решили вначале отработать выбор и настройку самой среды разработки. После нескольких экспериментов с Eclipse, Visual Studio и QT Creator выбор пал на кроссплатформенный VSCode и плагин от разработчика Espressif IDF для работы с фреймворком ESP-IDF.

    В качестве «сердца» контроллера рассмотрим двухъядерный микроконтроллер ESP32, который обладает рядом преимуществ, которые планируется использовать и раскрыть в проекте, а именно:

    1. ESP32 это не MCU, а SoC*, имеющий на борту:

      1. Wi-Fi: 802.11 b/g/n/e/i (802.11n @ 2.4 GHz up to 150 Mbit/s)

      2. Bluetooth: v4.2 BR/EDR and Bluetooth Low Energy (BLE)

        * Все эти интерфейсы мы планируем использовать для коммуникации с изделием. А вот аналоговый радиоканал и FPV использовать по возможности не планируем.

    2. 2 Cores 240 MHz up to 600 DMIPS

    3. ULP co-processor

    В качестве ядра ESP32 использует Tensilica Xtensa 32-bit LX6, у которого есть свои недостатки, главным из который, на мой взгляд, пока является слабая производительность с операциями с плавающей точкой в реальных приложениях. Возможно, это связано с текущей версией ядра LX6 или с компилятором GCC 8 toolchain, пока нет точного понимания. Пока это создает некоторые теоретические проблемы со скоростью работы фильтра Калмана и похожих алгоритмов (реализация Madgwick и Mahony).

    Есть информация, что новое ядро LX7 уже имеет большую производительность, но оно пока используется только в одноядерной версии ESP32-S2.

    Также мы надеемся, что производительность с float может возрасти с выпуском нового toolchain.

    Более детальное сравнение ядер Xtensa vs ARM можно посмотреть здесь.

    Начиная с версии фреймворка ESP-IDF v4.0 Espressif существенно улучшила техническую поддержку и дальнейшую разработку фреймворка. Качественно улучшилась техническая документация и поддержка разработчиков на форуме компании и GitHub. Кардинально улучшилась оперативность обработки сообщений об ошибках в фреймворке и их устранение. Ускорился выпуск новых версий базового фреймворка ESP-IDF, и дополнительных на нем основанных, например Arduino-ESP32.

    Настройка окружения

    Установку всех приложений и утилит мы будем рассматривать на совершенно чистую ОС (Win10Pro). Поэтому, если у вас уже установлены какие-то из перечисленных ниже приложений или утилит, то я рекомендую их удалить. Или учитывайте далее, что параллельное использование нескольких копий или версий программ из окружения может привести к непредсказуемым результатам, отличным от описанных ниже, и делайте советующие поправки на результат.

    В силу некоторых причин я работаю в стеке Windows. Но все последующие рекомендации, скорее всего, будут подходить и для Linux систем. Поэтому буду признателен за комментарии владельцев Linux, если они обнаружат принципиальные отличия в настройках или поведении системы и приложений. Вопрос скорости компиляции в Win и Linux поднимать не стоит, мы прекрасно знаем, что скорость компилирования в Linux в 2-4 раза выше.

    В состав окружения будут входить, в порядке очередности установки:

    1. Git

    2. Python

    3. CMake

    4. VSCode ESP-IDF (далее фреймворк)

    5. ESP-IDF Tools (далее Toolchain)

    Я рекомендую все утилиты ставить в отдельную папку в корень диска, например в C:\dev , за исключением VSCode.

    А проекты сохранять в папку C:\dev\esp32 .

    В дальнейшем это сделает настройку фреймворка более удобной, с визуальной точки зрения, поскольку существенно сократит длину путей к утилитам Toolchain.

    Git

    Сначала поставим Git

    Download URL: https://git-scm.com/

    Installation path: C:\dev\Git

    Python

    Затем поставим Python

    Download URL: https://www.python.org/downloads/

    Installation path: C:\dev\Python39

    Перед установкой убедитесь, что в папке C:\Users\UserName\AppData\Roaming\Python\Python39 не осталось скриптов от предыдущих установок. Почему скрипты для Python из Toolchain попадают в C:\Users\UserName\AppData\Roaming\Python\Python39 (внутри есть еще две папки \Scripts и \site-packages) для меня загадка. Правда скрипты попадают в эту папку только если производить установку ESP-IDF Toolchain из дистрибутива esp-idf-tools-setup-2.3.exe или более ранних версий. Буду признателен, если кто-то подскажет ответ.

    (Q1) Вопрос 1: Почему скрипты для Python из дистрибутива ESP-IDF Tools попадают в папку C:\Users\UserName\AppData\Roaming\Python\Python39 (\Scripts и \site-packages), а не в папку с Python? Можно ли изменить этот путь на пользовательский?

    Вообще буду признателен за комментарии и ответы на заданные по ходу статьи вопросы. В случае ответа на вопросы прошу начинать их в комментариях с префикса (Q1), где цифра после «Q» – номер вопроса, так их будет легче обрабатывать по тексту.

    CMake

    Теперь поставим CMake

    Download URL: https://cmake.org/download/

    Installation path: C:\dev\CMake

    На текущий момент Toolchain ESP-IDF использует для сборки проекта только свою версию CMake v3.13.4, которая идет в комплекте, и категорически не хочет использовать другие, в отличии от Python. Это выглядит странно, поскольку на сколько мне известно, у версий 3.13-19 нет явных проблем с обратной совместимостью.

    (Q2) Вопрос 2: Какие проблемы с обратной совместимостью есть у CMake версий 3.13-19? Почему Toolchain ESP-IDF не позволяет использовать альтернативные версии CMake?

    VSCode

    Теперь можно установить VSCode

    Download URL: https://code.visualstudio.com/

    Installation path: в папку по умолчанию

    VSCode plugins

    Далее необходимо поставить в VSCode два плагина:

    • Espressif IDF (espressif.esp-idf-extension)

    • C/C++ IntelliSense (ms-vscode.cpptools)

    Настраивать плагины пока не обязательно, они будут частично настроены после работы мастера настройки Espressif IDF.

    Default Terminal Shell

    Перед тем как продолжить, я настоятельно рекомендую установить CMD как оболочку терминала VSCode по умолчанию. Дело в том, что по умолчанию после установки в VSCode в качестве терминала используется MS PowerShell, но не все скрипты, которые используются в плагине Espressif IDF для работы с фреймворком корректно выполняются в powershell. А в новой версии оболочки PowerShell, которую предлагается скачать и установить, эти скрипты выполняются еще хуже. К тому же далее мы будем использовать в настройках ESP-IDF некоторый лайфхак, который в PowerShell вообще не выполняется.

    Для установки оболочки терминала по умолчанию запустите терминал Terminal ==> New Terminal и выберете окне терминала в выпадающем списке опцию Select Default Shell. Далее выберите в списке Command Prompt … cmd.exe

    Окно терминала теперь можно закрыть.

    Установка ESP-IDF

    Если вы еще не убирали опцию Show Onboarding on Visual Studio Code start в настройках Espressif IDF, то после перезагрузки VSCode и выбора в правой части экрана иконки с логотипом Espressif – автоматически запустится мастер настройки ESP-IDF (далее просто Мастер).

    ESSPRESSIF

    Данный Мастер можно также вызвать командой ESP-IDF: Configure ESP-IDF extension (onboarding.start)

    Теперь можно приступить непосредственно к установке и базовой конфигурации фреймворка и Toolchain.

    Для начала выберем, где хранить настройки фреймворка.

    Для первого раза я рекомендую сохранить настройки непосредственно в пустой папке нового проекта, которую мы предварительно создадим, например здесь: C:\dev\esp32\device01 , и откроем в VSCode. Это немного облегчит понимание, какие настройки, когда и для чего создает данный Мастер, и какие настройки понадобятся еще.

    Для сохранения настроек в нашу папку выберем опцию Workspace folder settings и укажем путь C:\dev\esp32\device01.

    Нажимаем START

    _ User & Workplace

    Небольшое отступление.

    VSCode оперирует двумя типами настроек – глобальными, которые обозначаются как User и локальными, которые обозначаются как Workspace и действуют для конкретного проекта. Есть некоторое несоответствие английских названий смыслу, поскольку User ассоциируется с пользовательскими настройками, но так сложилось исторически, и этот момент нужно просто запомнить, как есть. Мы будем далее называть настройки из раздела User – Глобальными, а из Workspace – Локальными. Если кто-то знает более подходящую терминологию, милости прошу поделиться в комментариях.

    Локальные настройки применяются после Глобальных и имеют над ними приоритет, т.е. при дублировании настроек применяются Локальные.

    Настройки в VSCode можно просматривать как просто текстовые файлы JSON, так и в форме графического интерфейса VSCode. Полезной фитчей последнего является то, что в разделе измененные значения параметров относительно значений по умолчанию подкрашиваются синей полосой. Это упрощает навигацию по параметрам и также позволяет в два клика вернуться к дефолтным значениям.

    Таким образом, те настройки, которые мы получим в результате работы Мастера и сохраним в папке проекта – будут для нас Локальными (Workspace), а в дальнейшем мы перенесем их и в Глобальные (User).

    Select Python version to use

    На данном экране необходимо указать путь к вашей версии Python. Его можно выбрать из выпадающего списка. Иногда скрипты Мастера дают сбой, и после выбора версии Python из списка предлагается снова ввести путь к исполняемому файлу python.exe вручную. Тут ничего нельзя поделать, придется повторить путь вручную.

    Также на экране показана определившаяся в нашей системе версия Git, которую мы поставили ранее.

    Проверяем путь к Python и нажимаем Configure ESP-IDF

    Configure ESP-IDF

    На данном экране необходимо выбрать версию фреймворка ESP-IDF, с которой мы хотим работать (и которая будет далее скачиваться), и указать путь, где фреймворк будет сохранен.

    Можно также выбрать опцию Find ESP-IDF in your system и указать папку с ранее скаченным фреймворком. Именно этой опцией, скорее всего, вы будете пользоваться в дальнейшей повседневной работе.

    Если вы хотите дополнительно использовать в своих разработках класс Arduino, как компоненту проекта, то необходимо выбрать версию ESP-IDF - release/v4.0 (release branch) или v4.0.2 (release version), т.к. фреймворк Arduino-ESP32 доступен сейчас только для версии v3.3, v4.0 и v4.2.

    Однако, v3.3 уже морально устарела, а v.4.2, на мой взгляд, пока еще слишком сырая и не имеет окончательного релиза, хотя к моменту окончания нашей установки она может уже и стабилизироваться.

    Использование более ранних версий фреймворков ESP-IDF и Arduino-ESP32 чем v.4.0 настоятельно не рекомендуется. Чтобы убедиться в этом можно просто ознакомиться с количеством изменений для базового фреймворка v4.0 по сравнению с версиями v3.x https://github.com/espressif/esp-idf/releases/tag/v4.0 , а фреймворк Arduino-ESP32 основывается как раз на базовой версии фреймворка ESP-IDF. Версии ниже v4.0 также плохо поддерживают, или вообще не поддерживают CMake, а все наши дальнейшие изыскания будут связаны именно с этой популярной системой сборки проектов.

    Примечательно, что для Arduino IDE доступен только фреймворк Arduino-ESP32 на версии v.3.3 ESP-IDF, поэтому разработка в нашем окружении VSCode дает несомненное преимущество при работе с классом Arduino, как с компонентой проекта. Правда в этой связке тоже не все так гладко, о чем мы позднее поговорим более подробно.

    Если вы хотите на этапе разработки проекта получать поменьше обновлений для вашего фреймворка, то необходимо выбирать версию (release version), а не (release branch).

    А мы тем временем, выбираем release/v4.0 (release branch), а в качестве пути к фреймворку ESP-IDF укажем папку C:\dev , к которой автоматически добавится адрес \esp-idf .

    Нажимаем Check here to download, после чего начинается процесс загрузки с GitHub.

    Ждем несколько минут и после окончания загрузки внезапно видим ошибку:

    Дело в том, что в плагине Espressif IDF версии 0.5.1 вот уже много месяцев присутствует ошибка для выбора release/v4.0 (release branch) – после загрузки репозитария v4.0 система пытается найти архив для версии 4.0.2

    Будем надеяться, что в будущих версиях эту ошибку исправят. Соответствующую проблему я зарегистрировал на GitHub https://github.com/espressif/vscode-esp-idf-extension/issues/223

    А нам остается только выбрать v4.0.2 (release version) и повторить загрузку.

    После успешной загрузки и распаковки фреймворка Мастер предложит перейти к настройке утилит Toolchain.

    Нажимаем Go to ESP-IDF Tools setup

    ESP-IDF Tools Configuration

    На данном экране выбираем Download ESP-IDF Tools

    Вторая опция выбирается если у вас уже есть папка с предварительно скаченным или клонированным с GitHub фреймворком.

    Теперь необходимо указать папку, в которую будет загружен Toolchain ESP-IDF Tools. Укажем C:\dev\.espressif .

    Обратите внимание, ниже перечислены версии всех утилит, входящих в комплект Toolchain для ESP-IDF v4.0.2 – именно с ними будет гарантироваться работа (компиляция) как самого фреймворка ESP-IDF, так и компоненты Arduino-ESP32 v4.0.

    Tool: xtensa-esp32-elf Version: esp-2020r3-8.4.0

    Tool: esp32ulp-elf Version: 2.28.51.20170517

    Tool: cmake Version: 3.13.4

    Tool: openocd-esp32 Version: v0.10.0-esp32-20200709

    Tool: mconf Version: v4.6.0.0-idf-20190628

    Tool: ninja Version: 1.9.0

    Tool: idf-exe Version: 1.0.1

    Tool: ccache Version: 3.7

    Нажимаем Download

    Ждем несколько минут и в самом конце установки получаем в консоли ошибку:


      ERROR: Failed building wheel for psutil

        ERROR: Command errored out with exit status 1:

        VisualStudio is not installed; get it from http://www.visualstudio.com/en-au/news/vs2015-preview-vs

        error: Microsoft Visual C++ 14.0 is required. Get it with "Build Tools for Visual Studio": https://visualstudio.microsoft.com/downloads/

    ...

    WARNING: You are using pip version 20.2.3; however, version 20.2.4 is available.

    You should consider upgrading via the 'C:\dev\.espressif\python_env\idf4.0_py3.9_env\Scripts\python.exe -m pip install --upgrade pip' command.


    Оказывается, для установки одной из компонент wheel for psutil требуется ее предварительно скомпилировать с участием MS С++14 и именно из состава Visual Studio! Ну кто бы мог подумать?!

    Я не стал пока искать альтернативных решений, а просто перешел по предложенной ссылке https://visualstudio.microsoft.com/downloads/ , скачал и установил VisualStudio.

    После чего вернулся в окно VSCode и снова нажал Download.

    Забегая вперед, скажу, что в этот раз установка ESP-IDF Tools закончилась успешно, все компоненты скомпилировались и установились. Однако мне осталось не ясным, нужен ли для успешной установки именно компилятор С++14 и состава Visual Studio, или подойдет любой другой компилятор С++14, установленный в системе?

    Если у вас не было данной ошибки, значит в вашей системе стояли необходимые компиляторы. Буду признателен, если вы поделитесь описанием вашей конфигурации. С какими компиляторами установка ESP-IDF Tools завершилась у вас удачно?

    (Q3) Вопрос 3: С какими компиляторами С++14, помимо штатного из состава Visual Studio, может успешно завершиться установка ESP-IDF Tools? Нужно ли обязательно при этом иметь в системе установленную программу Visual Studio, или достаточно только компилятора?

    _ PIP

    Перед тем, как вы тоже повторите действия выше с установкой Visual Studio и нажмете Download обратите внимание на последние строчки сообщения об ошибки. Там сказано, что в системе используется устаревшая версия pip в то время, как доступна более новая.

    PIP – это система управления пакетами, которая используется для установки и управления программными пакетами, написанными на Python. На сколько я помню, pip попадает в систему автоматически при установке Python версии > 3.4.

    Я рекомендую перед повторной попыткой установки ESP-IDF Tools устранить это замечание, чтобы данные строки больше не появлялись в консоли и не мешали восприятию сообщений.

    Для этого запустим командную стоку CMD из меню Пуск и введем сначала команду C:\dev\.espressif\python_env\idf4.0_py3.9_env\Scripts\python.exe -m pip install --upgrade pip , а затем python -m pip install --upgrade pip

    Дело в том, что первая команда обновит pip в локальной копии idf4.0_py3.9_env, а вторая команда обновит pip уже в основной системной версии Python.

    _ PIP cache

    Еще один нюанс кроется в кэше pip. Если после всех установок и настроек ESP-IDF вы вдруг решите удалить Visual Studio со всеми дистрибутивами C++, а потом решите повторно запустить мастер настройки ESP-IDF, то процесс установки ESP-IDF Tools пройдет успешно, как ни в чем не бывало. Дело в том, что в процессе предыдущей установки pip сохранил в кэш результаты всех успешных компиляций. Кэш находится по адресу C:\Users\UserName\AppData\Local\pip\cache , и далее, при повторных установках, если в кэше находится файл для утилиты подходящей версии, то он берется именно из кэша. Новые файлы будут компилироваться только для новых версий утилит из Toolchain.

    Для того чтобы провести полную переустановку Toolchain для ESP-IDF, без использования кэша pip, достаточно просто удалить папку C:\Users\UserName\AppData\Local\pip\cache\wheels , это вернет в консоль сообщение о недостающем дистрибутиве С++14, если таковой отсутствует в вашей системе.

    Теперь скачиваем Visual Studio https://visualstudio.microsoft.com/downloads/ , устанавливаем его с одной единственной опцией «Разработка классических приложений на C++», возвращаемся в окно VSCode и…

    Примечание: не стоит пока выбирать опцию Разработка на Python, поскольку это установит в систему еще одну копию Python более низкой версии, что может создать трудности для дальнейшей настройки и работы фреймворка ESP-IDF.

    Возвращаемся на шаг назад, нажав на стрелку влево над надписью ESP-IDF Tools, нажимаем Download ESP-IDF Tools и снова нажимаем Download.

    В случае успешной установки Toolchain станет доступна кнопка Go to next step.

    В логе ниже мы увидим снова предупреждение, что используется устаревшая версия pip. Да как так-то?..

    Дело в том, что если мы отмотаем лог наверх, то найдем сообщение:

    Creating a new Python environment in C:\dev\.espressif\python_env\idf4.0_py3.9_env ...

    Да, Мастер создал новую версию локального окружения Python, в которую поместил версию pip, идущую в комплекте с Toolchain, а не ту, которая установлена и обновлена в системном Python. Почему Мастер не взял системную версию pip – неизвестно. Будем надеяться, что в будущих версиях Матера это поправят.

    Чтобы снова обновить локальную версию pip снова выполняем в командной строке команду C:\dev\.espressif\python_env\idf4.0_py3.9_env\Scripts\python.exe -m pip install --upgrade pip

    Нажимаем Go to next step

    Verify ESP-IDF Tools

    Теперь мастер предлагает нам проверить все абсолютные пути для утилит из Toolchain.

    Обратите внимание, мастер сделал локальную копию нашего Python39 со всеми скриптами и окружением - idf4.0_py3.9_env, и менять этот путь не стоит.

    Также учтите, что несмотря на установленный в системе CMake v3.19 ESP-IDF использует свой CMake v3.13.4, и это доставит нам в дальнейшем некоторые сложности. Заменить путь к CMake более новой версии на данном этапе пока не удастся, т. к. на следующем шаге проверки Мастер укажет на несоответствие версий и не даст завершить настройку. Поэтому оставляем все как есть.

    Нажимаем Click here to check tools exist

    На этом экране Мастер уже сам проверяет, все ли версии утилит, согласно их абсолютным путям, соответствуют версиям, которые с его точки зрения являются правильными.

    Если все соответствует – везде появятся положительные галочки и сообщения … are satisfied.

    Нажимаем Go to next step

    ESP-IDF Tools have been configured

    И вот она, заветная надпись об успешном окончании установки.

    Настройки проекта

    Однако не спешите пока открывать примеры кода. Давайте посмотрим вначале, что же записал мастер настройки ESP-IDF в нашу папу, которую мы указали в самом начале как C:\dev\esp32\device01

    В данной папке появилась папка .vscode с единственным файлом settings.json который содержит всего пять строк:

    {

        "idf.espIdfPathWin": "C:\\dev\\esp-idf",

        "idf.toolsPathWin": "C:\\dev\\.espressif",

        "idf.customExtraPaths": "C:\\dev\\.espressif\\python_env …",

        "idf.customExtraVars": "{\"OPENOCD_SCRIPTS …",

        "idf.pythonBinPathWin": "C:\\dev\\.espressif\\python_env …"

    }

    Это пять основных переменных, которые определяют какой именно фреймворк ESP-IDF и Toolchain будут применяться для компилирования и работы с проектом.

    Но это еще не все настройки, которые нам необходимы.

    Теперь давайте создадим еще одну папку, например C:\dev\esp32\device02 , откроем ее в VSCode и выполним команду ESP-IDF: Add vscode configuration folder, далее будем для краткости называть ее ESP:Avcf. Для выполнения команды нажмите F1 и начните набирать ESP, далее уже можно выбрать команду из списка.

    Теперь в папке .vscode появилось уже 4 файла. Причем в фале settings.json нет переменных, которые мы получили после мастера настройки ESP-IDF. А в фале c_cpp_properties.json как раз есть ссылки на эти переменные с путями к фреймворку и Toolchain.

    Более того, если бы мы выполнили команду ESP:Avcf в нашей первой папке device01, то наши настройки были бы перезаписаны новым файлом settings.json .

    Все дело в том, что, к сожалению, эти две команды работают не совсем взаимосвязано. Мастер настройки ESP-IDF запоминает в переменных среды idf пути к фреймворку и toolchain и сохраняет их, в нашем случае, Локально. А команда ESP:Avcf создает конфигурационные файлы ВСЕГДА используя Глобальные переменные.

    Теперь получается, для того чтобы корректно заработали настройки в c_cpp_properties.json, нам необходимо сохранить наши переменные Глобально? И да, и нет.

    Дело в том, что, как мы уже говорили ранее, параметры Workspace (Локальные) применяются после параметров User (Глобальных), и если и там и там есть одни и те же параметры, то Workspace имеет преимущество перед User и перезаписывает их. Таким образом, мы может как внести наши переменные в User, так и добавить их в наш Workspace, после параметров, созданных командой ESP:Avcf, в низ файла settings.json, непосредственно в папку .vscode в нашей папке проекта . И то и другое будет работоспособно.

    Однако, если вы ведете совместную разработку проекта, например на GitHub, то вам я рекомендую обязательно внести все настройки в файл settings.json в самом проекте, чтобы гарантировать себе, что проект будет собираться в одном и том же фреймворке и Toolchain у всех участников разработки.

    В свою очередь, если вы сохранили настройки для какого-то конкретного фреймворка и Toolchain Глобально, то не забудьте об этом, когда будете пробовать собирать проект в другом фреймворке.

    Внести настройки переменных idf в User можно как вручную, так и еще раз запустив Мастер, выбрав в самом начале опцию User settings и далее указав папку уже со скаченным фреймворком ESP-IDF.

    Но в начале давайте откроем один из примеров кода и попробуем скомпилировать его с Локальными настройками.

    ПРИМЕРЫ КОДА и КОМПИЛЯЦИЯ

    Чтобы открыть библиотеку примеров кодов ESP-IDF выполним команду ESP-IDF: Show ESP-IDF Examples Projects.

    В открывшемся списке выберем проект get-started\blink и нажмем кнопку Crate project using example blink. Разместим проект в папке esp32.

    Теперь откроем файл .vscode\settings.json и добавим в конец файла наши настройки из папки device01. Будьте внимательны с синтаксисом JSON, не забудьте про запятые и фигурные скобки.

    Теперь перейдем на фаqл с кодом проекта main\blink.c .

    Обратите внимание, после открытия проект содержит две проблемы - BLINK_GPIO и portTICK_PERIOD_MS подкрашены красным системой проверки синтаксиса C/C++ IntelliSense. Мы разберем этот момент чуть позже, следующей статье про тонкие настройки окружения VSCode.

    А сейчас выполним команду ESP-IDF: Build your project.

    Первый процесс компиляции занимает несколько минут, поскольку создается папка build, последующие будут происходить значительно быстрее. В конце компиляции появится сообщение Build Successfully. Это значит, наши Локальные настройки применились успешно.

    К сожалению, в случае компиляции проекта командой ESP-IDF: Build your project не происходит отображения лога компиляции в окне терминала. Но можно выполнить эту команду другим способом, из меню Terminal => Run Task… => Build – Build project или Terminal => Run Build Task…

    Если окно терминала не было открыто, оно откроется автоматически и в конце компиляции в терминале появится сообщение Project build complete. To flash, run this command:..

    Выполнение команд из меню Terminal обеспечивается скриптами в файле .vscode\task.json , но их ход выполнения немного отличается от аналогичных команд через меню F1, например ESP-IDF: Build your project.

    На этом мы пока прервемся – мы смогли сделать базовую настройку плагина Espressif IDF для работы с VSCode и успешно скомпилировали один из примеров кода из библиотеки фреймворка.

    В следующей статье мы займемся более тонкой настройкой окружения VSCode и самого фреймворка – рассмотрим утилиту menuconfig, новые скрипты для task.json и решим проблему с не всегда корректной подсветкой синтаксиса IntelliSense, также рассмотрим выполнение команд фреймворка из командной строки.

    Комментарии 14

      0

      Python проще из аппстора установить. Легче обновлять версии будет.

        0
        На сколько я знаю, аппстор не предлагает выбрать путь установки. Это создает некоторые сложности… Также я помню, что например Arduino IDE, установленное из аппстора, имеет ограниченный функционал в плане поддержки плагинов и не поддерживает консольное исполнение. В общем, к аппстору есть вопросы…
        0
        Спасибо за подробную инструкцию. На mac на сколько я понимаю, не проверяли и есть большая вероятность, что не заведется из за psutil?
          0
          Да вот не факт как раз. Судя по описанию https://github.com/espressif/vscode-esp-idf-extension плагин работает с MacOS, а значит будет ставить правильный Toolchain. Сами разработчики Espressif сидят на Linux, даже под Win профиль плагина по умолчанию маркируется как Linux. Таким образом, по идее, должно работать во всех осях)) MacOS действительно пока не проверял, под Linux тестировали фреймворк v4.0 из консоли, работает.
          +1

          Dev-среда под windows для меня исторически гораздо больший геморрой, чем всё остальное, поэтому vscode у меня на Винде, а вот SDK esp-idf (и вообще вся разработка) — в WSL2; а так как WSL2 пока не умеет пробрасывать в себя usb/com-порты, то для подключения к микроконтроллеру я использую дополнительную WSL1 среду на базе Alpine, единственная задача которой — быть сервером для удаленного COM-порта (но, похоже, уже есть более простое решение — idfx). Единственное неудобство: нужно при перепрошивке кнопку нажимать для загрузки во flash-mode.

            0
            А почему вы VSCode под Винду ставите, есть же сборка под Linux? code.visualstudio.com/download
            Или поясните чуть подробнее, пожалуйста. Зачем вообще стек Linux поверх стека Win? Ведь IDE и фреймворк ест и работают сразу в стеке Linux.
              +1

              Я за свою жизнь годами работал на разных OS (и на рабочих станциях\ноутбуках, и на серверах) и пришёл к выводу, что если у меня компьютер не Apple, то в MacOS на нём особого смысла нет (и зачастую это не стоит того времени, которое нужно потратить, чтобы завести hackintosh), а Linux всё-таки имеет некоторые проблемы с поддержкой современного железа: к примеру, в последний раз я вернулся на Windows с Linux после нескольких лет использования из-за того, что сменил ноутбук, в результате на внешнем мониторе картинка 1920x1080, на встроенном — 3200x1800 и HiDPI, и постоянно возникали проблемы. В Windows таких проблем нет. Плюс больше софта, который нужен мне. Основной софт, конечно, один и тот же (я использую LibreOffice, Inkscape, GIMP etc), но вот всякие мелочи — их часто не бывает под Linux, зато есть под Win. Плюс различный софт для доступа к гос. органам и бизнес-софт. Это всё на тему "почему я вообще использую Windows".


              Теперь о разработке. С разработкой ситуация противоположная: инструментов, которые без танцев с бубном нормально работают "из коробки" под *nix гораздо больше, чем под Win. Какое-то время я работал с виртуалкой под Hyper-V, на которой был Linux с GUI. Но это не очень удобно. Работал и в режиме удалённого X-сервера (об этом см. ниже). Потом появился WSL (Windows Subsystem for Linux), и я практически сразу начал его использовать. WSL1 — это транслятор POSIX API в Win API (эдакий wine наоборот), кастомное ядро Linux, и работает он в целом хорошо, однако из-за определённых особенностей работа с файловой системой довольно медленная. А при сборке это имеет огромное значение. Плюс не все вызовы реализованы, поэтому кое-какой софт всё-таки не работал (но я с этим почти не сталкивался). Потом появился WSL2, где они отказались от прямой трансляции вызовов, теперь это крайне легковесная виртуалка под Hyper-V, а поэтому там всё работает очень быстро. Кстати, всё остальное — это совершенно обычный и никак не изменённый дистрибутив: скажем, Ubuntu (я пользуюсь в WSL Ubuntu) или Alpine (который я ставил под WSL1, чтобы пробрасывать COM-порт по tcp в Ubuntu на WSL2, потому что в WSL2 пока нет возможности работать с периферией Windows).


              Но и в WSL1, и в WSL2 для того, чтобы работать с GUI с родным Linux-софтом нужно на Windows запускать X-сервер, прописать переменную окружения, чтобы линуксовый софт понял, что нужно GUI показывать на удалённом сервере, и, само собой, это всё работает не совсем прямо и быстро. Поэтому я сначала просто открывал проекты из виндового VSCode, но расположенные внутри линукс-директорий, что свои проблемы добавляло. А потом в VSCode появилась возможность работать с remote-сервером, в результате у меня GUI родной виндовый, быстрый, отзывчивый, со всеми своими плюшками, а вот все плагины, процессы и т.п. запускаются прямо средствами vscode внутри WSL. Точно так же это может быть какая-то удалённая Linux-машина, физическая или виртуальная, но зачем, если есть WSL?


              В результате всё это выглядит как-то так



              Тут же пример Linux GUI под винду с запущенным X-сервером — окошко на переднем плане как раз оно:

                0
                Потрясающе! Я как-то пока настороженно относился к WSL, мне казалось, что это больше маркетинговый ход Microsoft для переманивания аудитории.
                У нас на работе как раз есть задача — предоставить серверу в офисе доступ к COM портам на удаленных ноутбуках, для прямого доступа к периферии ноута. Я правильно понимаю, что с WSL1 это сделать получается легко и просто?
                У вас нет случайно ссылки на кокой-то хороший ресурс, чтобы именно эту тему с пробросом портов посмотреть?
                  +1

                  Не уверен, что именно легко и просто, но это нужно пробовать. Если говорить именно о esp-idf, то у инструментария есть поддержка RFC 2217 (Telnet COM port control option). Теоретически есть родной софт прямо под Windows, который реализует rfc2217, но я почему-то год назад не нашёл ничего на эту тему, поэтому сделал всё через дополнительный инстанс WSL1 с rfc2217-сервером. Только что под ваш вопрос нашёл как раз заметки на тему работы с удалённым COM-портом, в том числе под Windows. Возможно, вам и WSL не понадобится — там вон ссылка на какой-то com0com есть в числе прочих — "нуль-модемный виртуальный кабель".


                  А если говорить непосредственно об ESP-IDF, то за год с тех пор, как я впервые всё это настраивал появился вот такой проект, который позволяет для прошивки\мониторинга прямо из-под WSL2 вызывать esptool, установленный на Win. Но, понятное дело, в этом случае всё равно приходится устанавливать python и esptools на Windows. Зато всё остальное под Linux, что не может не радовать.


                  А в целом, конечно, у WSL есть ещё свои проблемы, но инструмент для меня лично очень полезный и используемый в ежедневном режиме.

            +1

            Тоже недавно настраивал работу с esp-idf из VSCode на windows. Очень удобно использовать esp-idf в docker и возможности vscode по работе с remote контейнерами. С контейнерами усилия по установке для новых пользователей сводятся к установке и настройке vscode.

              +3
              Прошу прощения, случайно удалил коммент про PlatformIO, никак не привыкну к акцепту комментов…
              Я исторически считаю PlatformIO непригодным для серьезных или коммерческих проектов. PlatformIO имеет свою собственную, какую-то проприетарную систему настройки проектов. Т.е. например, чтобы заставить проект или компоненту компилироваться в С++17, вы лезете в какие-то собственные настройки PlatformIO platformio.ini вместо того, чтобы либо поправить настройки фреймворка, либо добавить в CMakeLists.txt параметр component_compile_options(-std=c++17).
              На мой взгляд, это какая-то лютая дичь, которая ставит крест на простую миграцию проекта между разными IDE. Проект в VSCode совершенно одинаково будет компилироваться как из-под плагина, так и из командной строки idf.py build, и даже в Eclipse проект заезжает почти as-is, при наличии в Eclipse плагина от Espressif.
              Наверно, PlatformIO это больше про обучение всему и вся, всегда все под рукой.
                +1
                Наверно, PlatformIO это больше про обучение всему и вся
                Увы, но они себя иначе позиционирует — «для разработчиков» :)) С вами полностью соглашусь, любая лишняя прослойка настроек и привязка с ide или к чему-то еще изначально убивает продукт для более менее серьезной разработки.
                  –1

                  А почему важна простая миграция проекта между ide? Так ли часто возникает необходимость переезжать в другую ide во время активной разработки проекта?

                    +2
                    Достаточно часто полагаю. Я пишу в VS Code + GCC, а заказчик или подрядчик работает в Keil. Иметь возможность собрать проект и вести разработку быстро и без костылей неплохой такой бонус. Или же вы свой проект выкладываете на github, скорее всего у многих будет другая среда разработки. Если же вы работаете один или задачи чисто бытовые, то тогда привязка к ide не должна особо волновать

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое