MicroPython Forum (Archive)

I like that idea - explicitly initializing the UART would disconnect the REPL from it. Nicely avoids the issue of inventing an API to do this. The drawbacks would be no way to change the baud rate for REPL, no way to reverse the operation (get the REPL back) without reboot, and no mixing "raw" UART ...

Agree, overloading the semantics of esp.osdebug(None) is not a good long-term solution. There are several alternatives, the simplest of which might be to create a new constant, e.g. NO_UART_REPL=(-2) and invoke esp.osdebug(NO_UART_REPL) instead. It's on my todo list to evaluate a better API for this...

When you call esp.osdebug(None), it sets uart_os = -1.
Within the esp8266 port, search for uart_os_config in modesp.c and uart.c.

My patch extends the existing meaning of (-1) to fully decouple UART from REPL.

Yes, I will do that. Thanks.

Redirecting the UartREPL to /dev/null while keeping the WebREPL active is effectively what my patch does. So what's a "proper" API to achieve this? I agree that eliminating the startup garbage would require changes to ESP code outside the Micropython sources. For my purposes it's not a problem since...

Yes, using the WebREPL while having fully independent control of the UART interface is nice. In general it's good to have STDOUT/STDIN decoupled from any particular interface (our lonely UART in the case of ESP8266). As I mentioned in my previous post, I'd like to hear from other MP users regarding ...

Definitely would be useful to be able to "disconnect" the REPL from UART0, and use it independently. Yes, you still have to tolerate the startup garbage, but after that the UART could be fully under application control - while still using WebREPL for example. @deshipu's recent change gets one step c...