You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
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.
@Gordon
What do you mean by
w/e?I did try splitting the firmware originally, but I didn't manage to do it with a linker script. If someone knows how to do it I'd be interested - but if I'm honest it's probably a bit late now given the need to update the bootloader with DFU. Most people won't want to do that.
The whole firmware will currently fit in that 256k even with WIZnet (that's what I did with the binary in the build above) - I just think it may end up being tight in the future. I actually put a branch online: https://github.com/espruino/Espruino/tree/Pico_Extra_RAM
These are the changes that are needed: https://github.com/espruino/Espruino/commit/9c063c9b2b5088b3ddac5a3f7146dacabe670c51
But honestly I think compression is the best bet - I imagine I could reliably get 80kB of data into 48kB of flash, especially as it'll never be 100% full (or your program wouldn't run). Then it's just a simple firmware update, there's more flash for other stuff, you get a compression library built in and potentially we could squeeze a bit more into the original Espruino board too.
Any thoughts about suitable compression libraries? I'd probably need something that either wrote data using a callback, or that could decompress in chunks.
LZFX looks nice and small, but I'd have to mess around with it quite drastically it order to get it writing via callbacks.