@chathurangawijetunge, you should generalise this Q and consider HTML as a special case: when is it appropriate to store resources in LFS and when the alternatives are a better fit. Lua as a language can only support numeric, boolean and string constants in code; anything more complicated: array, function closures, have to be constructed at runtime. LFS stores Lua code so it can only support the former. It makes sense storing resources as string in LFS code if you need fast access paths, but there is a cost in readability and maintainability. So sometimes the alternatives can be better such as:
return file.getcontents('someresource.dat') -- or even
return sjson.decode(file.getcontents('someresource.dat'))Also remember than in terms of storing HTML, then it is well worth separating the true constant stuff: CSS JS and even some HTML furniture is constant files which you can run through gzip on the host and store the compressed form as file or even string resource-s on the ESP. Just use the Content-encoding: gzip response to that the browser knows to unpack it. This is good example of where leaving the compressed resource as a file is just so much easier.
When it comes to storing complex resources in strings:
- Consider preprocessing the resources host-side and using a small bash/Python/Lua script to generate the file automatically from the bare resources.
- You can use the
%qformat specifier to ensure than any such resource can be embedded in compilable format into the intermediate source format, but - You might find that base64 encoding is just so much more readable:
return encoder.fromBase64[[...]]
is there a way to update string (let’s say json) in a file without overwriting whole contents or appending line at the file end?
Think about it: a structure encoded in JSON has a very strict grammar; even something as simple as replacing a string value with another 1 byte longer is going insert an extra byte in the middle of the encoded string, so there is no practical way to do this with file primitives. It's a lot easier just to rewrite the entire file with the new version, say by doing a file.putcontents() with the new encoded string. Work internally in RAM with Lua structures and only serialise them to SPIFFS if you want to keep a non-volatile copy to persist over restarts.
tmr alarms
tmr.delay() function just calls a ROM bootloader delay function, which isn't masked to ISRs and so can be used safely up to a few mSec, but I would suggest doing an alarm for much more than that. This isn't a time critical delay so a wobble of a mSec or 2 won't make any difference.
tmr.c for an example of how to do this.
I’m not using
tmr.delay(), delay I meant in general - to put delay between doing tasks and for sure non-blocking, using tmrin this manner: tmr.create():alarm(10, tmr.ALARM_SINGLE, function(t_ads) adc1:startread(function(volt). Saying “not optimal” I meant that usually, when you have device library it should do these small tasks and you should be free of thining about “did I forgot to put delay between readouts”. I will do readings today using different timing and will return with results.
Uncompressing toolchain
the archive contains ro files
Setting IDF_PATH and re-invoking...
/bin/sh: 1: Syntax error: "(" unexpected
Makefile:21: recipe for target 'all' failed
make: * [all] Error 2
/bin/sh: 1: Syntax error: "(" unexpected
Makefile:334: recipe for target '/home/thomas/nodemcu-firmware/nodemcu-firmware/sdk/.pruned-3.0-e4434aa' failed
make: * [/home/thomas/nodemcu-firmware/nodemcu-firmware/sdk/.pruned-3.0-e4434aa] Error 2
make: Leaving directory '/home/thomas/nodemcu-firmware/nodemcu-firmware'
@tjakober What are your .h changes. I just used linux x64 w/o issue on default...
git clone --recursive https://github.com/nodemcu/nodemcu-firmware
cd nodemcu-firmware
make -j8
git show-ref | grep HEAD
71a182caa7841cbb478ed90ede526dc881943c80 refs/remotes/origin/HEADI showed the head ref, too just in case something was fixed before I posted.