in reply to Win32 Serial Communication

I've used this module of a number of projects myself. However, I've always use the 'input' and 'write' methods, typically with select() for timeouts.

For some code I have written to drive a maniufacturing test platform, I decided to use the tied methods. What a disaster! I resorted to writing my own line buffering routines, and using the 'input' and 'write' methods that had served me so well in the past.

Admittedly, the documentation (which is very strong in some areas, and more than very weak in others) seems to indicate that the tied methods use some code that is less than heavily tested. But still, I'm not sure how the tied methods escaped from the lab, because even for a basic send/expect type protocol, I was having major problems. Which is a shame, because that would be very handy.

The worst is that something like @a = <SERIALPORT> will return empty, even with stty_icanon(1). I think this area needs a lot of help yet. Luckily, it's easy to write your own buffering routines that only return whole complete lines. I'd really like to see it behave more like a real file, and be able to use select() directly on the handle. As near as I could tell from the observed behavior (and not digging into the code because of time constraints), it doesn't actually give access to the file handles of the port object. Hence, select() can't be applied to it.


e-mail jcwren