then the compile process fails after bombarding me with tons of warnings and a final mention
glcdfont.c:10:28: error: 'font' defined but not used [-Werror=unused-const-variable=]
static const unsigned char font[] PROGMEM = {
^~~~
cc1: some warnings being treated as errors
I tried both with IDE 1.8.19 and IDE 2.1.1
this is on an intel Mac with Monterey
I suspect that this is due to the agressive settings of the compile process (warnings being treated as errors)
I'm Wondering if there are any user of the Core2 and if anyone succeeded to work around this
ah - I'll try removing the Adafruit GFX library... May be the IDE got confused on which library to use (although there is a builtin screen in the Core2, so may be they use the GFX Library)
actually on second look - no luck. Seems they have their own copy
I should have included the path for the error
~/Documents/Arduino/libraries/M5Core2/src/Fonts/glcdfont.c:10:28: error: 'font' defined but not used [-Werror=unused-const-variable=]
static const unsigned char font[] PROGMEM = {
^~~~
cc1: some warnings being treated as errors
it shows M5Core2/src/Fonts/glcdfont.c so that's their stuff...
I have a couple of M5Tough units. I just looked at the last project I did and the only #include files are ones I created.
You should be able to compile a .ino file for the M5 Core2 with just setup() and loop() and nothing else.
My setup() has an M5.begin() and I think that initializes the display.
[edit]
Their display.ino demo only has a #include <M5Tough.h>
Note that there are a number of cases where Core libraries won't work on Core2 hardware. M5 says they're in the process of fixing that. I think they want everyone to use M5Unified library for everything, but I found that doesn't always work so well.
At the moment it seems it does not work at all, at least for me.
I’ll try to get a full clean install on another Mac just to make sure there is no conflict about which the normal esp32 stuff.
Like the "esp32" boards platform it is a fork of, the "M5Stack" boards platform is distinctive in that the compilation result is affected by the setting of Arduino IDE's "Compiler warnings" preference.
Traditionally this preference has only influenced how many warnings we see in the compilation output, but the Arduino boards platform framework allows each platform developer to decide exactly what effect they want each of the levels of this preference to have. The ESP32 developers decided to add the -Werror=all flag to the compilation command when you set the "Compiler warnings" preference to the "More" or "All" levels. This flag causes compilation to fail when the sketch code produces a compilation warning.
Generally the solution would be to fix the code that produces the warning, which is what the configuration is intended to encourage. But in cases like this where the low quality code is from a dependency rather than code you maintain, that may be inconvenient (or not feasible for less experienced users). In this case the workaround is to reduce the level of the "Compiler warnings" preference to avoid the warnings causing a compilation error:
Select File > Preferences... from the Arduino IDE menus.
The "Preferences" dialog will open.
Select "Default" from the "Compiler warnings" menu in the "Preferences" dialog.
Thanks for the suggestion - I did not think of lowering the warnings in the preferences - I’ll try that.
Agree it’s poor engineering practice to have so many warnings in code you ship in support of a commercial product… I’d be embarrassed if I were them. Kudos to Arduino to keep an eye on that.
I might attempt to fix these later if I get time, it feels more like just incorrect types compatibility issues or initializers all over the place so not complicated but just lots of work.
so changing the compile warnings option to Default solves it. Any level above ("more" or "all") will trigger the some warnings being treated as errors issue and compilation will stop.