Feature: Startup delays for easier debug logging

[mk-pmb]

Missing feature

Configurable independent startup delays for the startup task (typically init.lua), and the default UART interface (greeting + REPL).

Justification

When trying to share my output from REPL sessions, I spend effort each time to cut out the line noise fort the reboot (if I start logging before), or have to manually insert the greeting message with system information (if I start logging after). It would be way easier to automate if there was more time in between. Thus I'd like to add an option for delaying the startup banner and REPL. Ideally there should be an independent option for how long to delay execution of the startup task. This way the MCU can still initialize connected hardware to a safe state so it can immediately be used in the REPL and not suffer side effects from the REPL startup delay.

What do you think? Would this be useful for others as well?

Workarounds

Manually fixing the logfile.

[TerryE]

I use the python miniterm for most of my debugging -- largely because I need to swap between a terminal session and elf-gdb when I am debugging the firmware.

You clearly have a host-side connection model in mind here for doing your REPL sessions. It would be really useful if you write this up as a gist or equiv so we can see what your dev model is. Also IMO, there is little point is adding functionality to core unless the expected usage merits the extra maintenance load and firmware bloat.

Part of the complexity here is that boot sequence include bot ROM output as well as SDK output before the NodeMCU firmware takes control of output and sets the baud rate, so you get output various baud rates including 74880 before the final baud rate, so you might need to do your own wrapper, but I can't really discuss this further until I understand your basic dev cycle.

[mk-pmb]

I'm still trying to establish a good dev cycle. I've tried to make a basic TCP server on the MCU that I can upload my files to, but I constantly run out of memory. My hope is that once I get LFS to work, it will free up enough RAM to make stuff work.

For now my setup is that I have a LoLin v3 ESP8266 connected via its onboard USB interface to a Ubuntu computer. I use GNU screen to talk to the serial port. GNU screen has a built-in logging facility which writes verbatim copies of each byte received. For file upload I have a small script that can take over the hardware uart to receive base64 encoded bytes and write them to a file, then return the uart to default REPL mode. I also have an uploader that can inject scripts or base64-encoded files into screen's serial port window as if I had typed them.

For firmware updates I build them on Github, usually wifigpio-pmb, sometimes daily vanilla for comparison, and upload them with a thin wrapper around esptool.

[nwf]

@mk-pmb For TCP transport, you may wish to look at my telnetd, especially its file support, at https://github.com/AcmeTensorToys/esp-lua_core/tree/main/telnetd , and the script I use host-side to drive it, at https://github.com/AcmeTensorToys/esp-lua_core/blob/main/host/pushvia.expect .

For serial transport, I wrote https://github.com/nwf/nodemcu-firmware/blob/dev-active/tests/expectnmcu/xfer.tcl (see its use in https://github.com/nwf/nodemcu-firmware/blob/dev-active/tests/tap-driver.expect ) which does similar base64 games but avoids taking over the raw uart (that is, it suffers some inefficiency because it transports data using the REPL). There's also https://github.com/4refr0nt/luatool but it expects to move Lua source only and has some caveats to it.

[mk-pmb]

Thanks! I'll have a look. I'm trying to go for WebDAV though. (And until then, my uart uploader is probably good enough.)

[TerryE]

Outside of NodeMCU development, I do some remote (headless) server management, and I use screen here but mostly so I can keep the sessions active even if I loose the TCP connection, and for screen sharing. I do use it for screen logging when I need it but TBH I have terminal set up with a large scroll window so just copy off that for recent history. A PITA about using screen for tty connection is that it only supports the standard baud rates and not ones such a 74880 (which you might need for boot diagnostics) and also clears the history on exit, so I just use miniterm now.

I map my distro directory (which my make build to) to an Apache subfolder so I can pull LFS images from this service form my ESPs using a pretty bare image loader. This uses flow control and is fast. (All of this is is firewalled off from direct internet connection.) I also have a minimal uploader for bootstrapping files when I an direct ttyUSB connected. I also add the ftpserver and telnet to the LFS images on my wifi connected ESPs for troubleshooting, and my apps remote APIs include commands to enable these.

WebDAV is too much trouble for what it's worth, IMO.

[TerryE]

PS @mk-pmb, I know REPL as an acronym (read evaluate print loop), but you seem to be using this in the context of a specific package. Which one? Are talking about repl.it?

[mk-pmb]

With REPL I meant the sofware on the ESP that I can talk to via the hardware UART. Now thinking about it, it only prints when I specifically request it, so probably not really a REPL, rather the LUA interpreter.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mk-pmb]

I still want this.

[mk-pmb]

GitHub doesn't offer me a way to re-open, so I guess we'll have to bow to stale bot's authority argument. I'm confused why adding two delays can be as hard as it seems to be.