We do serial differently.

[Ian Lepore]

On Fri, 2017-10-20 at 08:36 -0500, Kyle Evans wrote:
> On Thu, Oct 19, 2017 at 12:22 PM, Konstantin Belousov 
> 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 .init and .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.

Hmm.  You mention the .init node, does setting -hupcl in the .lock node
fail to suppress toggling DTR as well?  That, I think, would be a bug.

-- Ian