rp2: uasyncio: sys.stdout not working
the Pico port does not have a separate USB_VCP object so we resort to use sys stdio. while receiving works, transmitting blocks or crashes on writing. other ports like the pyboard support this. It would be good if this works so that uasyncio communication can be done via USB too.
Here is a minimal example for testing:
echo.py.txt
- It works on a pyboard (pybv11-20210302-unstable-v1.14-82-gcdaec0dca)
- It works on the unix port (though with
sys.stdoutinstead ofsys.stdout.buffer) - It fails on the pico (rp2-pico-20210301-unstable-v1.14-82-gcdaec0dca)
- [edit] it fails on the esp32 (esp32-20210302-unstable-v1.14-82-gcdaec0dca)
Output when it fails (drain never outputs anything on pico and esp32):
# ready
.# input b'hello\r\n'
# drain
.........Traceback (most recent call last):
[...]
KeyboardInterrupt:
And there is an exception on the pico (not on esp32) when the feedback_task is not started, pressing RETURN twice results in:
# ready
# input b'hello\r\n'
# drain
Traceback (most recent call last):
File "<stdin>", line 32, in <module>
File "<stdin>", line 29, in echo
File "uasyncio/core.py", line 1, in run_forever
File "uasyncio/core.py", line 1, in run_until_complete
IndexError: empty heap
Compared to an output on the pyboard, where it echoes and goes back to reading as expected:
# ready
...# input b'hallo\r\n'
# drain
.hallo
# ready
[...]
rp2 More USB woes
I raise this in case it sheds any more light on the USB issues.
I am using rp2-pico-20210209-unstable-v1.14-11-gc7aaee2b2.uf2.
I have a substantial uasyncio application developed on Pyboards and ported to the Pico. The test script outputs regular messages via print statements. The application maintains a heartbeat LED via a coroutine on the Pico.
It runs fine if I suppress all print output.
With print statements enabled it also runs so long as I periodically press a key on the keyboard (in rshell or in miniterm). If I don't, it runs for a while then stops. The heartbeat stops flashing until I press a key, when running resumes. The code has evidently stalled.
Unfortunately my attempts to create a trivial test case have so far failed. I have never encountered this behaviour on Pyboards, ESP8266 or ESP32.