- Fri May 12, 2017 2:01 pm
#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
Moderator: igrr
- Sun Aug 27, 2017 1:07 pm
#69490
I re-visted my perl script again to make it a little more versatile. I got it stable enough with sufficient features that I figured it was about time I shared it somewhere:
https://github.com/treii28/ESPWebFlashServer
https://github.com/treii28/ESPWebFlashServer
- Tue Sep 12, 2017 8:21 am
#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
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
- Tue Jul 17, 2018 10:12 am
#77102
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)'
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)'
