Your new topic does not fit any of the above??? Check first. Then post here. Thanks.

Moderator: igrr

User avatar
By owensv
#65864 This is exactly what I would like to do. Clearly, you guys have been deep into this; is there a gentle introduction somewhere that could start me down the path of how to serve files (especially images) from flash? Thanks
User avatar
By treii28
#69923 OK, after stumbling on the SPIFFS filesystem, the method outlined in this post -- while ingenious, end up being cumbersome and unnecessary. (alas, it made for a great learning example and inspired me to use compression/minify techniques)

I went back and revisited my idea and while I still have as of yet to re-build my 'hexify.pl' script (and likely will to work with this new code including adding upload capability right inside the code), I needed seriously to get the code working on the AsyncWebServer code as large files tend to crap out on the simple server code.
As suspected, when I finally got the code working with the Async server, not only do the large files not time-out repeatedly, they are served up much faster.
So what I ended up doing was adding a struct and some cheesy string manipulation (since SPIFFS is technically a flat filesystem - i.e. not really using directories) to derive a file basename, extension and path. Then I wrote a wrapper around that which will use the information to try 'alternative' path names for any file that does not exist as requested. I'm still debating whether to limit using the alternate look-up method with conditions to only run on files that are appropriate. But currently it will first try the path given, if not found, it will try appending ".min" between the basename and extension, try adding .gz on the end then try doing both at the same time. (The .min code won't run if .min. is already in the full filename and the .gz code doesn't run if the path is already ending in .gz) If finished 'true' pathname has .gz on it, the server adds the Content-Encoding: gzip header to the output. I also added code to check the finished path size to make sure it wouldn't exceed the 32 character maximum.
With testing some examples, I was able to get it to work on minified, gzipped versions of jquery, bootstrap, angular and similar large libraries and serve them up with no fuss at all. I'll probably eventually refactor this code into a separate library.

My todo list presently includes rebuilding my perl code to help minify/compress content that is 'in progress' from a separate www tree, add parameters to invoke this script manually on a specific file and to tell it whether to copy the result into the data/ directory of your project or to try uploading it to an OTA device directly.
The server code currently supports a delete and an upload functionality and I added a GET parameter to the uploader to allow a 'dir' parameter to be prefixed on the front of the filename uploaded. This code also tests for the finished path length to make sure it doesn't exceed 32 characters. I remove the 'deleteRecursive' functionality of the SD server code as it was kind of extraneous when emulating directories. I also may re-visit the code to try to implement the editor code included in the SD server code and will likely add more jJSON/Ajax style interaction to the filesystem commands (delete/upload/printDirectory/etc).

https://github.com/treii28/ESPAsyncFlashWebServer
User avatar
By Stickybit
#77102
local_dani_21 wrote:I put a ZIP-archive under http://www.wunderwald.ch/esp.

Best regards, Dani


Hi Dani

Just tried your example, but it didn't compile. Any thoughts on this one? :-)

Regards Sticky

exit status 1
no matching function for call to 'WiFiClient::write(_FLASH_ARRAY<unsigned char>&, int)'