Re: Flow Control on Serial Device
- From: "Paul Pridt" <p.pridt@xxxxxxxxx>
- Date: Fri, 20 Apr 2007 19:31:13 +0200
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.
Obviously the device is wired as DCE.
I also tried to set RTS on and off via ioctl, no result.
When I set hardware flow on, nothing happens, the program appearently waits
for response that never comes.
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.
This device now does provide some measurement values over a rs232 interface.
Again, I want to use C.
Paul
"Floyd L. Davidson" <floyd@xxxxxxxxxx> schrieb im Newsbeitrag
news:87slavdrhk.fld@xxxxxxxxxxxxx
"Paul Pridt" <p.pridt@xxxxxxxxx> wrote:
I have a serial device that is connected to a pc via modem cable (db9f-
db9m straigth-thru).
There is a Windows program that reads from and writes to that device.
Are you using the exact same cable for the Linux system that you
do for the Windows system? Are you absolutely sure that is
indeed a straight through cable? If it is some type of Null
Modem, there could be a lot of confusion...
Now I want to replace Windows with Linux, so I have to write the
program for myself.
I have traced all data in both directions, but when I write the
initial string to the device, it does not answer.
I'm not sure what you mean by "trace all data in both directions"
means. If you have access to an RS-232 data analyzer, that is
going to be *very* useful. Tell me how you are tracing data!
I found that only 4 lines are being used: RxD (line 2), TxD (line 3),
SG (line 5) and CTS (line 8).
That does *not* match RS-232. In the chart below, the PC serial
port is a DTE (for Data Terminal Equipment) and the remote
serial device is a DCE (for Data Communications Equipment).
PIN DTE FUNCTION NAME DTE DIRECTION
1 Frame Ground FG
2 Transmit Data TxD output
3 Receive Data RxD input
4 Request to Send RTS output
5 Clear to Send CTS input
6 Data Set Ready DSR input
7 Signal Ground SG
8 Carrier Detect DCD input
20 Data Terminal Ready DTR output
22 Ring Indicator RI input
The above is virtually guaranteed to be the way your PC's serial
port is wired. Your device may or may not be wired exactly the
same, or with appropriate wires reversed (TxD and RxD, for
example) for proper operation, which would be true of a DCE. If
the device is wired as a DTE, then the cable used must be a Null
Modem, and if the device is wired as a DCE then the cable must
be straight through.
When the Windows program is started, CTS shows -5,35V against SG,
otherwise it shows 0.
That cannot be a valid assumption on which pins are which.
First, pin 5 is not signal ground on your PC, and is very
unlikely to be on your device either. Second, RS-232 lines are
either a negative voltage or a positive voltage in respect to
ground, and are *never* idle at 0 volts. They have to be more
than +3 to be considered positive (not asserted) and more than
-3 to be considered negative (asserted). When between those
values the signal condition is undefined.
Generally on computers the RS232 pins are driven with +/- 12 volt
supplies, but technically can be (and must work with) signals as
great as +/- 15 volts. Voltage regulation is not required, and
actual values might vary even on the same equipment.
It seems that this line is used to control flow.
Hardware flow control exists on at least two levels, one as an
indication that the device is turned on and ready to work, and
the other as an indication that individual characters can or
cannot be sent. The exact way that is done can vary (and is
usually different than what RS-232 was actually intended to do).
Generally the DTR signal is asserted on one side and is
connected to DSR on the other. It may also be connected to
DCD and CTS, thus indicating that data transmission can begin.
Sometimes CTS and RTS are strapped together on each end and
connected to DCD on the opposite end. All of those configurations
allow more or less ability to determine the ready state of the
remote device.
Another way is to connect DTR on one end to the opposite DSR and
DCD to indicate the device is available. Then CTS and RTS are
crossconnected between devices to permit character by character
hardware flow control.
I tried to set CTS via ioctl without success.
Good trick, given that it is an input not an output, eh! :-)
You can monitor CTS, but you cannot set it. RTS is the output,
which you can set or clear.
But generally speaking, you don't want to do that. If you
properly configure your serial port, the device driver can and
will control RTS.
Has somebody an idea, what the underlying protocol might be and how I
could control that line in Linux?PS: If this is not the proper newsgroup,
could someone point me to the correct one?
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.
Serial port programming is not really hard as such, but it is
extremely confusing. Hence experience counts much more than
smarts. Virtually nobody gets it right on their own the first
time, and everyone uses good references to keep track of how to
do it.
First, the Linux HOWTO for serial programming is filled with
errors and the program examples are loaded with bugs, so it is
an interesting read for the experienced, and a horrible
reference for newbies. Avoid it.
The number one reference you want is "Serial Programming Guide
for POSIX Operating Systems" by Michael Sweet at,
http://www.easysw.com/~mike/serial/
There are probably a number of good examples of serial port
programming available. One is to get the source code for
/minicom/, and see how they did it. A production program is
necessarily a bit convoluted, but you can eventually track down
how to do almost anything.
I have a few simpler examples posted on my web page, which might
be useful too. There are multiple examples of how to write a
simple terminal program (similar to the examples in the Linux
HOWTO for serial programming, except hopefully with fewer gross
errors, but unfortunately still with some unexplained "weird
stuff").
http://web.newsguy.com/floyd_davidson/code/terminal/
And some generic examples of diddling with ioctl's and serial
ports,
http://web.newsguy.com/floyd_davidson/code/rs232/
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@xxxxxxxxxx
.
- Follow-Ups:
- Re: Flow Control on Serial Device
- From: Floyd L. Davidson
- Re: Flow Control on Serial Device
- References:
- Flow Control on Serial Device
- From: Paul Pridt
- Re: Flow Control on Serial Device
- From: Floyd L. Davidson
- Flow Control on Serial Device
- Prev by Date: duplicate ack in tcp closing state
- Next by Date: Re: Flow Control on Serial Device
- Previous by thread: Re: Flow Control on Serial Device
- Next by thread: Re: Flow Control on Serial Device
- Index(es):
Relevant Pages
|
