pySerial .read()

[mike_zah]

I'm using pySerial in my program and have a question regarding the .read(). Basically I have a loop that monitors .inWaiting(). When there is NOT ZERO bytes in .inWaiting(), the program grabs one byte .read(1) and then processes it. Some times this processing can take some time, which can allow a number of bytes to be in waiting, the next time a .read(1) is done. My question is, when the buffer has more than one byte waiting to be retrieved and the .read(1) command is used, which byte is retrieved? The last in or the first in? Thanks, Mike

[deanhystad]

The read queue is a FIFO. First In, First Out. Why are you asking? It seems like a very simple thing to test.

And what are you doing in your waiting loop while waiting? Blocking on a read is pretty efficient. Looping and checking if there are bytes in the buffer is very inefficient. At the very least I would use a read with a timeout unless it is very important that the read never blocks.

[mike_zah]

Thanks, I would think that it should be FIFO, but I'm having trouble missing bytes. My program is to take bytes from a PDP8E serial port at 9600 baud convert the ASCII byte to a FRIDEN code and output that code to my Friden SFD typing machine. The Friden is very slow. If the PDP8E spits outs 10 characters at 9600 baud, the Friden has not yet finished typed the first character. The loop checks the .inWaiting() and then has to grab the byte convert it and send it to the Friden. Once the typing is complete it comes back to the .inWaiting() to get another byte to type. For some reason a string of 10 or 12 bytes sent from the PDP8E, will have 3 or 4 completely missing characters. AND after the CRLF sent by the PDP8E there are a few extra characters. That is why I was thinking that maybe the .read() may not be FIFO. Well....... I'll have to look else where. Thanks for the help, Mike

[deanhystad]

You should post your code.

[mike_zah]

It's a little difficult without the understanding of how the Friden actually works. A Friden key press will immediately type that key and set up a selector code and strobe. This code and strobe is sent to a RPI which converts the code to ASCII and then sends it out to the DEC PDP8E. In reverse, if the PDP8E sends a response, the RPI again grabs the ASCII code converts it to Friden and generates a Friden strobe. This causes the typing machine to type the character. Problem is the PDP8E echo back also causes the selector contacts to generate a key code and strobe. Thus sending the key code back to the PDP8E. My first attempt at this caused a feed back loop. One character entered caused an endless string of that character being typed. The Friden works in 1/2 duplex. I'm attempting to work my code so as to deal with one character at a time from either machine, but I'm thinking that I may need to change my code to work on a line basis. If the user types on the Friden, the RPI holds all the characters until the CRLF is received. Same for the PDP8E transmission, save all the characters until a CRLF or a period prompt is received. Thanks for the help, but I believe I need to rethink the entire process. Ignoring the PDP8E full duplex echo back and Ignoring the Friden's sending code regardless of a key press or data received is proving to be my problem. This maybe confusing, but I'll get it, Thanks, Mike ---- ps I ruled out any problem with the .inWaiting(), my code code works fine if I just disconnect one of the machines so that the echo backs are really ignored.