Matt Sickler wrote:
isnt serial comms done with readwrite on /dev/serialdevice or something? although that is a good idea to write a Driver for serial comms.
Not exactly. A serial device is actually a little bit of hardware (the serial port, if you will) that you have to tell how to function. You set things like baud rate, parity, and other options (there are dozens) before you begin communicating. Once both serial devices (the serial port in your machine, and the device you're connecting to) have the same options set (for the most part) they may only then begin communicating.
The actual communication is usually done using a file descriptor, at least in POSIX, but that's not really what's happening. Data written to the file descriptor is sent to a buffer in the serial port hardware. The hardware then transmits the contents of the buffer across the line. Data received by the serial port generally triggers an interrupt, which the operating system recognizes and copies the data from the serial port buffer to the file descriptor.
At least that's how I remember it. I'm by no means an expert on the subject. In general however, I would use Device::SerialPort as that is what I have used successfully in the past. And it's cross platform.
Your biggest problem in creating a POE component for serial communication will be the configuration of the serial device and how to handle errors related to that device. I think baud rate, parity, stop bits, and data bits are going to be the configuration parameters you'll need to provide access to, at a minimum. You'll also want some way to re-establish a connection that fails, for some reason, as well as provide a way for the user to take actions on various errors. You might also run into some blocking issues, since I'm not sure how buffer over runs are handled by the Device::SerialPort. Sending too much data across the wire could very well cause the serial port to block, which kinda defeats the purpose, especially in POE.
Good luck, Rob
