Comments 17
Python проще из аппстора установить. Легче обновлять версии будет.
Dev-среда под windows для меня исторически гораздо больший геморрой, чем всё остальное, поэтому vscode у меня на Винде, а вот SDK esp-idf (и вообще вся разработка) — в WSL2; а так как WSL2 пока не умеет пробрасывать в себя usb/com-порты, то для подключения к микроконтроллеру я использую дополнительную WSL1 среду на базе Alpine, единственная задача которой — быть сервером для удаленного COM-порта (но, похоже, уже есть более простое решение — idfx). Единственное неудобство: нужно при перепрошивке кнопку нажимать для загрузки во flash-mode.
Или поясните чуть подробнее, пожалуйста. Зачем вообще стек 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-сервером — окошко на переднем плане как раз оно:
У нас на работе как раз есть задача — предоставить серверу в офисе доступ к 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 имеет свою собственную, какую-то проприетарную систему настройки проектов. Т.е. например, чтобы заставить проект или компоненту компилироваться в С++17, вы лезете в какие-то собственные настройки PlatformIO platformio.ini вместо того, чтобы либо поправить настройки фреймворка, либо добавить в
CMakeLists.txt параметр component_compile_options(-std=c++17). На мой взгляд, это какая-то лютая дичь, которая ставит крест на простую миграцию проекта между разными IDE. Проект в VSCode совершенно одинаково будет компилироваться как из-под плагина, так и из командной строки
idf.py build, и даже в Eclipse проект заезжает почти as-is, при наличии в Eclipse плагина от Espressif.Наверно, PlatformIO это больше про обучение всему и вся, всегда все под рукой.
ESP32 в окружении VSCode