Connecting Tech Pros Worldwide Forums | Help | Site Map

pyserial and com port interrupts

engsol
Guest
 
Posts: n/a
#1: Jul 18 '05
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
Guest
 
Posts: n/a
#2: Jul 18 '05

re: pyserial and com port interrupts


engsol wrote:[color=blue]
> 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.[/color]

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
Guest
 
Posts: n/a
#3: Jul 18 '05

re: pyserial and com port interrupts


On Wed, 12 Jan 2005 17:45:48 -0500, Peter Hansen <peter@engcorp.com> wrote:
[color=blue]
>engsol wrote:[color=green]
>> 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.[/color]
>
>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[/color]

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
Guest
 
Posts: n/a
#4: Jul 18 '05

re: pyserial and com port interrupts


On Wed, 12 Jan 2005 14:24:48 -0800, engsol <engsolnorm@peak.org> wrote:
[color=blue]
>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.[/color]

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
Guest
 
Posts: n/a
#5: Jul 18 '05

re: pyserial and com port interrupts


On Thu, 13 Jan 2005 03:11:23 GMT, Bengt Richter <bokr@oz.net> wrote:[color=blue]
> On Wed, 12 Jan 2005 14:24:48 -0800, engsol <engsolnorm@peak.org> wrote:
>[color=green]
> >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.[/color]
>
> 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.[/color]

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
Guest
 
Posts: n/a
#6: Jul 18 '05

re: pyserial and com port interrupts


On 2005-01-13, engsol <engsolnorm@peak.org> wrote:
[color=blue]
> 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.[/color]

Using threads in Python is really, really painless.

--
Grant Edwards grante Yow! Someone is DROOLING
at on my collar!!
visi.com
Neil Benn
Guest
 
Posts: n/a
#7: Jul 18 '05

re: pyserial and com port interrupts


engsol wrote:
[color=blue]
>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
>
>[/color]
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 : benn@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

Neil Benn
Guest
 
Posts: n/a
#8: Jul 18 '05

re: pyserial and com port interrupts


Neil Benn wrote:
[color=blue]
> engsol wrote:
>[color=green]
>> 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
>>
>>[/color]
> 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 :[/color]

<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 : benn@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

Peter Hansen
Guest
 
Posts: n/a
#9: Jul 18 '05

re: pyserial and com port interrupts


engsol wrote:[color=blue]
> 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.[/color]

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
Closed Thread


Similar Python bytes