Home/Support/Support Forum/Software flow control not working
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Software flow control not working

0 votes
Hi!

I have an AccelePort 8r PCI (PLX) and a DEC VT420 as well as a Wyse WY-160ES terminal connected to it (Debian 3.0 "Woody" on a x86 PC). My problem is that the ^S flow control character is being delivered to the program running in the foreground instead of being intercepted by the terminal line discipline. Accordingly the host keeps sending data to the terminal which results in garbage on the screen and also the application executing whatever it is supposed to do on receipt of a ^S.

I tried both driver versions (epca v1.56 and dgap v1.1) which make no difference. Of course Xon/Xoff flow control is enabled:

<root@ddm ~>stty -a </dev>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = <undef>; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Thanks for any help!

Regards
Matthias
asked Jul 13, 2004 in Serial Cards by anonymous

Please log in or register to answer this question.

6 Answers

0 votes
What happens if the progam in the foreground is not running?

If you cat a large file to the terminal port and press <Ctrl> S and <Ctrl> Q to simulate software flow control, does the data stop and start?

# cat /etc/termcap > /dev/ttyx##

Additionally, I do recommend using the dgap version of the driver, as the epca driver will soon be obsolete.
answered Jul 13, 2004 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
Interesting. Typing ^S and ^Q while "ls -l /dev" is running (dont have /etc/termcap) works, i.e. they stop and restart the flow as one would expect. Does this tell you something?

Regards
Matthias
answered Jul 13, 2004 by lal New to the Community (3 points)
0 votes
Ctrl-S and Ctrl-Q are the characters which correspond to Xon and Xoff, i.e. software flow control. It sounds like Xon/Xoff flow control is working properly, since you can do it manually.
answered Jul 13, 2004 by michaelt Veteran of the Digi Community (769 points)
0 votes
> Ctrl-S and Ctrl-Q are the characters which correspond
> to Xon and Xoff, i.e. software flow control. It
> sounds like Xon/Xoff flow control is working
> properly, since you can do it manually.

Mmmh, I'd rather say it's working *almost* properly. For pure printable characters (e.g. directory listings, cat'ing text files) it seems to work. But with curses-based apps it does not. Maybe it has something to do with their heavy usage of escape sequences?

Just to be clear, I'm quite sure that it's definitely the ^S not being recognized by the terminal line discipline and not some other weird misconfiguration on my side (info browser starting "I-Search" which is bound to ^S, vi displaying "^S isn't a vi command" etc.). Hardware handshaking works perfectly even at 38400 bps, BTW.

Regards
Matthias
answered Jul 13, 2004 by lal New to the Community (3 points)
0 votes
When Xon/Xoff is configured with the epca/dgap drivers, the software flow control is done in the FEP (firmware).
Even if the FEP missed it, (very unlikely), the Linux line discipline would have caught it.

This suggests that your application is turning off xon/xoff, or is changing the characters that trigger xon/xoff.

When your application is running, and ctrl-s is sent to stop output, perform a ditty -a ttyx##, to see if xon and xoff are activated, along with the start/stop characters (i.e.: start = ^Q and stop = ^S).
answered Jul 14, 2004 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
> When Xon/Xoff is configured with the epca/dgap
> drivers, the software flow control is done in the FEP
> (firmware).
> Even if the FEP missed it, (very unlikely), the Linux
> line discipline would have caught it.

Never mind. It has nothing to do with the AccelePort. After some more extensive testing and experimenting I finally got the unbelievably genious idea to test it with the onboard serial port of the computer. And guess what - the symptoms are exactly the same.

> This suggests that your application is turning off
> xon/xoff, or is changing the characters that trigger
> xon/xoff.
>
> When your application is running, and ctrl-s is sent
> to stop output, perform a ditty -a ttyx##, to see if
> xon and xoff are activated, along with the start/stop
> characters (i.e.: start = ^Q and stop = ^S).

Er, yes. All the curses-based programs disable flow control (-ixon)! So I guess it's the curses library fault. I will investigate this issue further.

Thank you very very much! You are of great help!

Regards
Matthias
answered Jul 18, 2004 by lal New to the Community (3 points)
...