@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:
%q
format specifier to ensure than any such resource can be embedded in compilable format into the intermediate source format, butreturn 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.
tmr.delay()
, delay I meant in general - to put delay between doing tasks and for sure non-blocking, using tmr
in 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
Setting IDF_PATH and re-invoking...
/bin/sh: 1: Syntax error: "(" unexpected
Makefile:21: recipe for target 'all' failed
make: * [all] Error 2
@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/HEAD
I showed the head ref, too just in case something was fixed before I posted.