Date: Sat, 21 Oct 2017 12:47:36 -0600 From: Ian Lepore <ian@freebsd.org> To: Kyle Evans <kevans@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Zaphod Beeblebrox <zbeeble@gmail.com> Subject: Re: We do serial differently. Message-ID: <1508611656.1383.100.camel@freebsd.org> In-Reply-To: <CACNAnaE4Cn50_h7mMtjxOm0xt1vXZom-orAhThzS%2BW-0rt65dg@mail.gmail.com> References: <CACpH0Md0ckYH6k5ufAwCoc-_ThtJHrV9%2BdUtp66%2BSSjVuyhpxA@mail.gmail.com> <1508425713.1383.6.camel@freebsd.org> <CACpH0MfaP%2B0BY-1VqbnTQXe9xtLpU3%2BopYaNpRQC1so0C5iKmw@mail.gmail.com> <1508432312.1383.18.camel@freebsd.org> <20171019172246.GU2473@kib.kiev.ua> <CACNAnaHL%2BpW4mqckFsu0Pisz5EWxGoD5AicXXpT1wW9xaiZonQ@mail.gmail.com> <1508511786.1383.50.camel@freebsd.org> <CACNAnaE4Cn50_h7mMtjxOm0xt1vXZom-orAhThzS%2BW-0rt65dg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2017-10-20 at 10:17 -0500, Kyle Evans wrote: > On Fri, Oct 20, 2017 at 10:03 AM, Ian Lepore <ian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1508611656.1383.100.camel>