Disabling buffering of serial port?

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

I wrote a simple program to change settings on a matrix switch. If I just put single commands in it works but multiple commands don't. I am pretty sure the issue is lack of buffering in the matrix switch. There are no handshake lines. The switch echos the characters so I could check for each characters reply before sending - probably a better solution but delays seemed simpler and workable. (Now that I think about it seeing what is returned would be useful for debugging...) I have found some things on $| for I/O but none that are for the serial port so I don't know exactly how the code for that would be. I am a perl noob so mostly just following examples. Here is the code:

#!/usr/bin/perl -w

# Controls HalfY matrix switch
# Switches both levels (audio and video)

use strict;

use Device::SerialPort; 

my $port = Device::SerialPort->new("/dev/ttyS0");

$port->baudrate(9600);
$port->parity("none");
$port->handshake("none");
$port->databits(8);
$port->stopbits(1);
$port->read_char_time(0);
$port->read_const_time(1);

# send data out
$port->write("CL1I1O1T");
print "TV input now from mythTV\n";
$port->write("CL2I1O1T");
[download]

Comment on Disabling buffering of serial port? Download Code

Replies are listed 'Best First'.
Re: Disabling buffering of serial port? by roboticus (Chancellor) on Oct 28, 2011 at 13:47 UTC
JimLS: Try adding a `sleep 1;` statement between the commands. Frequently embedded systems don't have buffers on the serial lines. (In fact, many microcontrollers don't have UARTs in them, and simulate the UART in software.) In many cases like this, the command software simply waits for a command, and once it gets one, it runs off and performs it. When the command is complete, it starts waiting for the next command. So when you send it a command, there'll be a delay before it will start looking for the next command, and anything sent before this will just "fall on the floor". You're sending 8 bytes, which takes roughly 8(8+2)/9600 seconds (8.3ms) to send to the controller. Since the serial port in your computer probably is* buffered, you're probably queueing up the second command before the first one has been fully transmitted! (Unless, of course, you're using a computer with no outbound serial buffer, or a horrendously low clock speed.) ...roboticus When your only tool is a hammer, all problems look like your thumb.	[reply] [d/l]

Replies are listed 'Best First'.

Re: Disabling buffering of serial port?
by roboticus (Chancellor) on Oct 28, 2011 at 13:47 UTC

JimLS:

Try adding a sleep 1; statement between the commands.

Frequently embedded systems don't have buffers on the serial lines. (In fact, many microcontrollers don't have UARTs in them, and simulate the UART in software.) In many cases like this, the command software simply waits for a command, and once it gets one, it runs off and performs it. When the command is complete, it starts waiting for the next command. So when you send it a command, there'll be a delay before it will start looking for the next command, and anything sent before this will just "fall on the floor".

You're sending 8 bytes, which takes roughly 8*(8+2)/9600 seconds (8.3ms) to send to the controller. Since the serial port in your computer probably *is* buffered, you're probably queueing up the second command before the first one has been fully transmitted! (Unless, of course, you're using a computer with no outbound serial buffer, or a horrendously low clock speed.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[reply]
[d/l]