pyserial and com port interrupts

[engsol]

Has anyone done a script that will rspond to the serial com port(s)
receive buffer interrupt, as opposed to polling and timeouts?
Win2000 is the main interest right now.
Thanks
Norm B

 

[Peter Hansen]

Has anyone done a script that will rspond to the serial com port(s)
receive buffer interrupt, as opposed to polling and timeouts?
Win2000 is the main interest right now.

What problem do you hope to avoid by not using "polling
and timeouts"? (Note that if you specify a sizable
read timeout, you're closer to being interrupt-driven
than you are to what is traditionally called "polling".)

-Peter

 

[engsol]

What problem do you hope to avoid by not using "polling
and timeouts"? (Note that if you specify a sizable
read timeout, you're closer to being interrupt-driven
than you are to what is traditionally called "polling".)

-Peter

Peter,
Thanks for the reply. I'm working on a s/w test program using python
code. Com1 and com2 play a part. The problem is that the python code
has a lot of work to do...and the results from the hardware under test can
come from either com1 or com2...at any time. It may be a few milliseconds,
or several seconds, sometimes minutes, before a response is expected.
I'm not sure what timeout value I'd use. Using threads, and re-loading the
timeout values on the fly may be a solution, but I'm not experienced with
threads....and was hoping to avoid them.
Norm B

 

[Bengt Richter]

Has anyone done a script that will rspond to the serial com port(s)
receive buffer interrupt, as opposed to polling and timeouts?
Win2000 is the main interest right now.

Have you looked into letting the OS do it? I.e., reading from COM4:
or whatever port in a thread maybe one byte at a time? Maybe you can
get your end functionality without writing low levels stuff, depending ;-)

I haven't done this, but it seems an easy thing to try a few experiments with.
The control panel should let you set baud rates and handshaking etc. I would think.

Regards,
Bengt Richter

 

[Stephen Thorne]

Have you looked into letting the OS do it? I.e., reading from COM4:
or whatever port in a thread maybe one byte at a time? Maybe you can
get your end functionality without writing low levels stuff, depending ;-)

I haven't done this, but it seems an easy thing to try a few experiments with.
The control panel should let you set baud rates and handshaking etc. I would think.

PySerial[1] is more than capable of handling all the low level
operations with little more than 's.baud = 9600'. The OP was more
interested in how to write his program so he could react to com port
input in a timely manner in the face of having blocking procedures
elsewhere in his code.

Regards,
Stephen Thorne

[1] http://pyserial.sourceforge.net/

 

[Grant Edwards]

I'm not sure what timeout value I'd use. Using threads, and re-loading the
timeout values on the fly may be a solution, but I'm not experienced with
threads....and was hoping to avoid them.

Using threads in Python is really, really painless.

 

[Neil Benn]

Has anyone done a script that will rspond to the serial com port(s)
receive buffer interrupt, as opposed to polling and timeouts?
Win2000 is the main interest right now.
Thanks
Norm B

Hello,

I came across this problem as when I first used PySerial, I
came from a java background which has the ability to register listeners
to a serial comm instance and receive interrupts (although some
implementations use polling behind the scenes anyway). I don't think
that pyserial has this kind of thing so I used the following :

def __checkSerial(self):

self.__objLock.acquire()
try:
try:
intNoChars = self.__objSerialPort.inWaiting()
if (intNoChars > 0):
strReceivedString =
self.__objSerialPort.read(intNoChars)
#or you could fire an event
self.newMessage(strReceivedString)
except:
#put any clean up code in here.
raise
finally:
self.__objLock.release()

You can then wrap this in a thread which runs the method every x
milliseconds (the code to ensure that I have all the information is
elsewhere in a superclass which deals with this use case across
communication implementations). However you will have to be aware that
you will need to lock around groups of calls to ensure you are receiving
the correct information (as above).
Therefore, although threading in Python is 'easy' you would still
have to think about this issue, it is unavoidable in communications I'm
afraid. Even if you could receive interrupts then you will likely be
receiving the interrupt on a different thread of execution than the main
anyways so you'll still have threading problems and need to lock around
calls. This is the problem which I usually express as '/RS232C is not
really a standard, more of a rumour/'.

Interestingly, if we take the 'python in threading is easy'
discussion (partially due to the GIL), then for this use case we could
also say that threading in VB6 is even easier than python - I'll leave
you to guess why!!!

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : +49 (0)351 4173 154
e-mail : (e-mail address removed)
Cenix Website : http://www.cenix-bioscience.com

 

[Neil Benn]

Hello,

I came across this problem as when I first used PySerial, I
came from a java background which has the ability to register
listeners to a serial comm instance and receive interrupts (although
some implementations use polling behind the scenes anyway). I don't
think that pyserial has this kind of thing so I used the following :

<snip>

Tabs got screwed up here is teh code again :

def __checkSerial(self):

self.__objLock.acquire()
try:
try:
intNoChars = self.__objSerialPort.inWaiting()
if (intNoChars > 0):
strReceivedString =
self.__objSerialPort.read(intNoChars)
self.newMessage(strReceivedString)
except:
raise
finally:
self.__objLock.release()

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : +49 (0)351 4173 154
e-mail : (e-mail address removed)
Cenix Website : http://www.cenix-bioscience.com

 

[Peter Hansen]

I'm working on a s/w test program using python
code. Com1 and com2 play a part. The problem is that the python code
has a lot of work to do...and the results from the hardware under test can
come from either com1 or com2...at any time. It may be a few milliseconds,
or several seconds, sometimes minutes, before a response is expected.
I'm not sure what timeout value I'd use. Using threads, and re-loading the
timeout values on the fly may be a solution, but I'm not experienced with
threads....and was hoping to avoid them.

I'm with Grant on this: threads in Python are really easy. If
you can describe a little more about what you need/would like
to do with the serial data when it *does* arrive, and how that
relates to the "lot of work" that the rest of the code is doing,
I'm sure there are a number of helpful replies just waiting to
be written to convince you how easy it really is.

For example, if you need to retrieve the data from the serial
ports right away, so the sending device doesn't block or lose
data, but can afford to just store it for later processing
when the main thread has time, that's only a few lines of
code.

If you actually want to reply immediately, then the only
real question is how you come up with the reply. If it needs
data from the main thread, we can show you several easy and
appropriate ways to do that with no thread safety issues.

If you're not experienced with threads, there's almost no place
better to start learning than with Python and c.l.p.

-Peter