Gadgetoid
commented
1 month ago Note that updating JPEGDEC totally blows this budget: https://github.com/pimoroni/pimoroni-pico/pull/948
Open Gadgetoid opened 1 month ago
Gadgetoid
commented
1 month ago Note that updating JPEGDEC totally blows this budget: https://github.com/pimoroni/pimoroni-pico/pull/948
ahnlak
commented
2 weeks ago Is it feasible (or useful?!) to break the report down in terms of C stuff (which presumably would be tricky to break out) and Micropython stuff (which presumably would be less painful)?
I get that it's incredibly useful to have a single bundle with everything in it (although as the number of boards grow that becomes less true anyway) but as you say, given that stuff only ever gets added it's inevitable that there will come a point where it just doesn't fit any more.
(and yes, my C/Micropython question doesn't really address that problem either, but...!)
We've always been grappling with this issue, due to our pack-in drivers, but I've long since run out of ways to trim things down. Combining common drivers, splitting out projects like Cosmic, and producing custom builds for our larger flash chips has worked for non-Pico builds. Unfortunately the Pico build now has only ~5k between firmware end and flash start. That is cozy.
Here's a full binary size report on our v1.23.0 release:
(Note: table produced with https://github.com/Gadgetoid/py_decl/blob/main/examples/size_report.py)
As such I propose making a breaking change in our next point or other release that changes our Pico firmware memory split from the Pico-compatible 640/1408 to 1024/1024.
In the table above you'll note that the USB build does this, leaving 374K bytes remaining even after packing in USB features.
The implications of this change are simple:
Short of backpedaling and rewriting our entire driver ecosystem in MicroPython (something I think we should begin looking into anyway), is there another way?