Closed TerryE closed 3 years ago
Thanks for the info. Really great. Just wish I had more time for this project :)
@TerryE, if you would be so kind, have a look at the lua parts in https://github.com/kmpm/nodemcu-uploader/blob/master/nodemcu_uploader/luacode.py It works, but that is not the same as being correct :-)
Hi @kmpm Peter, I just wanted to reach out and coordinate what we are doing on the NodeMCU project itself. This might interact with your uploaded tool, as @joysfera has raised in nodemcu/nodemcu-firmware#2948.
With effect from SDK 3.0, the Lua runtime uses pipes to buffer Lua input and output. The SDK 2.x and prior versions only used the H/W uart buffers to buffer input whilst parsing input streams so it was extremely easy to overrun these. Now the input driver dumps the interactive input lines into a fifo (in the Lua registry at
stdin
) using a high priority SDK task, and the interpreter reads this at low priority. Likewise redirected output is also spooled tostdout
. This change has a few advantages:It is now a lot harder to overrun the input session when connected to
PuTTy
,miniterm
,telnet
, etc. You can happily paste in 50 lines of Lua as a single paste without it overrunning. Overrun is still possible because the SDK is non-preemptive, but rarely happens.Likewise printing is spooled and a separate printing task is scheduled to empty the Q. This means that applications like
telnet.lua
have all of their output marshalling done for them and so can send back the output to the telnet client in decent network packet chunks. Now error reports use the same mechanism so a telnet user can see Lua errors. Printing now gets interleaved with other Lua tasks so it is far less likely that a lot of printing at the slower baudrates causes watchdog timeouts.This makes the user experience a lot easier. The downside of the input and output being buffered by default is that automated uploaders might get out of sync.
This is really just a heads-up, and to open a channel to the NodeMCU team.