I added a call to print the memory info in my Pico LED array program and found something interesting. As long as the program only used integer maths, the memory usage was rock steady.
But whenever I used float operations, such as making a call to random.random() or doing other float calculations, the amount of available memory kept decreasing, and the more calculations the program performed, the more memory was used up.
I let the program run, watching the available memory decrease to zero and when I expected the program to crash, suddenly a pile of memory came back and the program continued on. I guess GC finally decided to get off it’s butt and do something.
Anyway, I also added the watchdog timer and each of the program loops make regular calls to machine.WDT.feed() to keep the system from resetting, but now if the program hangs, the watchdog timer should reboot the Pico.
In fact is does that, because every time I run the program from Thonny over USB and stop the program, a little while later the watchdog timer resets the Pico and terminates the connection to the PC. That’s fine, but saving the code to the Pico now means that if I want to modify the code I either need to access the Pico with the boot select button or stop the program from Thonny and be very quick to select main.py and delete it before the wdt resets the Pico.
Regardless, I’m not certain whether the float memory situation is working as intended or not. Not sure why GC wouldn’t be more fastidious. Don’t really like the idea of not knowing why the problem hangs occasionally and needs to be rescued with a reboot but what can you do?