rfc: Change Pico build firmware/flash split to 1Mb/1Mb

[Gadgetoid]

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:

Filename	Binary End	Block Dev Start	Binary Size	Block Dev Size	Usage
cosmic_unicorn-v1.23.0-pimoroni-micropython	0x10124830	0x1012c000	1.14M	0.83M	29.95K remaining
enviro-v1.23.0-pimoroni-micropython	0x1010a280	0x1012c000	1.04M	0.83M	135.38K remaining
galactic_unicorn-v1.23.0-pimoroni-micropython	0x101248b0	0x1012c000	1.14M	0.83M	29.83K remaining
inky_frame-v1.23.0-pimoroni-micropython	0x10111474	0x1012c000	1.07M	0.83M	106.89K remaining
picolipo_16mb-v1.23.0-pimoroni-micropython	0x100bb740	0x10100000	0.73M	15.00M	274.19K remaining
picolipo_4mb-v1.23.0-pimoroni-micropython	0x100bb740	0x10100000	0.73M	3.00M	274.19K remaining
pico_usb-v1.23.0-pimoroni-micropython	0x100a25dc	0x10100000	0.63M	1.00M	374.54K remaining
pico-v1.23.0-pimoroni-micropython	0x1009eb28	0x100a0000	0.62M	1.38M	5.21K remaining
picow-v1.23.0-pimoroni-micropython	0x10117f44	0x1012c000	1.09M	0.83M	80.18K remaining
stellar_unicorn-v1.23.0-pimoroni-micropython	0x10124830	0x1012c000	1.14M	0.83M	29.95K remaining
tiny2040_8mb-v1.23.0-pimoroni-micropython	0x10099e6c	0x10100000	0.60M	7.00M	408.39K remaining
tufty2040-v1.23.0-pimoroni-micropython	0x100b4d74	0x10100000	0.71M	7.00M	300.64K remaining

(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:

• flashing between our Pico build, and the official Pico build will trash the user filesystem.
• less space is available to the user for their code
• in practice we're really only delaying the inevitable

Short of backpedaling and rewriting our entire driver ecosystem in MicroPython (something I think we should begin looking into anyway), is there another way?

[Gadgetoid]

Note that updating JPEGDEC totally blows this budget: #948

[ahnlak]

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...!)