1

I have little experience on UART communication. I am using the PL011 UART instead of mini mart in a Raspberry Pi 3, therefore I should have parity bit. The thing is when I enable the parity bit in my script the message is misunderstood. My question is, do I have parity bit on PL011 UART or I am doing something wrong? I hope that you will be able to help me.

Raspberry Pi code:

import serial, time

ser = serial.Serial(
    port="/dev/ttyAMA0",   
    baudrate=57600,        
    parity=serial.PARITY_ODD,          
    stopbits=serial.STOPBITS_ONE,      
    bytesize=serial.EIGHTBITS,
    xonxoff=True
    )

print ("START")
time.sleep(2)
while True:
    print(ser.read())

Output:

h
Y
?
?

?
K
?
d
h
Y
?
?

?
K
?
d
h
Y
?
?

?
K
?
d
h
Y
?
?

The message sent is:

hello world

The client's code: import serial, time

 ser = serial.Serial(
     port="/dev/cu.usbserial-AH01W3BD",
     baudrate=57600,
     parity=serial.PARITY_ODD,      
     stopbits=serial.STOPBITS_ONE,  
     bytesize=serial.EIGHTBITS,
     xonxoff=True
     )

print "START SENDING"

while True:
    time.sleep(2)
    ser.write("hello world")
    print("Outputting transmiter buffer: " + str(ser.out_waiting))
    print("Outputting reciver buffer: " + str(ser.in_waiting))

Client's OS: macOS High Sierra

  • What output did you get when you did not have the parity bit enabled? And does the other side of the connection have the parity bit enabled? – NomadMaker Jul 6 '18 at 14:22
  • I got hello world, yes, the other side had the parity bit enable – Sergio Prieto Jul 6 '18 at 14:34
  • It would help to have the code for client. The server worked when it didn't have a parity bit, but failed when it did, so it seems wrong that the client does have the parity bit set. Could you put up a screen shot of the client settings, along with what type of machine and OS. Something is inconsistent. – NomadMaker Jul 6 '18 at 16:48
1

You will most certainly have a parity bit available on any UART chip. Whether you use it or not is another question. The most common serial configuration is 8N1, which means no parity bit is used.

If you wish to communicate between two serial ports, they will both need to be configured the same. I would recommend you start with 8N1, and get that working before you try other configurations.

  • Another suggestion is to use a serial terminal program (kermit or something similar) to simulate the client. That way there are fewer things to debug all at once. Or better yet, use kermit on both sides of the connection to make sure that the problem isn't in the cables or other hardware. – NomadMaker Jul 7 '18 at 23:41
  • @Seamus I have tried to communicate with 8N1, it worked perfectly but when I enable the parity the message showed in the Raspberry Pi is completely misunderstood. – Sergio Prieto Jul 8 '18 at 11:04
  • Making sure you're using the exact setup you have above, please stop any previous testing processes and run the server and client with odd parity. Then stop both client and server processes and change the code for both of them for 8N1 and rerun the test. I still think that the most likely problem is that the client and server got out of sync and that you were running one with no parity and one with odd parity by mistake. Not killing the server and client processes before running the test could do this. – NomadMaker Jul 8 '18 at 13:00
  • @SergioPrieto: If you use parity, you must use it on both ends. But why are you using it? I've done serial ports for years, and never once used parity. It's not necessary in most applications. – Seamus Jul 9 '18 at 21:19
  • @Seamus I am using parity at both codes. I am using it to ensure that no info is lost on the way. I have to establish a solid communication with a drone that is going to be 15km far from me. – Sergio Prieto Jul 11 '18 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.