Esp8266 uart fixes #2990
Esp8266 uart fixes #2990
Conversation
Revert part of previus commit
|
This is essentially a duplicate of #2891. Please look at that PR and associated discussion. |
|
Well, I actually started from #2891. |
|
Hi guys, Has this been closed incorrectly? It appears to be useful, would be good to double-check |
| @@ -108,6 +108,7 @@ void init_done(void) { | |||
| #endif | |||
| } | |||
|
|
|||
| // Seems unused | |||
There was a problem hiding this comment.
Unrelated change.
Also, "seems" sounds dangerous. This patch also "seems" to work, right?
|
Ok, yes, it's not a duplicate of #2891, although it's related. What you are really trying to do here is disable ctrl-C being picked up by the UART interrupt and turned into a KeyboardInterrupt exception. And that can be done in a simpler way that what's presented here, essentially all you need to do is call mp_hal_set_interrupt_char(-1) to disable it. This is a general problem for all ports that needs to be solved. The same issue is reported recently for the microbit: bbcmicrobit/micropython#423 stmhal solves it by providing USB_VCP.set_interrupt(): passing -1 disables ctrl-C, and passing any number between 1-255 enables interruption using that char (eg passing 3 corresponds to crtl-C). So it remains to define a port-agnostic way of changing the interrupt character from a script. Since the function is related to the core of uPy I propose putting it in the micropython module as: micropython.kbd_intr(value)It would just call mp_hal_set_interrupt_char with the given value. |
| @@ -81,7 +81,7 @@ typedef struct { | |||
| UartBautRate baut_rate; | |||
| UartBitsNum4Char data_bits; | |||
| UartExistParity exist_parity; | |||
| UartParityMode parity; // chip size in byte | |||
| UartParityMode parity; // even/odd | |||
There was a problem hiding this comment.
Not very related change, should be submitted separately.
| @@ -92,12 +92,12 @@ typedef struct { | |||
| } UartDevice; | |||
|
|
|||
| void uart_init(UartBautRate uart0_br, UartBautRate uart1_br); | |||
| int uart0_rx(void); | |||
| @@ -165,22 +171,29 @@ static void uart0_rx_intr_handler(void *para) { | |||
| // fifo full | |||
| goto read_chars; | |||
| } else if (UART_RXFIFO_TOUT_INT_ST == (READ_PERI_REG(UART_INT_ST(uart_no)) & UART_RXFIFO_TOUT_INT_ST)) { | |||
| // rx timeout | |||
| read_chars: | |||
|
The pull request title appears to be incorrect - the patch doesn't seem to provide "fixes", but rather something else. To help with timely reviews, please use descriptive titles. Thanks. |
|
This feature is now available by calling |
|
Hi Damien, thanks for following up on this. It seemed that the original intent of some of these PRs was to allow (all) interpretation of input on the UART by the repl to be disabled. Do you know if this is currently the case? It seems from the description that if a serial device is attached to UART1 then buffers will still fill and the REPL will attempt to interpret the data received, save for control-c |
That is what #2891 is trying to do. And we will still work towards that feature.
The UART buffer will fill. If your scripts is running then the REPL is not active and will not touch the UART buffer. So your script is free to take the data from it. If you run |
|
Ah, got it. Ok thanks |
|
@dpgeorge Hi, |
|
@mohpor did you try using the new micropython.kbd_intr() function? The code @svily0 posted above can now work correctly using this function, like: import micropython as mp, machine
uart = machine.UART(0, 115200, timeout=500)
def uart_listen():
mp.kbd_intr(-1)
try:
data = bytearray(0x100)
n = uart.readinto(data)
print(n, data)
finally:
mp.kbd_intr(3)You can send (or type) any characters into the UART (even ctrl-C) and it will collect them all. |
|
I have not tested the code you have sent, but then again, I have no problem with Ctrl-C per se. |
|
Here it is my code sample (based on @svily0's PR): import time
import select
import esp
from machine import UART
import gc
uart = UART(0)
uart.init(9600)
def repl_on():
esp.replinput(0)
time.sleep_ms(10)
def repl_off():
esp.replinput(None)
time.sleep_ms(10)
def send(cmd):
cmd += "\r"
repl_off()
h = select.poll()
h.register(uart, select.POLLIN | select.POLLHUP)
uart.write(cmd)
data = ""
try:
while True:
gc.collect()
event = h.poll()
e = event[0][-1]
if select.POLLIN == e:
d = uart.read().decode()
data += d
print("NEW DATA: %r" % (d))
elif select.POLLHUP == e:
print("End received")
h.unregister(uart)
gc.collect()
return data
else:
print("Unknown event [%d] happened" % e)
h.unregister(uart)
gc.collect()
return data
finally:
repl_on()Sorry for the messy code, it is just a test. |
In that case I don't understand what the problem is...
No, this PR should not be needed, just use micropython.kbd_intr(-1) to "disable" the REPL, and micropython.kbd_intr(3) to "enable" it. To help fix your problem please tell how you are running your code (eg via UART REPL, script saved to flash, or WebREPL), what the output is and what you would expect the output should be, ie what the problem is. |
I said I'm a bit confused! That's wonderful news! will get on it right now! |
|
Can a UART object be closed so the kbd_intr() trick can be used on the webrepl? deinit() is unfortunately not implemented. |
Not yet. This all depends on #2891 and working out how to consistently (across ports) disable some source to dupterm. |
…n-master Translations update from Weblate
Doing something like:
when a ESP8266 is connected to the serial bus has the unfortunate effect of resetting the board.
Make it possible to put any data on the serial bus without REPL interpreting it.