You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basically, in my test I connect PA9 to PA10, PB10 to PB11, and PA2 to PA3.
I do the same thing with an off the shelve USB to UART converter.
Then I run this Python Program which tests if the data it sends comes back:
#!/usr/bin/env python3
import serial
import os
s = serial.Serial("/dev/ttyUSB0", 115200)
iteration = 0
while True:
barr = bytearray(os.urandom(1))
s.write(barr)
aarr = s.read(len(barr))
for i in range(0, len(barr)):
if aarr[i] != barr[i]:
raise Exception("Received data doesn't match: data=" + str(barr[i]) + " device=" + str(aarr[i]))
print("iteration sucessfull: " + str(iteration))
iteration += 1
On the off the shelve USB to UART converter it runs flawless. On the pill_serial none of the /dev/ttyACM[0-2] work with this.
It's not like the device doesn't work for me at all. It just seems to work very unreliably and in this test case I managed to make it always fail.
The text was updated successfully, but these errors were encountered:
I actually just tried this solution with the define to 32. While it makes the Python script not freeze immediately, the test will hang up after somewhere in between 10000 and 100000 iterations.
The test doesn't fail with corrupted data but rather it just seems to drop a byte. Therefore it'll hang in the s.read(1). It could certainly also be an electrical issue with the UART, still, my wires are pretty short and it happens accross all 3 UART ports. No such issue with the off the shelve part (and pretty long wires on that one).
Without reading the firmware code I'd suspect a more serious bug than a simple buffer size being too small. I'm just sending one byte over the UART until a single byte comes back. So there shouldn't be any buffers building up and/or overflowing.
USART1, USART2 and USART3 also provide hardware management of the CTS and RTS signals,
My educated guess is that connecting Clear To Send and Request To Send will improve the situation. But please be aware that I'm saying this without reading the firmware source code.
So I was having some issues with pill_serial where I wanted to connect the UART to some external device and it was loosing data for some reason.
This might possibly be related to #1
Basically, in my test I connect PA9 to PA10, PB10 to PB11, and PA2 to PA3.
I do the same thing with an off the shelve USB to UART converter.
Then I run this Python Program which tests if the data it sends comes back:
On the off the shelve USB to UART converter it runs flawless. On the pill_serial none of the /dev/ttyACM[0-2] work with this.
It's not like the device doesn't work for me at all. It just seems to work very unreliably and in this test case I managed to make it always fail.
The text was updated successfully, but these errors were encountered: