On esp8285 (or esp8266 with only 1M flash chips),
OTA updates are limited to usually half of the flash size (download to free flash, then copy to beginning of flash).
esp8266 flash images compress to around 0.7 of the original size (with gzip -9)
By compressing, sending and storing a compressed flash image, one can expect to gain roughly 100KB of flash image size and this is huge (1/(1+0.7)-(1/2))*1M. Inflating would happen on-the-fly while flashing (of course, inflate code would have to stay in ram).
Without using any ram-dictionary, already inflated chunks need to be always accessible.
Luckily this is compatible with this use-case.
However, uncompressed data are stored in 32bit-only accessible memory, so every read access to d->dest (already flashed, not in a temporary ram block), directly or through TINF_PUT must use a "32bits aligner" facility.
I already know official esptool.py is doing something similar, but it's using another deflate implementation that seems to require a 32KB ram block (which is always possible in that case), I find the source code less readable and I'm not sure it can do the job without a ram dictionary.
I'm not asking for help.
Due to your knowledge of the chip and its limitations, I was just wondering what you would think of this use-case.
(edit: fortunately, first result of google's 'zlib esp8266' is a link to uzlib)
On esp8285 (or esp8266 with only 1M flash chips),
OTA updates are limited to usually half of the flash size (download to free flash, then copy to beginning of flash).
esp8266 flash images compress to around 0.7 of the original size (with
gzip -9)By compressing, sending and storing a compressed flash image, one can expect to gain roughly 100KB of flash image size and this is huge
(1/(1+0.7)-(1/2))*1M. Inflating would happen on-the-fly while flashing (of course, inflate code would have to stay in ram).Without using any ram-dictionary, already inflated chunks need to be always accessible.
Luckily this is compatible with this use-case.
However, uncompressed data are stored in 32bit-only accessible memory, so every read access to
d->dest(already flashed, not in a temporary ram block), directly or throughTINF_PUTmust use a "32bits aligner" facility.I already know official
esptool.pyis doing something similar, but it's using another deflate implementation that seems to require a 32KB ram block (which is always possible in that case), I find the source code less readable and I'm not sure it can do the job without a ram dictionary.I'm not asking for help.
Due to your knowledge of the chip and its limitations, I was just wondering what you would think of this use-case.
(edit: fortunately, first result of google's 'zlib esp8266' is a link to uzlib)