Serial port losing data

dshahin has asked for the wisdom of the Perl Monks concerning the following question:

I'm having a very frustrating problem talking to an serial-based cash register pole display. I'm working on a browser-based cash register that talks to a Perl daemon that sits on the localhost port 8080 and awaits messages that the browser sends by opening and closing a window with a localhost:8080 address and the text to display is encoded in the url in a RESTful manner.

The messages are getting to the daemon, but they don't consistently get to the LCD display. One time the message gets there, then next it might not. Sometimes half of $arg2 will display, sometimes none, sometimes all. Frustration!

I'm using : $SIG{'PIPE'} = 'IGNORE'; to keep the daemon from mysteriously failing, but I'm thinking that the problem is in HTTP::Daemon. Should I just break down and use apache on the localhost or perhaps Net::Daemon will work better?

Rather than hack away at possibilities I thought I'd post here and see if any fellow Monks have any experience with such matters.

Any insights would be appreciated.

Here's the HTTP::Daemon I'm using:

#!/usr/bin/perl
use HTTP::Daemon;
use HTTP::Status;
my $d = HTTP::Daemon->new(LocalPort => 8080) || die;
print "Please contact me at: <URL:", $d->url, ">\n";
$SIG{'PIPE'} = 'IGNORE';
while (my $c = $d->accept) {
     while (my $r = $c->get_request) {
         if ($r->method eq 'GET' and $r->url->path =~  /display/) {
             my @args;
             my ($foo,$command,$arg1,$arg2) = split /\//, $r->url->pat
+h;
             $arg1 =~ s/%20/ /g;
             $arg2 =~ s/%20/ /g;
             $arg1 = substr($arg1,0,20);
             print "command: $command arg1: $arg1 arg2:$arg2\n";
             open SERIAL, ">>/dev/ttyS0" || die "Can't open serial";
             select((select(SERIAL), $| = 1)[0]);
             print SERIAL  "\x04\x01\x43\x31\x58\x17$arg1\x04\x01\x50\
+x44\x17 \$$arg2";
             #print   SERIAL "$$arg2 ";
             my $code = "200";
             my $mess = "Cache-Control: no-cache";
             $c->send_basic_header( $code, $mess );
             close SERIAL;
             next;
         }elsif($r->method eq 'GET' and $r->url->path =~  /scroll/) {
                print SERIAL "\x04\x01\x44\x31\x33\x17";#DISPLAY DEMO
         }else {
             $c->send_error(RC_FORBIDDEN)
         }
     }
     $c->close;
     undef($c);
}
[download]

Comment on Serial port losing data Download Code

Replies are listed 'Best First'.
Re: Serial port losing data by roboticus (Chancellor) on Jul 14, 2007 at 04:09 UTC
dshahin: I've done tons of hardware interfacing. While it's a great idea to check your code, you may be trying to feed data to the cash register faster than it's able to consume it. Here are a couple of things you might try: 1) Check the manual for the cash register and make sure that your cable is correct. Many serial devices use hardware handshaking signals to regulate the data flow to a rate they can handle. If it uses hardware handshaking and you're using a serial cable wired to fool itself, you'll get the symptoms you describe. I've seen this happen in lots of microcontroller-based hardware for example: many don't have a UART in them and they emulate the UART by bit-banging. When the microcontroller is busy doing something else (such as ejecting cash drawer, talking with LCD display, or some such) it can't be monitoring the serial channel. So they may use the CTS or DTR line to put a hold on incoming data. 2) Another thing I've encountered is that some devices don't use hardware handshaking, but they're not quite fast enough to handle a serial port going full-bore. You might try small delays after carriage returns to give the controller a chance to process the line before sending the next line. One final note: Delays should be your last resort. Too often, people put them in, and it works most of the time. Then you add more delays, and it's a bag of rats. If the device uses hardware handshaking, you'll save yourself some grief by cabling it correctly rather than using arbitrary delays. ...roboticus	[reply]
Re: Serial port losing data by GrandFather (Saint) on Jul 13, 2007 at 23:47 UTC
Is it possible (as your title indicates) that it is the serial communication that is failing? Easy test is to write a quick script that fires commands to the display and see if that is reliable. If not, I'd look at handshake between the script and the display. It may be that there is software handshake that is being ignored, or even hardware handshake that is resulting in buffer overruns and character loss. DWIM is Perl's answer to Gödel	[reply]
Re^2: Serial port losing data by dshahin (Pilgrim) on Jul 14, 2007 at 23:22 UTC
I've done that. My non daemon scripts that write to the serial never lose any data. That's what makes me think it's a problem with HTTP::Daemon, especially given it's sometimes flaky behavior.	[reply]
Re: Serial port losing data by TOD (Friar) on Jul 13, 2007 at 23:30 UTC
i think the problem is here: `select((select(SERIAL), $\| = 1)[0]);`, and it results from the usage of `$\|`. i suppose you localize it. -------------------------------- masses are the opiate for religion.	[reply] [d/l] [select]