«

I didn't fully think through my application before posting my
question. Async com port routines to handle com port interrups
only work well if one has access to the low level operating
system. In that case the receive buffer interrupt would cause
a jump to an interrupt service routine.. I don't believe that
Python provides that capabilty directly. The solution then would
be to write a C extention?

The suggestions offered by respondents to my original post
were almost all of a "Use threads, and poll as needed" flavor.
You're right...I need to learn threads as applied to com ports.
Norm B

A search on google gave me this library, I haven't tested it though:
http://groups-beta.google.com/group/...1074d7bd94be63

Thanks much..

On 14 Jan 2005 12:25:43 -0800, "" <> wrote:

>A search on google gave me this library, I haven't tested it though:
>http://groups-beta.google.com/group/...1074d7bd94be63

engsol wrote:
> I didn't fully think through my application before posting my
> question. Async com port routines to handle com port interrups
> only work well if one has access to the low level operating
> system. In that case the receive buffer interrupt would cause
> a jump to an interrupt service routine.. I don't believe that
> Python provides that capabilty directly. The solution then would
> be to write a C extention?

Maybe, but I doubt that you can or would really want to do this
with modern operating systems anyway. With DOS, and similar
primitive things, glomming onto an interrupt or hooking yourself
into the interrupt table was pretty easy. I don't think either
Windows or Linux is structured such that you just "write a
C extension" to intercept interrupts. Instead, you must write
relatively complicated drivers which have to be loaded at
system startup (more or less) and be tied into the kernel at
a relatively low level. Think "rocket science", at least in
comparison to writing a simple C extension.

> The suggestions offered by respondents to my original post
> were almost all of a "Use threads, and poll as needed" flavor.
> You're right...I need to learn threads as applied to com ports.

At least on Windows, I'm fairly sure you can configure the
read timeouts so that you get behaviour on reads that for
all intents and purposes is about as good as an interrupt,
without the difficulties inherent in that approach, but
provided you are willing to dedicate a thread to the task.

On Linux, it's possible the read timeouts capabilities are
a little less flexible (but I've only just barely glanced
at this area), but as I recall you were on Windows anyway.

BTW, another post pointed you to USPP. As far as I know,
it hasn't been updated recently and, while I can't say how
it compares to PySerial, I believe it's fair to say at
this point in time that PySerial is the _de facto_ standard
way to do serial port stuff in Python. If it doesn't do
what you need, it's probably a good idea to at least point
that out in its mailing list so that it can be improved.

-Peter

engsol <> wrote in
news::

> I didn't fully think through my application before posting my
> question. Async com port routines to handle com port interrups
> only work well if one has access to the low level operating
> system. In that case the receive buffer interrupt would cause
> a jump to an interrupt service routine.. I don't believe that

i would not go that route... the operating system provides sync and async
methods to access the serial port. it would make sense to use these before
hacking the operating system. (also see below)

> Python provides that capabilty directly. The solution then would
> be to write a C extention?

ctypes can do many things without a C compiler. it's a very nice an
valuable extension, but i won't like to encurage to use it for this
particular problem.

> The suggestions offered by respondents to my original post
> were almost all of a "Use threads, and poll as needed" flavor.
> You're right...I need to learn threads as applied to com ports.

if you realy want to do async programming, have a look at twisted
(http://twistedmatrix.com). it does not only provide async access to the
serial port (trough pyserial + some code in twisted) it also delivers some
nice utility functions, classes etc, like the reactor, defereds, thread
pools (if you can't resist and many protocol handlers.

chris

--
Chris <>

On Fri, 14 Jan 2005 23:25:21 -0500, Peter Hansen <> wrote:

>engsol wrote:
>> I didn't fully think through my application before posting my
>> question. Async com port routines to handle com port interrups
>> only work well if one has access to the low level operating
>> system. In that case the receive buffer interrupt would cause
>> a jump to an interrupt service routine.. I don't believe that
>> Python provides that capabilty directly. The solution then would
>> be to write a C extention?
>
>Maybe, but I doubt that you can or would really want to do this
>with modern operating systems anyway. With DOS, and similar
>primitive things, glomming onto an interrupt or hooking yourself
>into the interrupt table was pretty easy. I don't think either
>Windows or Linux is structured such that you just "write a
>C extension" to intercept interrupts. Instead, you must write
>relatively complicated drivers which have to be loaded at
>system startup (more or less) and be tied into the kernel at
>a relatively low level. Think "rocket science", at least in
>comparison to writing a simple C extension.
>
>> The suggestions offered by respondents to my original post
>> were almost all of a "Use threads, and poll as needed" flavor.
>> You're right...I need to learn threads as applied to com ports.
>
>At least on Windows, I'm fairly sure you can configure the
>read timeouts so that you get behaviour on reads that for
>all intents and purposes is about as good as an interrupt,
>without the difficulties inherent in that approach, but
>provided you are willing to dedicate a thread to the task.
>
>On Linux, it's possible the read timeouts capabilities are
>a little less flexible (but I've only just barely glanced
>at this area), but as I recall you were on Windows anyway.
>
>BTW, another post pointed you to USPP. As far as I know,
>it hasn't been updated recently and, while I can't say how
>it compares to PySerial, I believe it's fair to say at
>this point in time that PySerial is the _de facto_ standard
>way to do serial port stuff in Python. If it doesn't do
>what you need, it's probably a good idea to at least point
>that out in its mailing list so that it can be improved.
>
>-Peter

Peter, thanks for the input...good advice. I took a look at USPP,
and as you observed, it seems to be a bit dated.

Actually, I've violated one of my basic rules: do it the simple way
first, then determine what needs to be expanded, improved, speeded up,
etc.
Norm B

On Sat, 15 Jan 2005 19:38:19 +0000 (UTC), Chris Liechti <> wrote:

>engsol <> wrote in
>news: :
>
>> I didn't fully think through my application before posting my
>> question. Async com port routines to handle com port interrups
>> only work well if one has access to the low level operating
>> system. In that case the receive buffer interrupt would cause
>> a jump to an interrupt service routine.. I don't believe that
>
>i would not go that route... the operating system provides sync and async
>methods to access the serial port. it would make sense to use these before
>hacking the operating system. (also see below)
>
>> Python provides that capabilty directly. The solution then would
>> be to write a C extention?
>
>ctypes can do many things without a C compiler. it's a very nice an
>valuable extension, but i won't like to encurage to use it for this
>particular problem.
>
>> The suggestions offered by respondents to my original post
>> were almost all of a "Use threads, and poll as needed" flavor.
>> You're right...I need to learn threads as applied to com ports.
>
>if you realy want to do async programming, have a look at twisted
>(http://twistedmatrix.com). it does not only provide async access to the
>serial port (trough pyserial + some code in twisted) it also delivers some
>nice utility functions, classes etc, like the reactor, defereds, thread
>pools (if you can't resist and many protocol handlers.
>
>chris

Chris, thanks for the pointer to twisted. I'm a bit snow bound, so it's a
good time to actually read some docs...
Norm B