pyserial and end-of-line specification

Rob Gaddi rgaddi at highlandtechnology.invalid
Wed Jul 19 14:25:25 EDT 2017


On 07/18/2017 12:53 PM, FS wrote:
> Thank you for your response Andre. I had tried some code like that in the document but it did not seem to work. However ever leaving my terminal for a time the code eventually wrote out the records so apparently there is some very deep buffering going on here. A little more searching on the web revealed the following:
> 
> https://stackoverflow.com/questions/10222788/line-buffered-serial-input
> 
> It is apparent that pySerial, or at least the documentation is falling short of my needs. It is very unclear what module in the layer is handling the buffering and newlines and so forth. Also unclear is whether the coupled python and OS is reading FIFO or LIFO--something important in quasi realtime scientific applications.
>    This is problematic since the serial port is still so ubiquitous to a lot of scientific instrumentation. I probably will patch up some byte oriented code for this or perhaps write the module in C.
> 
> Thanks again
> Fritz
> 

Handling it .read(1) at a time is probably your best bet.  Append them 
into a bytearray and pull it all out when you're done.

It's a serial port; it's not like there is any degree of inefficiently 
that you could write the code that will make it slow with respect to the 
I/O.  I write a LOT of serial instrument I/O and I've definitely had to 
fall back to this plan.  Your code gets a little long, you hide it all 
in a function somewhere and never think on it again.

One paradigm I stick for ASCII serial is to have 3 functions:

def command(msg: str):
     """Sends a command, raises CommError if it doesn't get some
     expected OK sort of thing."""

def query(msg: str):
     """Sends a commmand, returns a (trimmed) response line."""

def _communicate(msg: str):

The ugliest stuff, all the str->bytes->str stuff, the line-ending and 
protocols, goes into _communicate.  Query usually just calls 
_communicate.  Command slaps on whatever checks are needed.  It feels a 
bit heavy, but it leads to highly-usable code and makes it easy to 
integrate logging, retries, integrating "*OPC?" handshakes, whatever 
sort of things turn out to be necessary on a given device.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.



More information about the Python-list mailing list