Date: Thu, 19 Oct 2017 10:58:32 -0600 From: Ian Lepore <ian@freebsd.org> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: We do serial differently. Message-ID: <1508432312.1383.18.camel@freebsd.org> In-Reply-To: <CACpH0MfaP%2B0BY-1VqbnTQXe9xtLpU3%2BopYaNpRQC1so0C5iKmw@mail.gmail.com> References: <CACpH0Md0ckYH6k5ufAwCoc-_ThtJHrV9%2BdUtp66%2BSSjVuyhpxA@mail.gmail.com> <1508425713.1383.6.camel@freebsd.org> <CACpH0MfaP%2B0BY-1VqbnTQXe9xtLpU3%2BopYaNpRQC1so0C5iKmw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2017-10-19 at 12:33 -0400, Zaphod Beeblebrox wrote:
> On Thu, Oct 19, 2017 at 11:08 AM, Ian Lepore <ian@freebsd.org> wrote:
>
> >
> >
> > Use the "callout" device, /dev/cuaXX, rather than /dev/ttyXX (which
> > is
> > the "callin" device). The callin device waits for a call to come
> > in,
> > and that's implemented by blocking in open() until the modem/other-
> > end
> > asserts DTR (or DSR, I can never remember which end is which).
> >
> > So if it's hanging with /dev/ttyU0 use /dev/cuaU0.
> >
> Is the reverse true? I have been using cuaU0.
No, the reverse is not true. If you're already using the cua* device
the problem is elsewhere.
My notes for the DTR pin on an FTDI chip say this:
[3] Coming out of reset, this pin is driven high. When the tty
device is open it is driven low. As long as the channel is in uart
mode, this pin will be driven high when nobody has the tty open, and
driven low while it is open.
Note that that really describes the tty-layer behavior, it's what tells
the ftdi chip to turn dtr on and off, so it should apply to other
brands of usb adapter as well.
Looking at that page you cited in your original message and how it
talks about a dtr connection to reset, this might be the problem. You
can try "stty -f /dev/cuaU0 -hupcl" -- that will force the signal to be
driven low continuously, regardless of whether anyone has the device
open or not. But there's no telling if that's the right behavior for
your arduino, it might just be differently-wrong, like never doing the
reset at all. If the line needs to be pulsed to do a reset maybe you
can use a wrapper script that does stty hupcl; sleep .1; stty -hupcl,
then launches your program.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1508432312.1383.18.camel>