From owner-freebsd-hackers@freebsd.org Sat Oct 21 18:47:46 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 04A82E37050 for ; Sat, 21 Oct 2017 18:47:46 +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 D8B63669CF for ; Sat, 21 Oct 2017 18:47:45 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 33d825e8-b690-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 33d825e8-b690-11e7-b50b-53dc5ecda239; Sat, 21 Oct 2017 18:46:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9LIla7E013927; Sat, 21 Oct 2017 12:47:36 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508611656.1383.100.camel@freebsd.org> Subject: Re: We do serial differently. From: Ian Lepore To: Kyle Evans Cc: Konstantin Belousov , FreeBSD Hackers , Zaphod Beeblebrox Date: Sat, 21 Oct 2017 12:47:36 -0600 In-Reply-To: References: <1508425713.1383.6.camel@freebsd.org> <1508432312.1383.18.camel@freebsd.org> <20171019172246.GU2473@kib.kiev.ua> <1508511786.1383.50.camel@freebsd.org> 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: Sat, 21 Oct 2017 18:47:46 -0000 On Fri, 2017-10-20 at 10:17 -0500, Kyle Evans wrote: > On Fri, Oct 20, 2017 at 10:03 AM, Ian Lepore wrote: > > > > > On Fri, 2017-10-20 at 08:36 -0500, Kyle Evans wrote: > > > > > > 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 > > > Yeah, that also fails to suppress it. For documentation purposes, this is > the exact device/driver I'm working with: > > > ugen0.2: www.arduino.cc product 0x0043> at usbus0 > umodem0 on uhub0 > umodem0: www.arduino.cc product 0x0043, class 2/0, rev 1.10/0.01, > addr 9> on usbus0 > umodem0: data interface 1, has CM over data, has break > > > When I last poked at it, I think I had decided that this line: > https://svnweb.freebsd.org/base/head/sys/dev/usb/serial/usb_serial.c?view=markup#l735 > > was the culprit and blatantly ignoring any configuration, but this isn't > exactly an area that I'm familiar with so I assume there might be something > elsewhere that I'm missing. First, a word about DTR being asserted vs. de-asserted... RS232 signals are inverted from the corresponding UART signals.  That is, when the DTR signal is 0 at the output of a uart chip, it runs through an RS232 line-level converter which inverts the signal to a 1 on the RS232 output side.  Often with embedded system stuff there is no RS232 conversion, the signals remain at uart levels on both ends.  In this case, "DTR asserted" means 0v on the DTR pin of the uart chips. Okay, after some digging, here's what I've found about how freebsd behaves with DTR... On first open(), DTR is asserted.  There is no control over that, it's just always going to happen.  (Slightly buggy: multiple serial drivers do this, and the tty layer does it too.  I think only the tty layer should do it.) On last close(), DTR is de-asserted unless -hupcl has been set.  This seems to be done ONLY in various drivers, and not be the tty layer, which seems differently-buggy than the open-assertion case.  Maybe there is a reason the tty layer can't do this, I didn't dig into it. If you set both /dev/cuaU#.init and /dev/cuaU#.lock to -hupcl, that will ensure that once the device is opened for the first time, DTR will remain asserted forever after that.  (setting .lock prevents any program from changing that setting.) There is no way to prevent DTR from ever being asserted. Things I've read about linux while searching for info on this seem to indicate it behaves the same way (but it lacks the .init and .lock features).  Apparently only on Windows is it possible to configure serial drivers to leave the DTR line completely untouched. -- Ian