The *NIX equivalent of this module is Device::SerialPort which makes use of the termios library and is exceptionally good for serial communications.

perl -e 's&&rob@cowsnet.com.au&&&split/[@.]/&&s&.com.&_&&&print'

I decided to try out this module. The following is pretty much the code from the examples

use strict;
use Win32::SerialPort qw( :STAT 0.19 );

my $PortName = 'COM1';
my $ob = new Win32::SerialPort($PortName) || die "Can't open $PortName
+: $^E\n";
Win32::SerialPort->set_test_mode_active(1);

$ob->handshake("none");
$ob->baudrate(57600);   #may need to be 56000
$ob->parity("none");
$ob->databits(8);
$ob->stopbits(1);
$ob->binary(1);
$ob->parity_enable(0);

$ob->read_const_time(5000);
$ob->read_interval(0);
$ob->write_const_time(3000);

$ob->debug(1);
$ob->error_msg(1);    # prints hardware messages like "Framing Error"
$ob->user_msg(1);     # prints function messages like "Waiting for CTS
+"
$ob->buffers(16,16);  # read, write

$ob->write_settings || die "Cannot write settings";
$ob->status;

print "Starting 1 character background read\n";
my $in = $ob->read_bg(1);
my $done = 0;
my $blk;
my $err;
my $out;
my $result;

for (;;) {
    ($done, $in, $result) = $ob->read_done(0);
    $ob->status;
    sleep(1); 
    last if $done;
}

print "got = $in\nresult = ",ord($result),"\n";
undef $ob;
[download]

The output says I receive a character, but it's ascii value is 0 which is wrong. I know that my hardware works because I have tried talking to it with HyperTerm. Where is my flaw?

I've done a lot of work with Device::SerialPort, which is the unix implementation of Win32::SerialPort. I get just a single "0" value when I have something in my settings wrong. Usually it's a baud rate. (My hardware at the other end doesn't always honour it's DIP settings for the baud rate) The other condition that I've had generate that was an error in flow control settings.

Maybe try a test at 2400 or something.

In any case, do please x 1000 use Win32::SerialPort, because it is what is normally used, it works _very_ well, and people expect to see it. Also, it's interface is portable to other platforms. (for example, the native platform of Perl...)
--
Snazzy tagline here

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.

--Chris