Wonder if that is because you have libzstd.dylib already, or if it’s a difference between x86 and arm mac binaries…
It’s a new M4 Apple silicon Mac. I moved to it from an Intel processor a few weeks ago.
I do have that file in /usr/local/lib due to some Wineskin port thing it seems.
I’m tempted to go compile arm-gcc myself, but with zstd support disabled.
Not sure how much work that is though.
So I built an arm-gcc (for linux) with no zstd support, then recompiled the stm32 system libraries using that gcc, which means that it will uze zlib instead of zstd for lto compression.
Unfortunately, I get a new error:
/usr/local/hubbe/arduino15/packages/proffieboard_experimental/hardware/stm32l4/4.5/cores/stm32l4/stm32l4_wiring.h:54:33: internal compiler error: original not compressed with zstd
This happens even though gcc -v says:
Supported LTO compression algorithms: zlib zstd
But clearly it has to be zstd, or it doesn’t work…
Board version 4.5 just appeared–I loaded it and test compiled a sketch.
No zstd compression error.
I have also successfully flashed a saber with the experimental board setting–but I’m in a hotel and only brought one saber with me, so I can only test this one… anyway:
All my presets seem to be working correctly.
What OS did you use?
(Both ProffieOS and host computer OS actually…)
Also, I’ve found something that seems to be a better build of arm-gcc 14.2.1:
So far it seems to have less foibles, and I’ve used in the new hotness: 4.6
1 Like
Proffie 7.14; board v3.9
Windows 11
Arduino 2.3.4
I don’t know if you’re still in need of testing, but I’ve tested 4.6 on both my laptop and desktop. Both are running Windows 11 and Arduino 2.3.4 and using Proffie 7.14.
Under the experimental board manager both 4.5 & 4.6 work. I am able to compile sketches and flash my sabers and they seem to behave as expected–I didn’t notice any differences, but if you need something specific tested, I’m happy to continue testing.
I get the zstd error with 4.4 and 4.3.
I have also been able to flash with 4.1 on the non-experiemental board manager on my desktop–but for some reason my laptop only sees up to version 3.6 on the non-experimental board manager.
I do have one odd quirk on my laptop with Arduino–but I’ll post it under a separate thread.
4.6.0 compiles fine for me as well (Windows10 Arduino IDE 2.3.4)
Sketch uses 489976 bytes (96%) of program storage space. Maximum is 507904 bytes.
Same config with 3.6.0 also with Smallest code, Serial+WebUSB & SDIO High speed:
Sketch uses 466624 bytes (91%) of program storage space. Maximum is 507904 bytes.
I definitely am.
There are a couple of different dimensions that needs testing:
- Different host OSs. (Windows and Linux seems to be working, mac-x86 and mac-arm still needs to be tested)
- Differnt versions of ProffieOS. (Seems like 7.14 works reasonably well, but we also need to test github master.)
- DIfferent features and configurations, like oled, color displays, different styles, etc. (Testing the same, or very similar configurations over and over does not really provide more information.)
Generally, I’m only interested in testing the latest, which is now 4.6.
It’s the same compiler, just compiled differently. That means that the differences between 4.3, 4.4, 4.5 and 4.6 are only in what host computers they work with. IF the compiler works properly, the results should be pretty much identical across 4.3-4.6. The results should also be the same on mac, windows, linux, arm or x86.
I revoked 4.1 from the live channel because it had serous bugs.
It’s unfortunate that 4.6 seems to use a bit more space, but if we have less bugs, I think that is going to be worth it.
Did you upload and test this as well? Or just compile?
Just compiled, it was POS8.x master with my latest muti_prop.h (rev 064), saber_fett263_button.h, blaster_BC_button.h, detonator.h, my latest jetpack_prop.h (rev48), my latest (very “squeletonick”) morsecode_prop.h (rev 16 - still a lot of work ahead, for that one!) & my very long 3836 lines config (where I try to have a bit of everything). ProffieBoard V3.9 & my multiprop/jetpack/morsecode display controller rev5.
I’m quite worried about compiler bugs though, which means that what I need most is testing that the code works as expected.
Would it help if I upload to my board, and use some commands in serial monitor ? My chassis is still in the same state as 5 months ago: everything connected except the board - I need to decide on which magnification to buy!
It would.
If you see something weird/different with 4.6 that you didn’t see with 3.6, then we would investigate and try to figure out what caused it. If not, it’s one more vote for 4.6 working as it should.
I just compared my config with 3.6 (release) vs 4.6 (experimental)… and the experimental averages smaller.
OS Windows 11, Proffie OS 7.14, Arduino 2.3.4
Proffieboard v3.9
Compiler set to “Fastest”
I tested 6 configs that I’ve written–the experimental board yielded a smaller config for 3 of the 5 (by 2-8k), and in the other three cases, the experimental config was less than ~700 bytes bigger.
I also tested a config that I didn’t write for a Proffie v2.2, code set to smallesst
The experimental board was ~1500 bytes bigger.
I have a few sabers with OLED displays–including one I just finished installing. I’ll admit I’m still learning to use OLED, so I’m not an expert, but its behaving the same as my other sabers with OLED displays running 3.6. I initially ran it with no bmps then reflashed with bmps copied from a chassis from Shadowfoil. Seems to be working fine…
That pretty much exhausts my potential contributions. 
Cool, I’m in.
ProffieOS 7.14
macOS 15.2 (M1)
Arduino 2.3.4
Error:
dyld[20759]: Library not loaded: /usr/local/opt/zstd/lib/libzstd.1.dylib
Referenced from: <73E7659D-2FDC-30A7-BE7F-5E4CE7A08422> /Users/catherinebogin/Library/Arduino15/packages/proffieboard_experimental/tools/arm-none-eabi-gcc/14-2-rel1/libexec/gcc/arm-none-eabi/14.2.1/cc1plus
Reason: tried: '/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/usr/lib/libzstd.1.dylib' (no such file, not in dyld cache)
arm-none-eabi-g++: internal compiler error: Abort trap: 6 signal terminated program cc1plus
Please submit a full bug report, with preprocessed source (by using -freport-bug).
See <https://bugs.linaro.org/> for instructions.
exit status 4
Compilation error: exit status 4