[Bug Report]: Total failure on Linux (Mint 20) (VSC-756)

[marcdraco]

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 }

[brianignacio5]

As mentioned in the ESP-IDF Prerequisites for Linux you just need to run this line (for debian/ubuntu distro for example) in the terminal:

sudo apt-get install git wget flex bison gperf python3 python3-pip python3-setuptools cmake ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0

When you are using the extension setup, you choose which python binary found in the system using which -a python; which -a python3.

Based on your doctor command output your extension configured.

Can you describe in detail what issue did you encountered ? We are sorry the experience hasn't been smooth enough but automating the whole setup for macOS and Linux we are still facing some challenges.

[marcdraco]

I already did that Brian - it's detailed quite well in one of the Internet videos that I've linked above and still fails for many people.

This video also details the Python gotchas (which, for someone like me who has been in IT for over four decades) is unforgivable. I can imagine people saying "How dare he..." well he dare because he grew up around systems that were in constant flux and watched as programmers and sys analysts started to realise that these sort of things cost time and time's money.

I'm aware the old joke about "The great thing about standards is there are so many to chose from!" but this is precisely the sort of thing that we have the automation to deal with. The APT system used by Debian and similar package managers for other distros do these things and when there's a potential conflict we're prompted on how to proceed.

What I'm seeing is alpha quality software compare to the Windows variant and that's not good for anyone.

Worse still, the Arduino framework also works flawlessly on Linux & Windows so far as I can tell but that puts some "help" into that makes us a bit lazy. My current project doesn't need RTOS so I'm actually going to use that (under PlatformIO or I'll remove what little hair I have left).

Compounding that seems to be a tendency to victim blame users on the VSCode reviews. I get it, it's frustrating as hell, but when you know there are issues you need to put this up ("this is alpha, not for production") up front!

Similarly the pre-requs. That can and should be addressed by the installer in the background or it needs a very, very prominent warning somewhere. I did find that (eventually) but I'd already failed several times using the normal installer ignorant of that fact. Again, automation has made us a bit lazy in this regard but remember that the Arduino version works just fine.

These issues are what I'm referring to when I say "a priori" - knowledge ahead of time in other words. Users coming in cold just expect it to work and when they fall on their face (as I and others did) we get mad. No one has time to go wading through pages of documents to get things running, we want to start coding ASAP. Reading the register descriptions for example (I spent several hours annoying the cat last night doing just that while she tried to sleep) is entirely different. We all expect to have to read those documents (or we should) because that's our job to figure out how to code for what we're trying to achieve.

I honestly feel for you guys. Linux is a bit of a moving target (as is MacOS) but there are people out here who will lend a hand to test things and tell you when the wheels come off. Myself included.

TL;DR

Perhaps you could offer some sort of beta program (and yank the current extension before it wrecks Espressif's reputation)?

I for one would be quite happy to use a spare Linux boot drive to flash a vanilla Ubuntu, Mint, Debian etc. distro and run your step-by-step guides every so often, reporting back when I hit the roadblocks. I'm sure others would too because it's in OUR interests to get this up and running just as much as it's in yours (as volunteers or professional devs.)

I really love the silicone and I'm desperate to get some cool apps out there but as things stand I'm beholden to the sketchy Arduino framework (rimshot) which lacks the speed for more detailed tasks.

[brianignacio5]

I already did that Brian - it's detailed quite well in one of the Internet videos that I've linked above and still fails for many people.

Let me breakdown the bug section:

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.

It's is impossible to know where to start ? Readme

The documentation isn't clear about the per-requisites Readme's prerequisites

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 The extension setup shows you a list of python binaries available in PATH for you to select by default or manually set the python binary path. This is done by running which -a python; which -a python3. This means we do support python and python3 aliases. What do you mean it doesn't work with python3 ? What error do you see ?

Again, what errors did you see specifically ? You are basically saying that we don't install everything for you. Sure, we are sorry for that. But the steps to install other dependencies are, in fact, documented.

[marcdraco]

I've said this before: a pirori knowledge prevents things from being clear. You need to unlearn and learn to think like a raw recruit. You already have a huge amount of knowledge regarding this and I lack the time and (frankly) the patience to be wading through documentation that's not up to date, incomplete or wrong. A simple missed instruction (which seems so obvious to us that we wouldn't included it) might be enough to stump someone completely. But I wasted the best part of a day trying to follow the installer that you even admit has issues.

You can see the (some of the errors) on the YouTube channel from that independent channel. One guy didn't have idf.py but I worked around that and then got even more errors - since you didn't look at that, I'll copy here what I wrote there in reply to another user with exactly the same issue.

I'm getting a similar error on Mint (which is broadly Ubuntu compatible).

For such an amazing piece of silicon, their toolchain is a complete and utter [redacted] Even with these very detailed instructions it STILL fails and when I get it to recognise idf.py, it starts whining about esoteric version numbers and stuff I don't know anything about.

I know this isn't your fault Alija, but someone needs to give those guys a shake and remind them what century we live in! Devs don't have time to be fixing what should be an automatic install so they can just get started. I'm going to see how this works on my Windows box - which does seem a lot simpler, just so I can fix up what amounts to a couple of pages of C code!

Let me reiterate: victim (user) blaming isn't helpful and you're acting, perhaps out of frustration, by doing just that. I'm just a user and while I can program in C, I'm nowhere near as skilled in Linux as I would like to be. I've followed the instructions and they don't appear to work. Too many assumptions are made re. the skill level of the users attempting this and it's clear from the reviews on the VSCode extension that this is an issue,.

It works beautifully on the Arduino platform, it works on PlatformIO (via their installer) but I'm a bit vague on that and it works on PlatformIO under the Arduino framework too.

I used to write for a living - over three decades - science, technology and IT. I know how to write good documentation and I know how to speak to users when my documentation isn't up to snuff. I don't go telling them it's their fault because they are unable to understand or don't know how to follow what (I think) are simple instructions. As an instructor, if my students don't understand that's my fault, not theirs.

If a step fails I can't say that's their fault. Even adding things to the path should be automated - it seems the other installers have managed this on Windows and Linux.

This attitude isn't helpful and it pains me to say, it reflects very poorly on Espressif. Hardware (which is excellent) is nothing without good software. I've already told you what errors I've seen, I've uploaded the logs and I've offered to work from a clean install and plod through your documentation to see where the wheels come off.

But the problem is with this assumptive attitude. Whoever wrote that documentation makes assumptions about the skill level of the people reading it. My primary skill is in explaining difficult subjects to everyday people. Designing electronics and writing the supporting code is something I do in my spare time and I don't have a lot. What little time I have right now I'm spending learning to command the device by its registers.

However, I'll start a vanilla Linux today and document the first place where things go wrong. I trust you'll reflect on this and take it on board rather than telling me to do what I've already done.

[brianignacio5]

Sir, I think you misunderstood my writing tone completely. I apologize if I was not clear.

I just asked for technical information, like, what error were you observing and at which step. The idea here is for me to understand the step by step you followed and me trying to understand the error you are receiving. In no way I'm trying to shame you, I just need the technical details, like Error ... SSL ... or /path/to/bin path not found or something along those lines.

You mentioned you already share the errors you were having while I'm trying to explain that you have not shared anything technical that I could review besides the doctor command output, which only states that the extension is configured after your tedious journey. The extension log is located in :

Windows: %USERPROFILE%.vscode\extensions\espressif.esp-idf-extension-VERSION\esp_idf_vsc_ext.log Linux & MacOSX: $HOME/.vscode/extensions/espressif.esp-idf-extension-VERSION/esp_idf_vsc_ext.log

Apologies for the misunderstanding. Just trying to make the extension, the documentation and the experience better.

[marcdraco]

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.

Imagine going to a new restaurant to try out a particular signature dish. When your meal arrives you take a bite and find the meal is so unbearably hot you almost pass out. The waiter comes over and when you tell him the problem he says, "Didn't you read the small print? This is is a fiery delicacy for more experienced palettes." (Note the use of a priori knowledge here?)

You glance back at the menu which is in a language you don't speak well (or at all), gather your stuff and leave.

Next door is a similar establishment and as you sit down to order, the waiter takes you through the available options and describes the relative heat of each dish, comparing them to dishes you may have already have and recommends a yogurt drink in case you find things uncomfortable. (Fat absorbs the capsaicinoids more readily than our nerves so it quenches the burn.)

Which restaurant do you return to?

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.

[marcdraco]

Just for those following along, I've completed some tests on PlatformIO (Linux, VSCode). There's a problem with Python 3 that its installer catches rather nicely and links directly to the "fix" on GitHub.

After that, the process resumes on a VSCode restart.

Start a project in PlatformIO using the Espressif toolchain and everything worked from start to finish without incident. Now I haven't tried anything more than just "Hello world" in C but it compiled first time.

I don't know what the differences are (PlatformIO also supports the more learner friendly Arduino toolchain at the same time on a per-project basis) and this is clearly what you need to be aiming for as it's what users are expecting. It might even be smart to direct them at PlatformIO in the short term until you get these bugs squashed or face more and more unpleasant reviews and that doesn't do anyone any good.

Screens to follow.

[marcdraco]

Here's the three steps required using PlatformIO on a vanilla Linux (Ubuntu 20.4) to start developing with FreeRTOS -or- Arduino framework. You pick the one you want during project creation.

A vanilla Linux often doesn't include the full Python 3, so the installer prompts following this error:

This take us to an error/fix page right here on Github although the solution (as you can likely see) is already present in the output.

Finally, with that Python3 "patch" applied, we're ready to pick a framework.

Now I don't know anywhere near enough to know how good or bad this is, nor what sort of inline debugging it has. I come from the 8-bit era where step-by-step debuggers just weren't practical (or available) to devs of my level so I'm used to doing it the hard way, which is ugly and slow. It's entirely possible you're offering more than PlatformIO but it strikes me that being Open Source you should be able to take a lot of cues as to how to get past the reticence of the Linux platform and perhaps even MacOS too.

I am willing to test later betas in the same way, but right now it seems there's a solution that we can both use to our advantage. Would you agree?

[brianignacio5]

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 running sudo apt-get ... you'll see

and follow express or advanced steps. I tested this on a fresh linux computer.

[marcdraco]

Excellent Brian. I'll give that a shot as soon as I can. It's crippling to have such a great piece of hardware when you can't easily access the development kit. Hopefully this should be enough to stop the moaning minnies over at the VSCode website. I'm stuck on a Windows ultraportable now with limited Internet access so I'm a bit stuffed for testing.