The issue is actually the flash memory available to save code to. The STM32F4 chip has pages arranged in 16,16,16,16,64,128,128 - the first is needed for the bootloader, and the interpreter binary needs a continuous chunk of flash memory to work from, and 256kB is a bit tight. It leaves only the pages 2-4, which is 48k.
You could do a build using the 64kB page as well (and lowering the room for the interpreter itself to 256kB), but you'd have to flash the Pico itself using DFU (See Advanced Reflashing in the Pico Page) because you have to replace the bootloader as well.
Making use of more memory in a normal build (or in the future when the firmware gets bigger) is probably going to involve adding some kind of compression when saving to flash. Not impossible, but more work.
Have you tried turning on minification in the Web IDE - it'll make it a bit harder to debug but should save you a whole load of space. Or if not, just moving comments that you had inside functions to above the function would really help.
Thinking about compression though, can anyone think of a very compact compression library that could be included? So far miniz (which seems to be zlib compatible) looks like a good bet.
Obviously if it's going in the interpreter, it could be exposed as a JS module as well.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
The issue is actually the flash memory available to save code to. The STM32F4 chip has pages arranged in 16,16,16,16,64,128,128 - the first is needed for the bootloader, and the interpreter binary needs a continuous chunk of flash memory to work from, and 256kB is a bit tight. It leaves only the pages 2-4, which is 48k.
You could do a build using the 64kB page as well (and lowering the room for the interpreter itself to 256kB), but you'd have to flash the Pico itself using DFU (See Advanced Reflashing in the Pico Page) because you have to replace the bootloader as well.
Making use of more memory in a normal build (or in the future when the firmware gets bigger) is probably going to involve adding some kind of compression when saving to flash. Not impossible, but more work.
Have you tried turning on minification in the Web IDE - it'll make it a bit harder to debug but should save you a whole load of space. Or if not, just moving comments that you had inside functions to above the function would really help.
Thinking about compression though, can anyone think of a very compact compression library that could be included? So far miniz (which seems to be zlib compatible) looks like a good bet.
Obviously if it's going in the interpreter, it could be exposed as a JS module as well.