Thanks for your responses everybody
gmx re "the Pico does not 'wait' rather it delivers each bit as whole message" What I meant was the Pico (low level deep driver code) did not wait for the NL at the end of the message like it was suppoed to -
rather (Looking at the picture from the scope above) it delivers each of the data parts (yellow trace) as a seperate message back to my code
re 'I wonder if the flow control is the problem' I kind of agree with you all.
I only tried this flow-control approach when all attempts to do it easily failed to find an answer as to why I was getting truncated messages.
I fiddled with baud rates, timeout values and cycle time (from the Test Harness - how long before next call), and different read() methods - all to no avail.
Its also very fiddly with the timeouts meaning different things on each end. I finally got the code to reveal the settings it was using including ones I had not set.
The RPi ('Host' sending side) has write_timeout set to None
The Pico (receiving side) has timeout=0 meaning dont wait for 1st character - there is nothing there. Also timeout_char=1 which is in ms.
After just confirming this I saw that the Pico (UART) end you can also change the size of the RX buffer - I upped it to 512, much bigger than the test message, but that made no difference.
Given this is running on a microcontroller which severely limits its ability to thread or multi-process AND it is but a tiny piece of the overall puzzle; I dont think its wise to get into writing more delicate, timing dependent code.
Maybe back out all the CTS/RTS and restrict the application to a message length I know can go through. Or use a 'Part-1', 'Part-2' protocol.
P.S its also annoying that the PICO UART code can only 'decode' from UTF-8 not 'Ascii' so there are unnecessary conversions and, with the real messages (not just these test ones) many unnecessary escape code sequences that increase the actual sent message length.
Thanks again.
Any additional suggestions ?
JC
gmx re "the Pico does not 'wait' rather it delivers each bit as whole message" What I meant was the Pico (low level deep driver code) did not wait for the NL at the end of the message like it was suppoed to -
rather (Looking at the picture from the scope above) it delivers each of the data parts (yellow trace) as a seperate message back to my code
re 'I wonder if the flow control is the problem' I kind of agree with you all.
I only tried this flow-control approach when all attempts to do it easily failed to find an answer as to why I was getting truncated messages.
I fiddled with baud rates, timeout values and cycle time (from the Test Harness - how long before next call), and different read() methods - all to no avail.
Its also very fiddly with the timeouts meaning different things on each end. I finally got the code to reveal the settings it was using including ones I had not set.
The RPi ('Host' sending side) has write_timeout set to None
The Pico (receiving side) has timeout=0 meaning dont wait for 1st character - there is nothing there. Also timeout_char=1 which is in ms.
Code:
Host_ser Serial port open baud= 230400 and timeout = 0.05 Serial<id=0x7fac416e30, open=True>(port='/dev/serial0', baudrate=230400, bytesize=8, parity='N', stopbits=1, timeout=0.05, xonxoff=False, rtscts=True, dsrdtr=False)self.ser.write_timeout = Noneself.ser.inter_byte_timeout = NoneCode:
PICO_ser Serial port open baud= 230400 and timeout = 0UART(0, baudrate=230400, bits=8, parity=None, stop=1, tx=16, rx=17, txbuf=256, rxbuf=256, timeout=0, timeout_char=1, invert=None, irq=0)***** Starting Pico Serial TestHarness3 / (Pico-T3) mainThrottle = 0.01Given this is running on a microcontroller which severely limits its ability to thread or multi-process AND it is but a tiny piece of the overall puzzle; I dont think its wise to get into writing more delicate, timing dependent code.
Maybe back out all the CTS/RTS and restrict the application to a message length I know can go through. Or use a 'Part-1', 'Part-2' protocol.
P.S its also annoying that the PICO UART code can only 'decode' from UTF-8 not 'Ascii' so there are unnecessary conversions and, with the real messages (not just these test ones) many unnecessary escape code sequences that increase the actual sent message length.
Thanks again.
Any additional suggestions ?
JC
Statistics: Posted by jc508 — Thu Feb 05, 2026 11:15 pm