RE: DTD required (was Re: Trouble reading from my serial device ( a microcontroller))

RE: DTD required (was Re: Trouble reading from my serial device ( a microcontroller))

[Ed Vance]

Hi Chuck,

Yep, I'm surprised too about open. Also, in theory, the read should not have
hanged, because you had previously set CLOCAL. Just a bug or two, here. Oh
well. For hysterical .. oops .. historical reasons, the default termio(s)
settings have CLOCAL off. The idea was that if you were using a modem, the
port would hang in the open until the phone line and modem connection was
made, as evidenced by detection of carrier tone from the remote modem. (DCD
= carrier detect). This standard behavior has frustrated people who were
just trying to connect local devices for many years. Some systems have a
"soft carrier" option outside of termios that causes a port to act as if DCD
is always asserted. 

You can accomplish the same thing by looping back DTR (pin 4) to DCD (pin
1). Open will assert DTR, and that will drive DCD high for you. That's what
most folks do.

Cheers,
Ed

> -----Original Message-----
> From: Chuck Messenger [mailto:chuckm@rochester.rr.com]
On Thu, Nov 20, 2003 1:13 PM, Chuck Messenger wrote:
> 
> Thanks, Ed.
> 
> I just got done trying out connecting DCD to +12 before reading your 
> message - it did the trick.
> 
> I did not call open() with O_NONBLOCK, but open() did not hang.  The 
> documentation I've read suggests that open() would hang in this case, 
> without DCD, but since I found that open() didn't hang, I figured DTD 
> wasn't necessary.
> 
> I guess the documentation is wrong.
> 
> Thanks for the fast response!
> 
> On another note: why should the Linux device driver require DTD to be 
> on?  This seems like a bad design -- surely it should be controllable 
> via tcsetattr() or an ioctl or something...?  And, it would 
> be useful if 
> the requirement was documented.
> 
>      - Chuck
> 
> Ed Vance wrote:
> > On Thu, Nov 20, 2003 at 11:23 AM, Chuck Messenger wrote:
> > 
> >>I'm unable to read from a serial device under Linux (Mandrake 9.1, 
> >>2.4.21-0.13mdk kernel), but the device works find in Windows.  I'm 
> >>hoping someone can offer me suggestions.
> >>
> >>My device is a Basic Stamp microcontroller, which I've 
> programmed to 
> >>spit out a certain byte continuously -- 0x40 -- at 38400 
> >>baud,n,8,1. The 
> >>device loops RTS back to DSR (i.e. it connects pins 6 and 7 
> >>of the 9-pin 
> >>serial connector -- DSR and RTS).  Other than that, only Rx 
> >>and Tx are 
> >>connected (and ground, of course).
> >>
> >>I know the hardware works (both controller and PC), because I 
> >>can boot 
> >>Win2k on the same machine and run a short program I wrote which 
> >>continuously dumps to the console whatever comes in.
> >>
> >>Also, I know that things are _basically_ configured right, in 
> >>my Linux 
> >>boot, since I can run "statserial /dev/tts/0", which shows, in real 
> >>time, the status of the DSR line.  When I unplug from my 
> device, DSR 
> >>goes low; when I plug it back in, DSR goes high.
> >>
> > 
> > [snip]
> > 
> >>However, the program fails to read any bytes -- it hangs at 
> >>the read().
> >>
> >>I've tried running serlook, but that, too, failed to see any bytes.
> >>
> >>Any suggestions?
> >>
> >>I've tried 9600 baud instead of 38400 -- still no luck (although it 
> >>works under Win2k).
> >>
> >>Poking around, I've seen mention of the DCD control line -- 
> >>could that 
> >>be the problem (i.e. does the Linux serial driver require it, 
> >>somehow? 
> >>I don't have it hooked up.)
> >>
> > 
> > Hi Chuck,
> > 
> > Your program works fine on my Red Hat 7.3 setup. A 
> difference is that all of
> > my modem status lines are driven. (could not find my 
> breakout box) Try
> > connecting your serial port's DTR output to its DCD input. 
> Perhaps the
> > program is hanging on the open instead of the read, because 
> DCD is detected
> > low and you are not opening with O_NONBLOCK (or O_NDELAY).
> > 
> > cheers,
> > Ed
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-serial" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Serial Howto suggestions (was Re: Trouble reading from my serial device...)

[Chuck Messenger]

OK, thanks for the thorough explanation, Ed -- it all makes sense now...

As far as the documentation goes -- I'm sending this to the 
maintainers/writers of the Linux Serial Howto, and the Linux Serial 
Programming Howto.  I had trouble sending to both before, so I'm 
cross-posting here in the hopes they might see it...

1) In my experience, open() does not hang if DTD is not asserted, even 
without O_NONBLOCK.  Instead, open() returns, but read() hangs instead. 
  If DTD is not asserted, and you open with O_NONBLOCK, then open() 
returns (as per the documentation), but all read()'s fail right away 
(not in the documentation).

2) It would be very helpful to point out in the documentation that you 
_must_ assert DCD -- in hardware -- or it will be impossible for you to 
operate the serial port, no matter what software flags you use.  It 
would be nice to point out the trick of attaching DTR to DCD, too.

For reference, I'm running Mandrake 9.1, with kernel 2.4.21-0.13mdk.

     - Chuck

Ed Vance wrote:
> Hi Chuck,
> 
> Yep, I'm surprised too about open. Also, in theory, the read should not have
> hanged, because you had previously set CLOCAL. Just a bug or two, here. Oh
> well. For hysterical .. oops .. historical reasons, the default termio(s)
> settings have CLOCAL off. The idea was that if you were using a modem, the
> port would hang in the open until the phone line and modem connection was
> made, as evidenced by detection of carrier tone from the remote modem. (DCD
> = carrier detect). This standard behavior has frustrated people who were
> just trying to connect local devices for many years. Some systems have a
> "soft carrier" option outside of termios that causes a port to act as if DCD
> is always asserted. 
> 
> You can accomplish the same thing by looping back DTR (pin 4) to DCD (pin
> 1). Open will assert DTR, and that will drive DCD high for you. That's what
> most folks do.
> 
> Cheers,
> Ed
...

Re: Serial Howto suggestions (was Re: Trouble reading from my serial device...)

[Gary Frerking]

I've saved this whole thread for future consideration, thanks.

-- Gary

----- Original Message ----- 
From: "Chuck Messenger" <chuckm@rochester.rr.com>
To: <linux-serial@vger.kernel.org>
Sent: Thursday, November 20, 2003 7:47 PM
Subject: Serial Howto suggestions (was Re: Trouble reading from my serial
device...)


> OK, thanks for the thorough explanation, Ed -- it all makes sense now...
>
> As far as the documentation goes -- I'm sending this to the
> maintainers/writers of the Linux Serial Howto, and the Linux Serial
> Programming Howto.  I had trouble sending to both before, so I'm
> cross-posting here in the hopes they might see it...
>
> 1) In my experience, open() does not hang if DTD is not asserted, even
> without O_NONBLOCK.  Instead, open() returns, but read() hangs instead.
>   If DTD is not asserted, and you open with O_NONBLOCK, then open()
> returns (as per the documentation), but all read()'s fail right away
> (not in the documentation).
>
> 2) It would be very helpful to point out in the documentation that you
> _must_ assert DCD -- in hardware -- or it will be impossible for you to
> operate the serial port, no matter what software flags you use.  It
> would be nice to point out the trick of attaching DTR to DCD, too.
>
> For reference, I'm running Mandrake 9.1, with kernel 2.4.21-0.13mdk.
>
>      - Chuck
>
> Ed Vance wrote:
> > Hi Chuck,
> >
> > Yep, I'm surprised too about open. Also, in theory, the read should not
have
> > hanged, because you had previously set CLOCAL. Just a bug or two, here.
Oh
> > well. For hysterical .. oops .. historical reasons, the default
termio(s)
> > settings have CLOCAL off. The idea was that if you were using a modem,
the
> > port would hang in the open until the phone line and modem connection
was
> > made, as evidenced by detection of carrier tone from the remote modem.
(DCD
> > = carrier detect). This standard behavior has frustrated people who were
> > just trying to connect local devices for many years. Some systems have a
> > "soft carrier" option outside of termios that causes a port to act as if
DCD
> > is always asserted.
> >
> > You can accomplish the same thing by looping back DTR (pin 4) to DCD
(pin
> > 1). Open will assert DTR, and that will drive DCD high for you. That's
what
> > most folks do.
> >
> > Cheers,
> > Ed
> ...
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

low_latency flag

[Chuck Messenger]

In my continuing efforts to connect to a real-time device, I came across 
another problem -- latency.  I found that there was significant delay 
(multiple ms) between the time a byte arrives at the port, and the time 
that read() supplies it to my program.

Luckily, I happened to notice a recent message on this list with the 
word "low_latency".  This led me to discover the low_latency flag, which 
you can set with "setserial /dev/ttyS0 low_latency".  This sets a 
special mode on the port, which defeats some kernel-level buffering.  I 
don't (yet) know how to set this mode programmatically -- I just call 
system("...") from my code (yech!).

I'm posting this in the hopes that someone trying to do something 
similar finds it useful some day...

(P.S. Can someone tell me how to set the low_latency flag programmatically?)

     - Chuck


Chuck Messenger wrote:
> OK, thanks for the thorough explanation, Ed -- it all makes sense now...
> 
> As far as the documentation goes -- I'm sending this to the 
> maintainers/writers of the Linux Serial Howto, and the Linux Serial 
> Programming Howto.  I had trouble sending to both before, so I'm 
> cross-posting here in the hopes they might see it...
> 
> 1) In my experience, open() does not hang if DTD is not asserted, even 
> without O_NONBLOCK.  Instead, open() returns, but read() hangs instead. 
>  If DTD is not asserted, and you open with O_NONBLOCK, then open() 
> returns (as per the documentation), but all read()'s fail right away 
> (not in the documentation).
> 
> 2) It would be very helpful to point out in the documentation that you 
> _must_ assert DCD -- in hardware -- or it will be impossible for you to 
> operate the serial port, no matter what software flags you use.  It 
> would be nice to point out the trick of attaching DTR to DCD, too.
> 
> For reference, I'm running Mandrake 9.1, with kernel 2.4.21-0.13mdk.
> 
>     - Chuck
> 
> Ed Vance wrote:
> 
>> Hi Chuck,
>>
>> Yep, I'm surprised too about open. Also, in theory, the read should 
>> not have
>> hanged, because you had previously set CLOCAL. Just a bug or two, 
>> here. Oh
>> well. For hysterical .. oops .. historical reasons, the default termio(s)
>> settings have CLOCAL off. The idea was that if you were using a modem, 
>> the
>> port would hang in the open until the phone line and modem connection was
>> made, as evidenced by detection of carrier tone from the remote modem. 
>> (DCD
>> = carrier detect). This standard behavior has frustrated people who were
>> just trying to connect local devices for many years. Some systems have a
>> "soft carrier" option outside of termios that causes a port to act as 
>> if DCD
>> is always asserted.
>> You can accomplish the same thing by looping back DTR (pin 4) to DCD (pin
>> 1). Open will assert DTR, and that will drive DCD high for you. That's 
>> what
>> most folks do.
>>
>> Cheers,
>> Ed
> 
> ...
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: low_latency flag

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Fri, 2003-11-21 16:59:50 -0500, Chuck Messenger <chuckm@rochester.rr.com>
wrote in message <bpm18m$73f$1@sea.gmane.org>:
> Luckily, I happened to notice a recent message on this list with the 
> word "low_latency".  This led me to discover the low_latency flag, which 
> you can set with "setserial /dev/ttyS0 low_latency".  This sets a 
> special mode on the port, which defeats some kernel-level buffering.  I 
> don't (yet) know how to set this mode programmatically -- I just call 
> system("...") from my code (yech!).

Looking at setserial's sources, something like this:

struct serial_struct serinfo;
fd = open ("/dev/ttySxx");
ioctl (fd, TIOCGSERIAL, &serinfo);
serinfo.flags |= 0x4000;
ioctl (fd, TIOCSSERIAL, &serinfo);
close (fd);

should do. Of course, not tested and missing all error handling:-(

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: low_latency flag

[Chuck Messenger]

Jan-Benedict Glaw wrote:
> On Fri, 2003-11-21 16:59:50 -0500, Chuck Messenger <chuckm@rochester.rr.com>
> wrote in message <bpm18m$73f$1@sea.gmane.org>:
> 
>>Luckily, I happened to notice a recent message on this list with the 
>>word "low_latency".  This led me to discover the low_latency flag, which 
>>you can set with "setserial /dev/ttyS0 low_latency".  This sets a 
>>special mode on the port, which defeats some kernel-level buffering.  I 
>>don't (yet) know how to set this mode programmatically -- I just call 
>>system("...") from my code (yech!).
> 
> 
> Looking at setserial's sources, something like this:
> 
> struct serial_struct serinfo;
> fd = open ("/dev/ttySxx");
> ioctl (fd, TIOCGSERIAL, &serinfo);
> serinfo.flags |= 0x4000;
> ioctl (fd, TIOCSSERIAL, &serinfo);
> close (fd);
> 
> should do. Of course, not tested and missing all error handling:-(
> 
> MfG, JBG

Thanks for the idea.  Looking into it, I see in 
/usr/include/linux/serial.h, the definition for serial_struct.  The 
comments show these values for the flags member:

/*
  * Definitions for async_struct (and serial_struct) flags field
  */
...
#define ASYNC_LOW_LATENCY 0x2000 /* Request low latency behaviour */
#define ASYNC_BUGGY_UART  0x4000 /* This is a buggy UART, skip some safety
                                   * checks.  Note: can be dangerous! */
...

So, it looks like 0x2000 is the right value -- better, just use 
ASYNC_LOW_LATENCY.

To save some future reader some time, you need:

#include <sys/ioctl.h>
#include <linux/ioctl.h>
#include <linux/serial.h>

I tried it out and it works.  Thanks!


     - Chuck

Re: Serial Howto suggestions (was Re: Trouble reading from my serial device...)

[David Lawyer]

On Thu, Nov 20, 2003 at 09:47:51PM -0500, Chuck Messenger wrote:
> OK, thanks for the thorough explanation, Ed -- it all makes sense now...
> 
> As far as the documentation goes -- I'm sending this to the 
> maintainers/writers of the Linux Serial Howto, and the Linux Serial 
> Programming Howto.  I had trouble sending to both before, so I'm 
> cross-posting here in the hopes they might see it...
> 
> 1) In my experience, open() does not hang if DTD is not asserted, even 
> without O_NONBLOCK.  Instead, open() returns, but read() hangs instead. 
>  If DTD is not asserted, and you open with O_NONBLOCK, then open() 
> returns (as per the documentation), but all read()'s fail right away 
> (not in the documentation).
> 
> 2) It would be very helpful to point out in the documentation that you 
> _must_ assert DCD -- in hardware -- or it will be impossible for you to 
> operate the serial port, no matter what software flags you use.

Not so.  At least not on my system.  I'm running kernel 2.4.20 and
updated using Debian unstable a few months ago.  I'm now typing on a
dump terminal which is only connected by 3 wires to the PC so there is
no DCD.  But getty has set clocal which does the trick

Furthermore, I just used minicom to open my serial port for my modem
while watching "modemstat".  It shows DCD off (red) since I've set up my
modem to only assert DCD once the modem connects.  No problem opening
the port or reading it.  It reads when I see the results of AT commands
such as displaying the modem settings to double check that I've set it
for DCD off until connect.

So the way it's described is the way it's been working for many years.
I just checked the modemstat code and it opens the port without
O_NONBLOCK so it may well be that it's read() that hangs and not open().
Modemstat just checks the control lines and doesn't do any reads.

		David Lawyer (maintainer of Serial-HOWTO)

> It would be nice to point out the trick of attaching DTR to DCD, too.

> For reference, I'm running Mandrake 9.1, with kernel 2.4.21-0.13mdk.

Was a bug introduced with 2.4.21?  Anyway, you could try setting your
modem to negate DCD and see if you can dial out.

> 
>     - Chuck
> 
[snip]