We do serial differently.
Kyle Evans
kevans at freebsd.org
Fri Oct 20 14:00:13 UTC 2017
On Thu, Oct 19, 2017 at 12:22 PM, Konstantin Belousov <kostikbel at gmail.com>
wrote:
> On Thu, Oct 19, 2017 at 10:58:32AM -0600, Ian Lepore wrote:
> > 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.
>
> For each tty device, including cuaU*, there are <name>.init and <name>.lock
> devfs nodes which can be used to set the initial and permanent states of
> the flags. It might be useful in this situation.
>
This doesn't seem to necessarily be true with ucom(4) bits. I put in a bit
of effort to try and get devel/libserialport to stop setting DTR when it
probes /dev/cuaU* to no avail. As a consequence, connected Arduinos
constantly reset when devel/arduino18 is open unless the serial
monitor/plotter is also open.
I can appreciate that +DTR is a sensible default here, but it would be nice
if it could be configured with the .init node.
More information about the freebsd-hackers
mailing list