ESP8266 Community Forum

I've rewritten the section on how Lua sits over the SDK and how you need an event driven approach to Lua based applications on the ESP8266. Any feedback gratefully received. Thanks.

Thanks Terry. I brute forced which worked, but now I can substitute it for the ...

I'm primarily reporting and controlling io over mqtt. I've found the dynamic module approach very useful and effective. And I have the esp07 doing some heavy lifting with mqtt, ds18B20,6 inputs [4 interupt driven 2 being polled] and 3 outputs. This is done with 7 files all compiled to .lc except init.lua. I think Ive reached the limit of what can be run on this limited stack, but Im happy and my SwitchNode project is happily controlling my dual light switches.

What I did find is that the calling depth [stack?] eats away at the heap - up to 6K sometimes. The GC recovers this once the module is unloaded, so the code is [relatively] stable - it idles at 10k heap. but I found it interesting that this much stack can be used by an event and its calling depth.

There's a new build coming out soon which frees up another 17K RAM or so for a slight performance hit, but worthwhile overall, IMO.

It's well worth your while keeping your init.lua as small as possible e.g.
Also note that extension names are a convention only as the bytecode content is detected by the <ESC>Lua file header, so you can do a node.compile("init.lua")and if you want and rename the lc file back to init.lua. This way you avoid calling the compiler entirely which decreases memory fragmentation.

Also read my last section on the cost of subroutine calls, and use tailcalls wherever possible as this saves a stack frame.

Thanks for the Unofficial FAQ

It would be nice if there was an item on how to deal with include library functions. When there is a statement "require(xxx)",
does one load the xxx function into the esp8266 (just like loading init.lua or do_file) or does the language take care of this automatically from the source directory ?

Thanks,
Curt