MicroPython Forum (Archive)

It seems to depend on the code size as well. With a minimal code I see no error. If I just add some non-executed code lines, I get errors. So there seems to be something fundamentally wrong with threading and interrupts.

That sounds very wrong.
I do have a lot of code so ..

But that means that I might be able to get the whole thing to function if I stick to one core for now. That might be a solution for my problem at least. Since the uart writes are non blocking as you say, they might now be fast enough to stick everything in one core.

You can try to use a single thread only with sufficiently large transfer buffers. If that does not fit, I could make a firmware version with the previous version of uart.write().

So I made some further tests:
Using the previous version for machine.uart does not change the picture a lot. The crashes and lock-ups occur too. Only I have not seen the character doubling. So the latter seems just one variant of misbehavior caused by the underlying bug in threading.
Nevertheless I made a firmware version with the unbuffered version of machine_uart.c: https://github.com/robert-hh/Shared-Stu ... d_uart.uf2
Also, I raised an issue in the repository. Maybe I get helpful feedback,

Thank you very much, I'll try that tomorrow.

Afternoon

I too have experienced this issue with the new version on Micropython (1.15) on my Pico. All my code that require info form UART seem to have stopped working... if i roll back to 1.14 works immediately. I have also tried the Firmware mentioned in the thread with no luck.

Thanks
LUAP

The behavior of the UARt has changed from blocking to non-blocking. Now it is consistent to all other ports. If you call uart.read() and there is not data present, it will return immediately with the Value None. You can set a timeout value in the instantiation of the UART. Or you can check before calling with uart.any(), if data is available. UART now buffers incoming and outgoing data. The default buffer size is 256. You can change that with the rxbuf=xxx option in the instantiation.

So even if the update changed the behavior of UART, it is now identical to all other ports.

Does that mean it now also supports irq?

Yes and no. It uses IRQ for handling the input and output buffers. But you cannot set a handler to get called when data arrives.

P.S.: There is still a hiccup in RP2040 using two threads. The UART code has to be in thread0 only. And besides that, the RP2040 stalls (not related to UART) if the threads use dynamic memory a lot. So better stick to single thread mode.

I managed to rewrite my code to use a single core and it looks like the buffered UART's are now fast enough to not get in the way of my interrupt handling.
I haven't seen any errors from the UART using only one core.

I did have to increase the buffer on the receiving side (ESP32) because things were coming in too fast now.
Thank you very much for your help.