[Bug Report]: Total failure on Linux (Mint 20) (VSC-756)
See original GitHub issue** Here’s the TL; DR.**
Windows 10_: worked first time, without issue. Smooth sailing, no questions asked. Linux (Mint): A wasted afternoon and evening battling errors with Python, Pip and ultimately CMake and still doesn’t work even after following some excellent guides that pointed to less than obvious problems
Queue another angry review on the VS Studio extensions which was truncated by about 50% because I’d already included a lot of detail about why this is an issue. I’ve cooled off a bit now but this is a serious problem for anyone using VSCode on Linux especially if they aren’t “up” on Python and the weirdness in the naming systems since Python3, not to mention CMake.
I read and followed the install guide (I note others have to with similar failures) and that’s obviously only part of the problem. The main issue is lack of automation. What’s needed is an absolute beginner (preferably someone who doesn’t code) to follow your instructions (without knowledge of how to fix issues) and see where they walk into tripwires. You’ll find this is a much faster way to find problems before the public at large start screaming at you and leaving 1* reviews. Believe it or not, I’d much prefer to leave a 5* any day of the week.
Consider the prerequisites for example. Windows is essentially just VSCode, Linux needs CMake, Ninja-build and others that I’ll admit that I never heard of. Lacking knowledge a prori is often enough to stop someone in their tracks and the only reason I persisted was because I’d had some code working in PlatformIO and witnesses just how good this is.
Make no mistake: the ESP32 is an excellent piece of “silicon” that trounces pretty much everything in its wake like Godzilla wading through a matchstick village but, and this is important, devs are busy people. Open Source devs often work in their free time which is at a premium and this is alpha quality software on Linux. Even at my age, I’m not scared to learn something new (FreeRTOS in this case) but I don’t need the installer to throw me under the bus while my friends on Windows look at me and laugh like Nelson Muntz.
I prefer Linux for any number of reasons (privacy, FOSS, etc.) and although it’s generally not for everyone, even developers aren’t necessarily experts in everything.
The Bug
There are (apparently) many - so it’s impossible to know where to start. The documentation isn’t clear about the per-requisites, even the fact that it doesn’t work with Python3 because the system expects to see python3 (or pip3) and only python and pip are available. Not that hard to rectify but it’s a gotcha that simply shouldn’t be there.
To Reproduce Quite literally tried to run the installer. I thought I had all the prerequisites in place and even after I’d followed an independent YouTube: https://www.youtube.com/watch?v=Jt6ZDct4bZk and I’m not alone.
Expected behavior
I expected it to install in the same way as it did on Windows, smoothly and flawlessly. I’ve had to move development to Windows which isn’t terribly inconvenient but it’s something I didn’t want to have to do and I was lucky enough to have a Windows box languishing in a corner.
Environment
Linux Mint: 20.2 (X64 Generic 5.4.0-84) VSCode: 1.60.1 ESP-IDF: 4.3.1 Python: 3.8 Python Pip: 21.2.4
“You can use the ESP-IDF: Doctor command
to generate a report of your configuration.”
This is another example of knowledge a priori folks. As it happens I had a clue where to find this from doodling around most of the afternoon, but I’m no expert on VSCode. It’s a tool, I’ve learned what I needed to learn to complete my tasks efficiently. I didn’t know this existed until I read it here. This is why people are choking on the Linux installer, it makes far too many assumptions about what’s already present and knowledge of how to fix them. This isn’t 1980 Linux any more.
This is the closest I got to a working system. PlatformIO was (and still is) successfully compiling code for the ESP32 on the same VSCode installation but I really need to keep one for Arduino and one for ESP and the ESP IDF has features I that PIO doesn’t offer.
---------------------------------------------- ESP-IDF Extension for Visual Studio Code report --------------------------------------------- OS linux x64 5.4.0-84-generic System environment variable IDF_PYTHON_ENV_PATH undefined System environment variable PATH /home/marc/.local/bin:/home/marc/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin System environment variable PYTHON undefined Visual Studio Code version 1.60.1 Visual Studio Code language en Visual Studio Code shell bash ESP-IDF Extension version 1.2.0 ---------------------------------------------------- Extension configuration settings ------------------------------------------------------ ESP-ADF Path (idf.espAdfPath) ${env:ADF_PATH} ESP-IDF Path (idf.espIdfPath) /home/marc/esp/esp-idf ESP-MDF Path (idf.espMdfPath) ${env:MDF_PATH} Custom extra paths (idf.customExtraPaths) /home/marc/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin:/home/marc/.espressif/tools/xtensa-esp32s2-elf/esp-2021r1-8.4.0/xtensa-esp32s2-elf/bin:/home/marc/.espressif/tools/xtensa-esp32s3-elf/esp-2021r1-8.4.0/xtensa-esp32s3-elf/bin:/home/marc/.espressif/tools/riscv32-esp-elf/esp-2021r1-8.4.0/riscv32-esp-elf/bin:/home/marc/.espressif/tools/esp32ulp-elf/2.28.51-esp-20191205/esp32ulp-elf-binutils/bin:/home/marc/.espressif/tools/esp32s2ulp-elf/2.28.51-esp-20191205/esp32s2ulp-elf-binutils/bin:/home/marc/.espressif/tools/openocd-esp32/v0.10.0-esp32-20210401/openocd-esp32/bin Custom extra vars (idf.customExtraVars) {"OPENOCD_SCRIPTS":"/home/marc/.espressif/tools/openocd-esp32/v0.10.0-esp32-20210401/openocd-esp32/share/openocd/scripts"} Virtual env Python Path (idf.pythonBinPath) /home/marc/.espressif/python_env/idf4.3_py3.8_env/bin/python Serial port (idf.port) /dev/ttyUSB0 OpenOCD Configs (idf.openOcdConfigs) interface/ftdi/esp32_devkitj_v1.cfg,target/esp32.cfg ESP-IDF Tools Path (idf.toolsPath) /home/marc/.espressif Git Path (idf.gitPath) git -------------------------------------------------------- Configurations access ------------------------------------------------------------- Access to ESP-ADF Path (idf.espAdfPath) false Access to ESP-IDF Path (idf.espIdfPath) true Access to ESP-MDF Path (idf.espMdfPath) false Access to ESP-IDF Custom extra paths Access to /home/marc/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin: true Access to /home/marc/.espressif/tools/xtensa-esp32s2-elf/esp-2021r1-8.4.0/xtensa-esp32s2-elf/bin: true Access to /home/marc/.espressif/tools/xtensa-esp32s3-elf/esp-2021r1-8.4.0/xtensa-esp32s3-elf/bin: true Access to /home/marc/.espressif/tools/riscv32-esp-elf/esp-2021r1-8.4.0/riscv32-esp-elf/bin: true Access to /home/marc/.espressif/tools/esp32ulp-elf/2.28.51-esp-20191205/esp32ulp-elf-binutils/bin: true Access to /home/marc/.espressif/tools/esp32s2ulp-elf/2.28.51-esp-20191205/esp32s2ulp-elf-binutils/bin: true Access to /home/marc/.espressif/tools/openocd-esp32/v0.10.0-esp32-20210401/openocd-esp32/bin: true Access to Virtual env Python Path (idf.pythonBinPath) true Access to CMake in environment PATH true Access to Ninja in environment PATH true Access to ESP-IDF Tools Path (idf.toolsPath) true ----------------------------------------------------------- Executables Versions ----------------------------------------------------------- Git version 2.25.1 ESP-IDF version 4.4 Python version 3.8.10 Python's pip version 21.2.4 -------------------------------------------------- Python packages in idf.pythonBinPath ---------------------------------------------------- bitstring version: 3.1.9 Brotli version: 1.0.9 certifi version: 2021.5.30 cffi version: 1.14.6 charset-normalizer version: 2.0.5 click version: 8.0.1 construct version: 2.10.54 contextlib2 version: 21.6.0 cryptography version: 3.4.8 ecdsa version: 0.17.0 Flask version: 0.12.5 Flask-Compress version: 1.10.1 Flask-SocketIO version: 2.9.6 future version: 0.18.2 gcovr version: 5.0 gdbgui version: 0.13.2.0 gevent version: 1.5.0 greenlet version: 1.1.1 idf-component-manager version: 0.2.100b0 idna version: 3.2 itsdangerous version: 2.0.1 Jinja2 version: 3.0.1 kconfiglib version: 13.7.1 lxml version: 4.6.3 MarkupSafe version: 2.0.1 pip version: 21.2.4 psutil version: 5.8.0 pycparser version: 2.20 pyelftools version: 0.27 pygdbmi version: 0.9.0.2 Pygments version: 2.10.0 pyparsing version: 2.3.1 pyserial version: 3.5 python-engineio version: 3.14.2 python-socketio version: 4.6.1 PyYAML version: 5.4.1 reedsolo version: 1.5.4 requests version: 2.26.0 requests-toolbelt version: 0.9.1 schema version: 0.7.4 semantic-version version: 2.8.5 setuptools version: 58.0.4 six version: 1.16.0 tqdm version: 4.62.2 urllib3 version: 1.26.6 websocket-client version: 1.2.1 Werkzeug version: 0.16.1 wheel version: 0.37.0 xmlrunner version: 1.7.7 ---------------------------------------------------- Check ESP-IDF python requirements.txt ------------------------------------------------- Check ESP-IDF Python packages Python requirements from /home/marc/esp/esp-idf/requirements.txt are satisfied. ---------------------------------------------------- Check extension requirements.txt ------------------------------------------------------ Check Extension Python packages Python requirements from /home/marc/.vscode/extensions/espressif.esp-idf-extension-1.2.0/requirements.txt are satisfied. ---------------------------------------------------- Check ESP-IDF debug adapter requirements.txt ------------------------------------------ Check Debug AdapterPython packages Python requirements from /home/marc/.vscode/extensions/espressif.esp-idf-extension-1.2.0/esp_debug_adapter/requirements.txt are satisfied. ---------------------------------------------------- Visual Studio Code launch.json -------------------------------------------------------- { "version": "0.2.0", "configurations": [ { "type": "espidf", "name": "Launch", "request": "launch" } ] } ---------------------------------------------------- Visual Studio Code c_cpp_properties.json ---------------------------------------------- { "configurations": [ { "name": "ESP-IDF", "compilerPath": "/home/marc/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc", "cStandard": "c11", "cppStandard": "c++17", "includePath": [ "${config:idf.espIdfPath}/components/**", "${config:idf.espIdfPathWin}/components/**", "${config:idf.espAdfPath}/components/**", "${config:idf.espAdfPathWin}/components/**", "${workspaceFolder}/**" ], "browse": { "path": [ "${config:idf.espIdfPath}/components", "${config:idf.espIdfPathWin}/components", "${config:idf.espAdfPath}/components/**", "${config:idf.espAdfPathWin}/components/**", "${workspaceFolder}" ], "limitSymbolsToIncludedHeaders": false } } ], "version": 4 }
Issue Analytics
- State:
- Created 2 years ago
- Comments:10
Top GitHub Comments
I understand and I do understand the frustration at either end.
I’m currently running some “idiot” tests with VSCode plus PlatformIO and Esp.Idf to see what happens on a vanilla install. This will hopefully give you a better view of what it’s like here out on the ice in a pair of training wheels.
Life got in the way today (as it does) but I did manage to see PlatformIO prompt for an incorrect/incomplete version of Python on Ubuntu 20.4. The installer presented a link to the solution (on Github, naturally) which was simply a matter of running a single command line. PlatformIO won’t install unless that’s done. Python seems to be going the way of PHP in regards to moving the goalposts for developers and that’s something they need to look at. It’s all very well having the latest features, but it’s poor show when lack of forethought breaks huge swathes of existing code.
So far this is a benchmark for me and while I find having to drop back to a terminal to “sudo” something I’m aware that it’s probably impossible to gain elevated privileges while in VSCode.
This isn’t particularly painful because Linux does put more barriers in the way that Windows and is therefore (I hope) more secure. Although I was recording this, the virtual machine ran out of disk space so I’ll have to start again and make notes as to what was needed.
My next “challenge” (to the installers) is to put the Arduino and Espressif toolchains on and run some simple sample code (like a Blink sketch) to ensure that the basic environment is present and correct.
PlatformIO did compile Arduino code without a hitch as expected but I “broke” the install before I’d tested ESP.IDF.
I’ll be sure to get some screenshots at times when/if the wheels come off and try to locate the diagnostics - but I should reiterate, that most developers (particularly those coming from Arduino) will expect a considerable level of automation and not be presented with hundreds of lines of crud when something goes wrong (cough) CMake (cough). We need to be eased in gently.
Let’s use an analogy which I’ll put into quote text for clarity.
I would also refer to to Dr. Daniel Kahneman’s book, “Thinking, fast and slow” for a more detailed introduction to this problem from the standpoint of a teacher and psychologist. All developers should at least attempt to read it at least once.
Kahneman’s key argument is the separation of the “automatic” brain, system 1 and the slower analytical brain, system 2. As developers gain experience more and more work is handed off (or handled by) system one which uses a sort of binary divide and conquer approach to finding the right answer quickly.
I’m sure you know yourself that a binary search is almost always the fastest way to locate something if the data is presented in such a way that such a search is practical. When compared to a more nuanced analytical approach, the binary search either finds an answer or gives up. In our brain this uses very few cognitive resources and developed as an evolutionary approach to keeping us alive (I’ll save you the details).
When System 1 fails to find an answer, it gives up and hands it to the much slower but more complex System 2 cognition.
For a simple maths question.
Find the square root of 9. Easy right? That’s system 1 finding the answer.
Now find the root of PI. Not quite so simple, so System 1 hands that off to System 2 which then finds itself overwhelmed with a problem it doesn’t know how to face (short of grabbing a calculator).
We see these effects our entire lives as we learn new skills and our minds program System 1 with better and better solution maps that it can use to get instant answers to problems.
Think of when you learned to drive (apologies if you don’t). As your skill improves, System 2 (slow) gives way to System 1 (fast). So that when you are faced with a complex, developing situation in front of you such as a car skidding out of control, system 1 takes command of the steering and brakes while system 2 has some free resources to expend looking for a route through the chaos. The more experienced driver is far less likely to crash for precisely these reasons.
In commercial aviation we speak of a “sterile cockpit” which is designed to keep the pilot’s workload to the minimum during periods where the aircraft requires more input than the autopilots can handle (traditionally takeoff and landing). When sterile cockpit procedures are ignored or forgotten and something unexpected happens, even the world’s best pilots can find themselves overwhelmed by the amount of information they are dealing with. No amount of training can prepare anyone for every situation and this is a the cause of many of the worst aviation disasters; including those where the software has failed (recently 737 Max), critical instrumentation or systems have failed (too many to mention) or pilots simply made a mistake that created a chain of events that became unrecoverable. I could give you many, many examples - probably enough to put many off flying altogether but it’s still the safest form of transport when we look at passenger miles traveled.
This brings us back to where we came in (sorry for the essay, I’m hoping this will help others understand this problem better too). Humans can only take in a limited amount of information before our brains are overloaded. When our visual cortex comes into play, as in most situations including programming, we don’t have much cognitive horsepower left to spare. The result of this is that when we’re faced with screens of rapidly scrolling debugging data, we just become overwhelmed and can’t deal with it. Same if we’re told to refer to this file and this page and then… etc.
Some people are naturally more gifted than others and develop system 1 (fast) analytics more readily than others leaving more resources available to system 1 (slow).
In fact, in closing, this brings me nicely to the project I’m designing right now which requires an HF (>100 KHz) sine wave.
I spent a few days working on and testing various oscillators (Wein bridge, Colpitts, Clapp, phase shift…) so see which would give me the most stable, low distortion (low harmonic) for the fewest parts.
Now you’re probably thinking, “why not use the cosine generator” right?
Well to being with, coming from the Atmel chips, I wasn’t aware of it so I tried using the CPU to drive the DAC using a lookup table.
Can you see where this is going? The CPU doesn’t have anywhere near the performance to produce a wave (not even an 8-bit one) on the DAC at frequencies much above a few KHz. This is fine for the other part of the project but it left me wondering if I could use a simpler square wave with a 50% duty cycle (much lower on resources) and then feed that through a four pole Salen-Key filter to slice off all those nasty odd harmonics. Yeah, it works, but it’s an appalling solution and never as good as a pure sine generator.
But wait!
The ESP32 has cosine generator that only needs to be register programmed and one you start it, it runs - we’ve tested it well above 200KHz - it’s completely independent of the CPU, leaving the processor(s) to do the thinking. This is like out brain’s system 1. It takes care of the simple stuff - a clean sine - while the CPU (system 2) is free to perform actual tasks that involve decisions and occasional interrupts.
Brilliant hardware to which I owe the designers a debt of gratitude! This is going to make a tough design a lot simpler with fewer parts and better performance at a low cost.
To recap: how much of that did you already know? There’s only about 1500 words here - about a page and half of a typical magazine and a short-form essay and I’ve only scratched the surface. But most of us will only get about 20% of it at first pass - which is why I rail against this “read the friendly manual” approach. I didn’t have to look anything here up on the web, I’ve already learned it (except for Dr. Kahneman’s name, I always misspell that). But if you skipped anything or had to look it up, you’re guilty as the rest of us of being 100% human! Reading for many is quite difficult because it requires all our visual cortex (you can’t read with your eyes shut!) which is the most intense single use of sensory cognitive resources AND other parts of our noodle to process the text, formulate and file the information. People like me with reading difficulties (yes, you did read that right) are doubly compromised in this regard so we find other short cuts. Pictures are easier than words because our brains evolved vision to decode images rapidly. Communication such as the written word is useful but it’s a relative newcomer in the evolutionary timeline - perhaps the Egyptians had the “write” idea?
TL;DR
Let’s fix this together! I’m willing to help as much as I can.
As you mentioned we added prerequisites link in the extension setup wizard. When
cmake
,ninja-build
or python are not in the system this message is shown. After runningsudo apt-get ...
you’ll seeand follow express or advanced steps. I tested this on a fresh linux computer.