I have breakout box, but handshaking is controlled by devc-ser8250 on both
ends (I have written a loop-back simulator that I run on a separate QNX
box). I was unaware that devc-ser8250 can be invoked in such a way that
hardware flow control is disabled? I don’t think this is possible. However,
I can tell you that hardware flow control works perfectly up to the point
the system hangs . I have actually had QNX crash at this point, although not
consistently - i.e. I cannot start new applications (/bin/sh not found),
only shutdown existing ones and I cannot invoke shutdown to reboot the
system - I am forced to hard boot.
I use the following code to initialize the serial ports (I removed error
checking at every step to reduce the size of this post - I do check for
errors wherever possible):
int status;
struct termios device_attr;
sysl_log_function_start(my_function_name);
/* Open serial port for reading and writing */
*p_fd_device = open(p_port, O_RDWR);
/** flush output buffer **/
status = tcflush (*p_fd_device, TCOFLUSH);
/* Get current attributes for this port */
status = tcgetattr(*p_fd_device, &device_attr);
/* readcond is used in spro - intercharacter timeouts are not needed (see
readcond) /
device_attr.c_cc[VMIN] = 0; / expect minimum of 0 characters /
if (timeout > 255)
{
device_attr.c_cc[VTIME] = 255;
}
else
{
device_attr.c_cc[VTIME] = (unsigned char) timeout; / inter-character
timeout [seconds * 10] */
}
/* Set raw mode for this port */
status = cfmakeraw (&device_attr);
/** set input speed **/
status = cfsetispeed(&device_attr, (speed_t) B57600);
/** set output speed **/
status = cfsetospeed(&device_attr, (speed_t) B57600);
/** update port **/
status = tcsetattr(*p_fd_device, TCSAFLUSH, &device_attr);
Once opened, I use readcond() to a byte at a time from the serial port (I am
using a transparent protocol with an escape character to distinguish data
from command bytes). The code for this is simply:
status = readcond(fd_device, &ucChar, 1, 0, uiTimeout, 0);
uiTimeout is my protocol intercharacter or packet timeout (depending on
whether I’m waiting for the first character in a packet or the next
character).
I can’t see why the above should cause any problems.
just for completeness, devc-ser8250 is invoked from my /etc/rc.d/rc.local as
follows:
slay devc-ser820560
sleep 1
devc-blueheatw -I 10 -O 10 -u1 3f8,4 -u2 2f8,3 -u3 -zd /bin/devc-ser8250
this yields (checked using “ps”):
/sbin/devc-ser8250 -I 10 -O 10 -u1 3f8,4 -u2 2f8,3 -u3 -t8 -c22118400/16
d400,11 d408,11 d410,11 d418,11 d420,11 d428,11 d430,11 d438,11
Yes, I have 10 serial ports, 8 of which are on a ConnectTech BlueHeat 8 port
ISA serial card. But I get the same results if I invoke devc-ser8250
directly only for ports 1 (3f8,4) and 2 (2f8,3) and restrict myself to using
only /dev/ser1 on each QNX box.
Anyone got any ideas?
Randy Aeberhardt
<raeberhardt@tantalus-systems.com>
<www.tantalus-systems.com>
“Tom Evans” <tom@nospam.invalid> wrote in message
news:3C0F062E.41@nospam.invalid…
Randy Aeberhardt wrote:
I don’t have a solution, but I do have the same problem.
Always suspect Flow Control.
Put a serial breakout box on the serial port (or an
oscilloscope) and look at the DTS and CTS lines.
Does your hardware support flow control? Which one
(hardware RTS/CTS or software XON/XOFF). Is this enabled
in the serial driver?
And where’s the source of and documentation for the “tti()”
and “ttc()” functions that seem to do a lot of the serial
driver work?
Good luck.
Tom Evans
InitialSurnameAt
tennyson.com.au