compile error with SPIFFS

[lblabr]

if i compile with SPIFFS_SUPPORT i get the following error:

C:\Users\Lars Bretschneider\lblabr@owncloud\Projekte\Arduino\github.espurna\code\espurna\utils.ino: In function 'void info()':

utils:336:132: error: 'sectors' was not declared in this scope

         DEBUG_MSG_P(PSTR("[MAIN] SPIFFS total size: %8u bytes / %4d sectors\n"), fs_info.totalBytes, sectors(fs_info.totalBytes));

[mcspr]

SPIFFS isn't used here at all, so adding that flag does nothing but include that message into 'info' command.

@xoseperez While reading esp8266/arduino issue tracker I had often seen mentions of how dangerous it is to use eeprom and spiffs should be used instead to avoid possible flash memory failures. If I understood that right, spiffs tries to spread out writes and ease on writing same sectors over and over again. Maybe this should be considered to be included again as possible storage for settings and state (last relay, schedule triggers etc.)? arduinojson or some binary-blob format

[xoseperez]

Yes, SPIFFS handles wearing much better than EEPROM, that basically does not handle it at all (my EEPROM_ROTATE library is an attempt to halve chances of failure). It's an option to reconsider. I removed SPIFFS support when ESPurna moved to WEB_EMBEDDED to save room and have more space for OTA.

[xoseperez]

I have fixed the bug but this certainly requires more talk. Should SPIFFS support be dropped completely? Is it worth to add support to store settings over SPIFFS?

[lblabr]

i would like to have spiffs available. as far as i understud i may store some web content there... i think i tried in the past and worked...
i use nodemcu with 4mb so there is enough space for ota. i provide a custom interface from spiffs would be nice, if you still support the OPTION to serve web content from spiffs, without doing this compressing stuff

thanks in advance

Lars

[mcspr]

Non-existent problem right now - up to date webui <-> api compatibility. Other similar projects resort to just templating everything on the fly. With SPIFFS that would require clearer versioning agreement (enforcing or not) between ws and web, also sometimes keeping older versions of code.

Still, as a pro, using it would allow saving statistics / debug log data, sensor readings, general stats, crashdump history. Configuration becomes easily importable/exportable directly on flash. As a con - 1MB modules become tricky to use because of minimal required 128Kb (most basic use would do 64Kb, but that's stretching). And another level of management - uploading full fs image or not, file updates via http api etc.

@lblabr About compression/inline etc. you'd still need to package everything. Might as well do the compression. However, with 4mb, that might not make such big difference like with 1mb (comparing file sizes in 'code/espurna/data' before and after gunzip). Plus, there is technical reasoning for bundling such multi-file-based UI: http://tinkerman.cat/optimizing-files-for-spiffs-with-gulp/ (aka memory goes out of control)

[xoseperez]

I fully agree with @mcspr. We could, of course, benefit from having SPIFFS available to store logs or even configuration (this is something we have in mind). You can also store the web UI there but the web building procedure will still be necessary (cleaning, merging, compressing). The only step not needed would be inlining in program memory.

That said, the full web UI image uses around 62Kb. That's too tight for a 64Kb SPIFFS partition so we should go for the 128Kb. That would leave 871Kb for program plus OTA space, 432 Kb each rounding to the sector size. Current binary size (removing the webUI) would be under 415kB so it is feasible.

I think we should still deliver monolithically binaries (code and webUI embedded) but offer the option to use the old system based on SPIFFS. Like @mcspr says, this will require ensuring the versions of both the code and the webUI match