the a thought about the flash size limit

[davidelang]

The current flash size limit is based on 1M of flash - 64k bootloader /2 so that the current running copy of the firmware can fit in flash along with the new copy that's being downloaded (so that it can be checked before being used)

I don't know how easy/hard this would be to implement with the current toolchain, but as a thought

Could we split the firmware into a core and sensors package?

by doing this split, the core could delete the sensors package and replace it without needing to replace itself.

the core could delete the sensors package and install an updated version of itself that could then install an updated version of the sensors package.

The sensors package could be tightly coupled with the core package where they have to be built from the same source, or we could define an interface between the two that would let the same core work with multiple sensor package versions

I'm thinking that the sensors package would start with a data structure that would be a table of the available sensors in the module

1. a versionid (similar to cfg_version)
2. the size of the sensor package (in bytes or 64k blocks)
3. the number of sensors in this package
4. for each sensor, a list of several items
   1. Name
   2. function pointer to detection function
   3. function pointer to initialization function
   4. function pointer to mmqt producer
   5. function pointer to web producer

function pointers would be relative (how far into the sensor blob to find this function) so that the sensor package could be loaded at any address in the flash. If this isn't doable, make the sensor package always go at the end of the flash, so the last 64k chunk of the flash is this data structure with unused space between the core and the sensor packages

This approach would have the ability for the firmware to detect if there is or isn't a sensor package loaded (the same way it detects if the config is usable or needs to be replaced)

ideally the initial flash-via-serial would install both (along with the bootloader) and only OTA updates would be affected.

Thoughts?

[arendst]

Nice thought and it might be usefull if the sensor code was the bigger part of the image. It's not. In fact the webserver (+60k) takes up a huge amount of space as would TLS (+50k). And then we do not have that many 64k blocks available.

Another challenge will be the next Arduino-esp8266 release. I've done some testing with the current github version and it raises code size by another 25k making the current set almost unusable. For that case I introduced the USE_MINIMAL option allowing to upload the minimal version first after which you can upload the current full version.

[khcnz]

If one were to re-write the webpage as a Single Page Application you could probably both save some code (essentially just expose the mqtt commands through a JSON endpoint) and also then you could store the static assets as gzip content and stream it out directly as pre-gzipped. There is stacks of text in that file so it would zip up nicely.

And if you were super desperate for space, that file could be hosted elsewhere on the net...(and just include the .js remotely that the browser would directly retrieve).

[ionciubotaru]

Looking inside code I found:
//#define USE_SPIFFS
By default you save the configuration to Flash.
You can add a new board in arduino's boards.txt with 1Mb flash and 0 spiffs and you will have 32k (64k/2 ) for OTA.

[hallard]

Guys,

As I already made 1M with lot of SPIFFS different size (sorry forgot NO SPIFFS option) I just made a new PR on official Arduino ESP8266 to handle 1M No SPIFFS
esp8266/Arduino#3203