robertlipe
commented
3 months ago Not to be unsympathetic - hey, we're all users trying to help each other out - but lots of us compile ESP32 code (RV and LX6/LX7) on Apple Silicon hosts pretty often without issue. So not to sound like one of those antatonistic support calls, but maybe it's not all them, but maybe a dash of you.
You didn't include a reproducible test case so anyone else can look at it to see what you were doing differently than the rest of the world. No fetchable repo to clone or steps to follow means that the helpers are left to try to guess what makes your invocation "special". That's rarely well spent effort for anyone but you. (Sorry.)
It catches my eye that there's a lot of Python barf in your stack trace. I don't use Python in my embedded builds. I can't tell if that Python is even yours or what comes with a system or what should come with a system but didn't or whatever. (Have I blown my cover as not a fan of the Python ecosystem?) Not saying there's cause/effect there, but maybe that's a hint on where to start digging. There are Pythonic errors that are really really similar going back at least sixe years. Ex: https://stackoverflow.com/questions/51775462/python-3-7-import-requests-returns-chardet-error Maybe there's a hint in there somewhere.
In short, just as a bystander that's trying to throw a fellow dev a life jacket, to me this looks like either a question that's not asked well enough to actually get the help you need OR some kind of Python-specific library (chardet ?) that's being used by ... something that isn't being found. (Resolving this latter case is about half of the development time I've spent on Python. Something I didn't know I needed wasn't installed for this specific version of Python that's hidden deeply on the system, but in a different versino of Python than the one that's in my $PATH...but I'm not bitter, noooooo. :-) Cross development (writing code on a Real Computer for a Tiny Computer) makes this issue much harder to work through because the Python you can "see" may not even be related to, say, '/Users/clarence/.platformio/penv/.espidf-4.4.5/lib/python3.12/site-packages/charset_normalizer' and friends (that path may or may not have anything to do with anything - it's just an example) which can make "normal" debugging vs. embedded download of scripting languages all the more frustrating to work through. 'Chardet' may work perfectly normally on native systems but be missing/malformed on the embedded/cross dev environment to lead to this kind of thing.
Even if I haven't directly helped (sorry /shruggie) hopefully I've helped improve the quality of the question enough (reproducible steps on dev issues rock! A dev can't "fix" what they can't see...) to help move the conversation along once you're at the top of their queue. It looks like there's a backlog of a few thousand between the rise of popularity of Platformio and the homeland of the project's principal developers being regularly bombed.
May The Source Be With You! (And certainly with the PlatformIO team!)
PIO Core Call Error: "The following files/directories have been created in ~/Documents/PlatformIO/Projects/MyESP32Project include - Put project header files here lib - Put project specific (private) libraries here src - Put project source files here platformio.ini - Project Configuration File Resolving esp32dev dependencies... Already up-to-date. Updating metadata for the vscode IDE...
UserSideException: Processing esp32dev (platform: espressif32; board: esp32dev; framework: espidf)
Verbose mode can be enabled via
-v, --verboseoption CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html PLATFORM: Espressif 32 (5.4.0) > Espressif ESP32 Dev Module HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa) PACKAGES: