You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • 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/tre­e/Pico_Extra_RAM

    These are the changes that are needed: https://github.com/espruino/Espruino/com­mit/9c063c9b2b5088b3ddac5a3f7146dacabe67­0c51

    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.

About

Avatar for Gordon @Gordon started