When MinGW is my default toolchain, I can build the esp32-s3 env no problem. no issues whatsoever here.
However, if I switch my environment to native, CLion blows up and is unable to identify any of the sources for native as part of the project. However, if i swap my default toolchain to WSL before switching to native, the IDE does just fine.
Now for the actual weirdness - if I try to invoke any platformio commands from the CLion IDE, it complains that it can’t find g++, even though I have my WSL toolchain pointing to /usr/bin/g++, however if I execute platformio test -e native from the WSL command line in CLion, everything compiles and runs just fine. If I run which g++ from the command line, it points to /usr/bin/g++.
I think that has exactly zero effect, if you tell it to use the “WSL” toolchain. Likely, when PlatformIO is triggered to build with pio run on your Windows machine, it doesn’t even look at that configured CLion toolchain. PlatformIO manages its own toolchain packages after all; With the one exact exception being platform = native, where it expected that the OS has gcc, g++ etc. globally available in its path.
I don’t think you can tell PlatformIO to “just use WSL” – the entirety of PlatformIO (CLion in this case) would have to be started from WSL.
So, if you already have mingw installed, make sure g++ etc are in the global %PATH. In a regular Windows terminal (Win + R → cmd.exe), gcc --version has to work.
Thank you for the response. I’m still pretty new to all of this, and the checking gcc --version from cmd got me on the right path. I found I also had MinGW32 and not 64 on my computer, which once I fixed, everything seems to be pretty happy. I’m still running into some issues trying to run my unit tests in debug, but one step at a time!
As an aside, you’re issuing a workaround for a a bug on a different chip. You’re just flushing performance for no good reason.
If you have the correct board definition, it’ll pick up BOARD_HAS_PSRAM from that and it’ll never pick up -mfix for a ‘wrong’ chip. The proper board=definition should get you these.
This isn’t any of your actual problem here and has nothing to do with CLion… It just catches my eye as a pet peeve of people that copy-paste stuff without understanding it.
Thanks for the call out! I’ve got it removed, and yeah, it’s a pet peeve of mine to copy paste stuff I don’t understand, but the documentation for all of this is pretty rough and it can be hard to try and find all the appropriate information to get things to work exactly as you need!
It’s true that modern development seemingly requires us to all be experts in about two different domains. You should find that a platformio board efinition for a board that has an affected chip has that flag, for example the original esp32-feather:
specifies it on lines 9 and 12. That board HAS_PSRAM and it needs the cache errata workaround for that chip.
The Feather with an S3 HAS_PSRAM but does not include that workaround becauses is uses the related S3 that doesn’t have that bug and therefore doesn’t need the compiler to work around it. Notice the absence of -mfix-e-p-c-i
It’s my religion that if you specify that actually correct board= entry, you shouldn’t have to specify any of this junk. HOWEVER, with Platformio and Espressif feuding (and they didn’t exactly get this perfect when they weren’t…) they’re not accepting bugreports or fixes in this area.
People see a post from 2017 when ESP32-was new and the boards= entries were wrong or hadn’t yet been updated and they read (what’s now superstition/folklore) that says ‘add these magic flags’ and trust they’re the thing to do. There are also a ton of users that are driving ESP32 configurations from board s that are similar and they just sprinkle on flags until things mostly work. I’ve seen original ESP32-nothings turning on USB_MODE even though those parts don’t even have USB silicon.
In fact, it was only the fairly short-lived first production rev of those first ESP32s that needed it: Support for External RAM - ESP32 - — ESP-IDF Programming Guide v5.2.3 documentation I haven’t seen a 1.0 rev chip in years, but the symptoms in that chip are soooo obscure, that there’s a lean to applying it even when not needed. On the S3 and all other parts, it’s simply not needed.
Apparently I spend my sleepless nights digging up year-old posts, butting my nose into discussions where I have nothing helpful to add, but am “adding value” by telling people they can delete two lines of build configuration goo. I need better meds…and a life.
