Re: Flow Control on Serial Device

Floyd,

I re-engineered my cable and connected line 7 (RTS) also.
So the cable now looks like that:
2,3,5,7 and 8 are straight-thru. On the PC-side 6 and 4 are connected (did
not make any difference).
The sniffer ends are connected to 2 and 3 respectively and to 5.
Then I repeated all the tests and noted down the measurements as follows:

W WA WT LS0 LUSB

2 -7,1 -7,1 -7,2 -6,4 -7,2
3 0 -5,3 -5,3 0 -6,9
7 0 -5,3 +5,9 0 -7,3
8 -7,1 -7,1 -7,1 -6,7 -7,2

That means:
W Windows only (no application started)
WA Windows application program (provided with the device)
WT Windows perminal program
LS0 Linux ttyS0
LUSB Linux ttyUSB0

In all cases the same cable and hardware was used with the following
exception:
in Linux ttyS0 did not work at all (the sniffer program did not even see the
initial character string sent)
and I have to use an usb-serial adapter, while the Windows application
program runs on com1 only.
In Windows only the application program provided with the device works.
Interesting is that when I use the Windows terminal program to send the
initial character string line 7 shows +5,9 V,
but there is no response from the device either.
In Linux I made the same test with my application program and serlook.
In both cases the sniffer program sees the initial character string but no
response.
These are the relevant parts of my program:

fd = open(tty, O_RDWR | O_NOCTTY | O_NDELAY);

tcgetattr(fd,&oldtio);
bzero(&newtio, sizeof(newtio));
newtio.c_cflag = CLOCAL | CREAD | CS8;
newtio.c_iflag = 0;
newtio.c_cc[VMIN]=0;
newtio.c_cc[VTIME]=0;
cfsetospeed(&newtio, BAUDRATE);
cfsetispeed(&newtio, BAUDRATE);
tcflush(fd, TCIOFLUSH);
tcsetattr(fd,TCSANOW,&newtio);
fcntl(fd, F_SETOWN, getpid());

ioctl(fd,TIOCMGET,&status);
status |= TIOCM_RTS;
ioctl(fd,TIOCMSET,&status);
write(fd,"UUUUU\xFF\xFF\x01\x5b\x8f\x00\x5A\x07\x01\x33\x00\x00\x95",18);

I hope this all is readable to you.
Thank you very much for your effort.

Paul


"Floyd L. Davidson" <floyd@xxxxxxxxxx> schrieb im Newsbeitrag
news:87lkgmexc3.fld@xxxxxxxxxxxxx
"Paul Pridt" <p.pridt@xxxxxxxxx> wrote:
I use exactly the same cable as with the windows program. It is a
straight-thru cable. I had cut it and reconnected with 2 sniffer ends and
used linux/logserial to log all data. As I can see exactly the same data
as it is shown in Windows, speed, parity etc seem to be ok.
Btw I did started as sniffer with a windows machine and got the same
result.
A db-9 cable is being used. I can disconnect all lines but 2,3,5,8 and it
works in Windows as before.

Okay. First, I was thinking in 25 pin connector terms, and you
are using 9 pin connectors. My fault.

DB25 DB9
PIN PIN FUNCTION NAME
1 Frame Ground FG
2 3 Transmit Data TxD
3 2 Receive Data RxD
4 7 Request to Send RTS
5 8 Clear to Send CTS
6 6 Data Set Ready DSR
7 5 Signal Ground SG
8 1 Carrier Detect DCD

20 4 Data Terminal Ready DTR
22 9 Ring Indicator RI

Hence, with that, your pin statements do make more sense, though
there is still the problem with showing 0 volts. It is possible
that your device is trying to use -5v for mark and 0 volts for
space... which often enough works even if it is an abomination.

With that configuration, connecting only 4 lines, you can't
really do hardware flow control in the way the device driver
will assume if it is used.

It appears as if the RTS/CTS line is sourced at the device
(RTS), and your program would sense (the CTS) that line to
determine the state of the device. I guess one would assume
that data should only be sent if it is asserted. Or at least
that is a good starting point, and something you can verify
relatively easy.

There is code for sensing CTS in the RS-232 examples that I
cited in the previous article, which you can use as a mind
refresher if needed. It would appear that you have done that
sort of thing previously, so it will all make sense quickly.

Obviously the device is wired as DCE.
I also tried to set RTS on and off via ioctl, no result.

If what I suspect above is true, there would be no effect from
changing RTS states.

When I set hardware flow on, nothing happens, the program appearently
waits
for response that never comes.

And that would also happen.

Somebody asked about my knowledge level in serial programming: once I
wrote
a serial device monitor for a specific device in C, so I do have some,
problably not very deep knowledge.

That is definitely a good start. I was assuming just about
that. Otherwise you would not have been playing with ioctl
calls! (And of course if you had lots of experience, you
wouldn't have even bothered with that.)

This device now does provide some measurement values over a rs232
interface.
Again, I want to use C.

Here's where we're at, I think:

Welllll... Post your code for opening and configuring the
serial port. Try to cut it down to the simplest, shortest
program that you can. Maybe even just snippets with code
to open and configure a port; though if you can do it nicely the
best would be a short program that compiles and shoud send
one command and receive a response from the device.

I think we might be back to this. A lot of what you are
probably doing depends on what examples you used to develop your
code, and much of what is available on the net comes from the
LINUX Howto, which means much of it is riddled with errors.

I can go through your code and determine if it actually is doing
what you want it to, and probably point out any weird
possibilities that would cause strange results.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@xxxxxxxxxx


.

Relevant Pages

  • Re: Flow Control on Serial Device
    ... Btw I did started as sniffer with a windows machine and got the same result. ... First, I was thinking in 25 pin connector terms, and you ... I also tried to set RTS on and off via ioctl, ...
    (comp.os.linux.networking)
  • Re: Flow Control on Serial Device
    ... the sniffer pc sees the initial character string, ... the sniffer see any answer from the device. ... Also, when I use a terminal program in Windows, I have the same problem. ... can communicate to the device it must also be possible to do that in Linux. ...
    (comp.os.linux.networking)
  • Re: Event Viewer - Pop3 Connector Delivery
    ... scanning the pop connector work folders ... C:\Program Files\Microsoft Windows Small Business ... > I look in the event viewer and see some error messages for pop3 connector ...
    (microsoft.public.windows.server.sbs)
  • Re: Vista Mail & HTTP
    ... I am using Outlook without Connector, just with WebDAV. ... where on my XP system it makes Outlook ignore that Windows is shutting down. ... MSFT keeps those accounts around. ...
    (microsoft.public.windows.vista.mail)
  • Re: Strange "Drive Not Ready" message
    ... Reseat the power supply connector going to the drive. ... If the problem persists, swap out the floppy drive with a known-working ... MS-MVP Windows - Shell/User ...
    (microsoft.public.windowsxp.general)