esp8266: Allow disable of REPL on UART0 #3277
Conversation
…wait functionality
Previously was not checking rxbuf ringbuffer state correctly.
From @dpgeorge on micropython#2891: IMO this belongs in machine_uart.c, since it's specific to UART behaviour. Also, since UART1 can't receive it doesn't need to take an argument. Makes more sense here as it is UART specific.
Add flag to determine if UART object's rx should be sent to repl as well. When sending to repl all input is sent to input_buf as well as internal rxbuf. Note that this logic will need to be changed when dupterm slots stuff is implemented.
Apply the use_repl flag to TX in addition to RX. When flag is true then we send TX chars to UART, when false they don't go anywhere.
All logic now mediated by machine_uart which in turn handles the raw uart interactions.
Make sure we reallocate rxbuf if we change rxbuflen using UART.init().
This is needed to ensure rxbuf and use_repl are properly initialised on boot. With-out this we don't get working REPL on UART.
|
This is what I am waiting for. I will try it out. |
|
Man I was just looking for this, thanks for carrying the torch! |
|
Sure, happy to look into it. Couple of things that might be simpler resolved first.
|
The original discussion in #3144 was to leave index=0 free for the user to use, and then index=1 would have the UART in it by default. So that means the user can do But, looking at it again after some time, it does seem more logical to put the default REPL source at index=0. Doing it that way is not such a breaking change for esp8266 because WebREPL is the main user of dupterm and the WebREPL setup code must anyway change no matter what approach is taken. So might be better to aim for this behaviour, of UART at index=0.
It should already have exactly a readinto/write interface.
The esp8266 is short on RAM so objects should only be created if needed. Thus the UART should be created on the heap when needed and a pointer to it stored in the root pointers upon creation. |
|
@dpgeorge, while I'd love to get back to this, it's not likely to happen in the next month or so. Feel free to pick it up if you have the inclination in the mean-time. |
|
It would really be nice if this could somehow be made work in mainline. However doing that patch seems way out of my league as there seem so many changes regarding this from 1.9.1 (what this patch is for) to 1.9.3.. I assume nobody is interested to use the serial port on esp8266 upy for anything else than debugging as also all other related threads are dead? Is there any place where a normal human being mediumly skilled in c and c++ but not working 8 hours a day on upy development can start to revive this patch? |
|
Any updates on this? |
|
Sorry, this did get quite stale. It's not forgotten! |
|
Please see #3784 for my alternative to this PR. |
|
Ability to disable UART(0) on the REPL was implemented in afd0701 |
sharpdisplay: Prevent 'ValueError: <pin> in use' exception
This PR builds on the great initial work of @mhoffma in #2891. It rebases that work then extends those changes to address comments on #2891 by @dpgeorge, provide ability to enable/disable REPL and further decouple esp_mphal.c, machine_uart.c and uart.c from one-another
It pumps all UART RX into it's own ring buffer as well as conditionally to the main REPL input_buf. TX will go out on the UART as normal but this adds a conditional TX API for esp_mphal to use that will conditionally disable REPL TX to UART.
The conditional RX/TX behaviour is currently switched using an extra parameter to UART.init(). This would need to change to align with whatever is eventually decided in #3144. This shouldn't be very onerous if the
uos.dupterm(obj, index)approach is adopted.To make use of this behaviour the process is basically:
Boot ESP8266, connect via UART, use REPL on UART to setup webrepl.
Power down, connect whatever other device you want to your UART.
Boot and connect to webrepl.
Reinitalise the UART to disable REPL (and set other params as needed):
uart0.init(use_repl=0, baudrate=9600, rxbuflen=256)Use the webrepl and the Pythonic UART API to talk to your other device using UART without any weird REPL interaction!