I'm using the ESP8266HTTPUpdateServer library to give my sketch OTA update capability. I have a basic sketch that permits OTA uploads, it's working perfectly, including the ability to compress the .bin file with gzip prior to upload.
The following section of the OTA Updates documentation:
OTA Updates — ESP8266 Arduino Core 3.1.2-21-ga348833 documentation (arduino-esp8266.readthedocs.io)
notes that the OTA data received is stored in the space between the current top of sketch and the base of the spiffs area. If I'm using an uncompressed OTA, then it's obvious that the sketch size must be smaller than half the total available space in order to leave room for the OTA update to be saved.
But what about the following case, working on a device with 1MB of flash.
Assume I partition flash as follows:
900K sketch space
100K spiffs
24K for EEPROM, WiFi credentials, etc.
With an uncompressed OTA, I'm limited to 450K space for the sketch. However, assume I can get compression with gzip that reduces the .bin size by at least 20%. In practice I'm typically seeing a reduction of between 25% and 30%, so I think 20% is a safe margin.
Can I allow the sketch to grow as large as 500K, working on the basis that the sum of 500K uncompressed and 400K compressed fits into the 900K available?
This section of the OTA Updates page:
OTA Updates — ESP8266 Arduino Core 3.1.2-21-ga348833 documentation (arduino-esp8266.readthedocs.io)
seems to suggest that the gzip decompression is done at the same time as the eboot loader is reading the compressed OTA update and writing the new sketch to flash.
Is this actually the case? Can I get away with a 500K sketch and a 400K compressed OTA, or am I limited to 450K, even when compression is in use?