Открыть список
Как стать автором
Обновить

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

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

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

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

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

Я за свою жизнь годами работал на разных 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-сервером — окошко на переднем плане как раз оно:

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

Не уверен, что именно легко и просто, но это нужно пробовать. Если говорить именно о 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 есть ещё свои проблемы, но инструмент для меня лично очень полезный и используемый в ежедневном режиме.

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

Прошу прощения, случайно удалил коммент про 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 это больше про обучение всему и вся, всегда все под рукой.
Наверно, PlatformIO это больше про обучение всему и вся
Увы, но они себя иначе позиционирует — «для разработчиков» :)) С вами полностью соглашусь, любая лишняя прослойка настроек и привязка с ide или к чему-то еще изначально убивает продукт для более менее серьезной разработки.

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

Достаточно часто полагаю. Я пишу в VS Code + GCC, а заказчик или подрядчик работает в Keil. Иметь возможность собрать проект и вести разработку быстро и без костылей неплохой такой бонус. Или же вы свой проект выкладываете на github, скорее всего у многих будет другая среда разработки. Если же вы работаете один или задачи чисто бытовые, то тогда привязка к ide не должна особо волновать
Подскажите нормально ли мигрируются проекты между Keil и GCC? Вроде в кейле заморочки именно свой компилятор как пишут промышленного стандарта. Да и система сборки у кейла своя через s и таргет. Или какие-то сложности и костыли приходится заморачиваться? В кейле насколько знаю нет make
Спасибо за статью. С нее и начну работать с esp32 без pLatformio. PlatformIO вроде быстрый вход но потом… Жду новых статеек. А пока буду помаленьку осваивать примеры. У меня были установлены VS CODE, VS, и PYTHON 3.9 Версию установил 4.02. В общем все зашло быстро и без ошибок. Буквально минут за 30 ушло на все до компиляции блинка. Еще раз спасибо за статью.
А у меня как-то не так гладко. Во-первых, интерфейс настройки заметно отличается, а, во-вторых, при попытке компиляции вылетает с ошибкой «No such file or folder» — не может найти инклюды.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.