Fair enough, UKHeliBob! It took some doing, but I was able to get the old version of NoiascaLedControl on my Windows 11 machine IDE. It compiles the Sketch just fine, and it uploads to the target MKR-Zero hardware, but it still has the performance issues and the Win 11 compile is still 97,872 bytes compared to the 87K bytes in the Win 10 compile that works on the MKR-Zero hardware.
10K program size difference is a lot for a patch release. The diff is more complicated for a few reasons, including using different sketch names on each machine. To make it "easy", some script hackery (I'm using Linux) can break the log at every space or (back)slash to see each option and path component separately. I pasted them into one.txt and two.txt
$ diff <(sed 's/\([ \]\)/\n\1/g' one.txt) <(sed 's/\([ \]\)/\n\1/g' two.txt) | less
12c12
< \tomki
---
> \info
30c30
< \tomki
---
> \info
45c45
< \tomki
---
> \info
58,59c58
< -Og
< -g3
---
> -Os
So first, three instances where the user name is different on each machine. Then a difference in the -O option, which controls optimization. -Og is a little complicated and goes with -g3, but -Os optimizes for size. That's probably why the second one (Win 10) is smaller.
Note that this early diff is actually for the first command doing "Detecting libraries used...", but you can check that it is used for all the others, including the compiling. Looking for those switches in the board packages
$ rg '[-]O[sg]' ~/.arduino15/packages
~/.arduino15/packages/arduino/hardware/samd/1.8.14/platform.txt
36:compiler.optimization_flags=-Os
37:compiler.optimization_flags.release=-Os
38:compiler.optimization_flags.debug=-Og -g3
There you go: for release, optimize for size. The other option is apparently for the menu option Sketch > Optimize for Debugging (which I have never used). If it is enabled on the Win 11 machine, try turning it off.
1 Like
Wow, good insight! I switched off the Optimize for Debugging on the IDE for the Win11 machine, and the compile output dropped to 86504 bytes, right in line with that for the Win10 machine. And guess what? The Sketch uploaded from the Win11 machine's IDE now performs properly on the target hardware MKR-Zero. You're a genius!
Just to be clear, in the IDE 2.3.6 it's Sketch > Optimize for Debugging (click it on or off - it works when it's off, i.e., with no checkmark next to that menu item). Thanks, and thanks to everyone for your kind attention to my rookie problem.
I performed the acid test: I turned the "Optimize for Debugging" option ON on my Win10 machine IDE and reproduced the exact problem (and the IDE compile output was 97,872 bytes just like it was before on my Win11 machine). Sure enough, the uploaded Sketch exhibited the same performance maladies on the target MKR-Zero hardware as it had previously on the upload from the Win11 machine. And when I switched that Optimize for Debugging option OFF on my Win10 IDE, everything worked as it had originally. Thank you all!
"optimize for debug" really shouldn't have that dramatic of an effect on performance. Can you be more explicit about what sort of code you're using, how fast it's supposed to run, and how badly it is degraded?
Many extra brownie points if you can come up with a small sketch that shows similar performance degradation!
Good challenge, but maybe just a brief description instead: I build and sell specialized computers for competitors to use in Open Road Challenge events. The computer displays their Ahead/Behind time in hundredths of a second as they drive a high desert canyon road closed by the police for the event at speeds up to 180 mph average (for 90 miles in one case). Using one of my own computers, I set a record on Nevada's Highway 318, coming in within 0.0001 seconds of a perfect time. Typical winning times are about 0.0020 seconds. The computer gets an interrupt every 0.01 seconds and uses a GPS to calculate distance and speed against the declared target speed (anywhere from 95 mph to 180 mph). So the MKR-Zero is under heavy load, although since it's a microcontroller rather than a cpu, it exhibits loading problems by missing some interrupts sometimes as it goes through its loop. In this instance, the Ahead/Behind display before the start of the race (competitors typically start at one-minute intervals) shows the GPS Time-of-Day seconds. The competitor hits a pushbutton at the start line, and the unit knows to start at the top or bottom of the minute upcoming. When the Sketch is loaded using the "Optimize for Debugging" option, the Ahead/Behind display can't update the display of seconds reliably - it freezes often before resuming after a few seconds. But without the "Optimize for Debugging" enabled, the Sketch works fine. How can I tell? The Sketch has a built-in Simulator function that allows a user to simulate a run at a given target speed when the box is just standing still (the Simulator produces simulated GPS latitude and longitude coordinates in keeping with the simulated velocity). So, that's a long-winded explanation. Not sure I can analyze exactly what's happening but at least when the option is off it works, and when the option is on it exhibits problems.