Have you looked at Win32API::CommPort? It provides the low level/raw access that Win32::SerialPort is built-upon. It's included with Wn32::SerialPort, so you should already have it.
| [reply] |
I doubt that this level of control (includes fiddling with control signals like RTS (Request to Send), CLS (Clear to Send), etc is needed. I think all that is needed here is binary data send/receive (not low level access to the flow control signals).
A modern computer can keep up easily with the port, even at "high" baud rate settings.
Also many of the computers nowadays have very limited RS-232 support and all of the flow control signals may not be even available! xon/xoff flow control is the way to go (if possible and needed) - however even no flow control at all is often fine!
The serial port chip or emulator will have at least 16 bytes of buffer. If this is a simple request/response protocol (no asynchronous messages being used), the programming should be fairly straight-forward.
RS-232 serial port communication is going the way of the dodo bird although it will "live" and be useful for a very long time.
| [reply] |
That's a good point. Maybe he can replace the part of Win32::SerialPort that is trying to help him too much without having to dive into Win32API::CommPort.
I don't see serial ports going away anytime soon either given that most (all?) network devices have a serial console interface. Ditto for lights out (HP's Jargon) type cards that manage servers like iLOs, DRAC, RSC, etc. I suspect they will be around much, much longer than expected in some form or another.
Update: FWIW, I was just forecasting for some Lantronix devices to provide serial console access to our ACS appliances.
| [reply] |