Hi,

Can somebody tell me if Slackware 10.0 or the pc's hardware is
responsible for /dev/tty flowcontrol? I need to disable it, but
'options.c_cflag &= ~CNEW_RTSCTS;' in C gives me the error CNEW_RTSCTS
doesn't exist.
My hardware: Asus K8N systemboard, AMD Sempron 3000+.

Thank you,

Huub

Huub <hdotvdotniekerkathccnetdotnl> wrote:
> Can somebody tell me if Slackware 10.0 or the pc's hardware is
> responsible for /dev/tty flowcontrol? I need to disable it, but
> 'options.c_cflag &= ~CNEW_RTSCTS;' in C gives me the error CNEW_RTSCTS
> doesn't exist.

Essentially the kernel is, the "serial port" driver.
Of course the wiring TO the terminal (and it HAS to be a serial terminal,
graphic screen doesn't have CTS/RTS as those are serial port pins) does
have to include the RTS/CTS (Request To Send cq Clear To Send) wires.

> My hardware: Asus K8N systemboard, AMD Sempron 3000+.

So this flowcontrol essentially only works to /dev/ttyS*, the serial I/O
port special files.

Flow control to the console (system keyboard/monitor) is done in software,
through the Xoff/Xon (ctrl-S/ctrl-Q) protocol, although most current
hardware doesn't need it at all.

And note that /dev/tty (without anything AFTER it) is a pseudo device, not
a physical device at all, it is "the current terminal, cq window", so is
routed in software to whatever terminal or window you're currently in.
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

> Essentially the kernel is, the "serial port" driver.
> Of course the wiring TO the terminal (and it HAS to be a serial terminal,
> graphic screen doesn't have CTS/RTS as those are serial port pins) does
> have to include the RTS/CTS (Request To Send cq Clear To Send) wires.
>
>
>>My hardware: Asus K8N systemboard, AMD Sempron 3000+.
>
>
> So this flowcontrol essentially only works to /dev/ttyS*, the serial I/O
> port special files.
>
> Flow control to the console (system keyboard/monitor) is done in software,
> through the Xoff/Xon (ctrl-S/ctrl-Q) protocol, although most current
> hardware doesn't need it at all.
>
> And note that /dev/tty (without anything AFTER it) is a pseudo device, not
> a physical device at all, it is "the current terminal, cq window", so is
> routed in software to whatever terminal or window you're currently in.
So what you're actually saying is that, if the compiler tells me 'no
such thing', I just can't disable it. Problem is that I have written
some C-code which writes a byte to /dev/ttyS0, using 19200, N81.
On Windows, using HyperTerminal and settings being the same with
flowcontrol off, the device (a robot) responds well.
On Slackware 10.0, fluxbox wm, and xterm, I can see that the device is
receiving the signal (blinking LEDs) but it doesn't act at all. This
makes me think of flowcontrol.

Thanks,

Huub

Huub <hdotvdotniekerkathccnetdotnl> wrote:
>So what you're actually saying is that, if the compiler tells me
>'no such thing', I just can't disable it. Problem is that I have
>written some C-code which writes a byte to /dev/ttyS0, using
>19200, N81.

Your original post asked about /dev/tty, which is entirely a
different story.

>On Windows, using HyperTerminal and settings being the same with
>flowcontrol off, the device (a robot) responds well.

We can assume to robot works then.

>On Slackware 10.0, fluxbox wm, and xterm, I can see that the
>device is receiving the signal (blinking LEDs) but it doesn't
>act at all. This makes me think of flowcontrol.

First, unless you are really unusual, and extremely perceptive,
my guess is that most of your serial port code is, ahem... less
than correct. (Don't take offense at that idea. It is
*common*, and the reason is because POSIX serial port
programming isn't something most programmers do every day, and
it is a maze of hard to relate to ideas.)

So. Post some code, and we'll get that straightened out first.

Post the code you use to initialize the serial port. Also post
the code you use to read and write to the port.

If it is possible, you might try working this down to something
as small as you can get and still actually have a compilable
program. If it just sends initialization code, or something
like that, to the robot and then reads enough response to verify
that the beast is alive, that would be good enough.

If that sounds like too much work, or if your coding style is
such that it takes 20k of text to do it, the other option is to
just post the individual functions. (You'll have to suffer with
the fact that my response will likely reformat your code in my
chosen style, and might even include a lecture on style!)

In the mean time, as a heads up (and maybe that is all you'll need),
here is the best description of POSIX serial port coding that is
available on the net:

http://www.easysw.com/~mike/serial/serial.html

Also, on my web site there are some examples of various ways to
program a serial port "terminal" program,

http://web.newsguy.com/floyd_davidson/code

Look under "Terminal Programs", though you might also be
interested in the "RS-232 Hardware" code too.

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@barrow.com

> We can assume to robot works then.
Yes.
> Post the code you use to initialize the serial port. Also post
> the code you use to read and write to the port.
This is the code I put together from a doc on serial programming on
Linux. The open_port() and write_to_port(int data) functions do work, as
far as I can tell. It's set_baudrate() that I suspect. I left out the
#includes.

struct termios options;

int x, data, n, fd;

set_baudrate()
{
tcgetattr(fd, &options);
cfsetispeed(&options, B19200);
cfsetospeed(&options, B19200);
tcsetattr(fd, TCSANOW, &options);
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
options.c_cflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
}

int open_port(void)
{
fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);
if (fd == -1)
{
perror("open_port: Unable to open /dev/ttyS0 - ");
}
else
fcntl(fd, F_SETFL, 0);
return (fd);
}

write_to_port(int data)
{
n = write(fd, "ATZ\r", data);
if (n < 0)
fputs("Write() of data failed!\n", stderr);
}

main()
{
set_baudrate();
open_port();
write_to_port(8);
}

>
> If it is possible, you might try working this down to something
> as small as you can get and still actually have a compilable
> program. If it just sends initialization code, or something
> like that, to the robot and then reads enough response to verify
> that the beast is alive, that would be good enough.
It should just pass a digit to the robot, which then rides a bit.

> http://www.easysw.com/~mike/serial/serial.html
>
> Also, on my web site there are some examples of various ways to
> program a serial port "terminal" program,
>
> http://web.newsguy.com/floyd_davidson/code
>
> Look under "Terminal Programs", though you might also be
> interested in the "RS-232 Hardware" code too.
>
Thank for the links and helping.

Huub

On 07/05/05 18:46, Huub wrote:

> struct termios options;
>
> int x, data, n, fd;
>
> set_baudrate()
> {
> tcgetattr(fd, &options);
> cfsetispeed(&options, B19200);
> cfsetospeed(&options, B19200);
> tcsetattr(fd, TCSANOW, &options); <=== ????
> options.c_cflag &= ~CSIZE;
> options.c_cflag |= CS8;
> options.c_cflag &= ~PARENB;
> options.c_cflag &= ~CSTOPB;
> options.c_cflag &= ~CSIZE;
> options.c_cflag |= CS8;
> }

Shuoldn't you move the "tcsetattr(fd, TCSANOW, &options);" statement
at the end of the function? It makes no sense to write options to the
device and then modify it.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
Registered Linux user #337974 <http://counter.li.org/>

> Shuoldn't you move the "tcsetattr(fd, TCSANOW, &options);" statement
> at the end of the function? It makes no sense to write options to the
> device and then modify it.
Makes sense, but it shows no effect on the device..alas.

On 2005-07-05, Huub <hdotvdotniekerkathccnetdotnl> wrote:
> So what you're actually saying is that, if the compiler tells me 'no
> such thing', I just can't disable it. Problem is that I have written
> some C-code which writes a byte to /dev/ttyS0, using 19200, N81.
> On Windows, using HyperTerminal and settings being the same with
> flowcontrol off, the device (a robot) responds well.

The reason the compiler is telling you "no such thing" is that the
macro CNEW_RTSCTS isn't defined in whatever include files you're
including. You might want to read the Serial Programming HOWTO. If
you've installed the "f" disk sets in your Slackware installation
it will be in /usr/doc/Linux-HOWTOs. Otherwise, look for
http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ on the World
Wide Web. It explains quite a lot about programming a serial port
in linux. The serial port is one of those things that are different
from operating system to operating system.

--
e-Harmony.com called the cops after I sent in my personality profile.

On Tue, 05 Jul 2005 21:29:32 +0200, Huub wrote:

>> [quoted text muted]
> Makes sense, but it shows no effect on the device..alas.

Have you tried opening minicom (the linux hyperterminal) and tried talking
to your robot? Anything you type in the minicom page should be passed
stright on through the serial port. (and let you experiment with turning
flow control on and off from a menu system)

for starters

Christopher A. Shamis wrote:
> On Tue, 05 Jul 2005 21:29:32 +0200, Huub wrote:
>
>
>>>[quoted text muted]
>>
>>Makes sense, but it shows no effect on the device..alas.
>
>
> Have you tried opening minicom (the linux hyperterminal) and tried talking
> to your robot? Anything you type in the minicom page should be passed
> stright on through the serial port. (and let you experiment with turning
> flow control on and off from a menu system)
>
> for starters
>
>
Good idea, but since I don't have /dev/modem, what properties should I
give with "mknod /dev/modem"?

Thanks,

Huub