From owner-freebsd-hackers@freebsd.org Fri Oct 20 15:03:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9057DE37FAD for ; Fri, 20 Oct 2017 15:03:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DD6E7E57A for ; Fri, 20 Oct 2017 15:03:09 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ad246a03-b5a7-11e7-b50b-53dc5ecda239 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id ad246a03-b5a7-11e7-b50b-53dc5ecda239; Fri, 20 Oct 2017 15:02:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9KF36MQ011259; Fri, 20 Oct 2017 09:03:06 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508511786.1383.50.camel@freebsd.org> Subject: Re: We do serial differently. From: Ian Lepore To: Kyle Evans , Konstantin Belousov Cc: FreeBSD Hackers , Zaphod Beeblebrox Date: Fri, 20 Oct 2017 09:03:06 -0600 In-Reply-To: References: <1508425713.1383.6.camel@freebsd.org> <1508432312.1383.18.camel@freebsd.org> <20171019172246.GU2473@kib.kiev.ua> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:03:09 -0000 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