Date: Sun, 22 Oct 2017 17:57:40 -0400 From: Zaphod Beeblebrox <zbeeble@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Kyle Evans <kevans@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: We do serial differently. Message-ID: <CACpH0Md%2B5-9ASDLsO3UJSL-p8ONdqCArw1LUCVxX3oipnh4kvQ@mail.gmail.com> In-Reply-To: <1508611656.1383.100.camel@freebsd.org> 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> <1508611656.1383.100.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Firstly, this is an excellent and awesome summary of behavior. Would that we could turn it into some form of change proposal. But: here's my little state diagram: linux: arduino works, pronterface works FreeBSD:arduino works, pronterface fails arduino is a big pile of java, but it successfully talks to the arduino. Maybe in a different mode? I dunno... but it works on both OSs. pronterface is a big pile of python. It works on linux and doesn't work on FreeBSD. Now... the one possible point was that cutting the arduino's DTR trace might make it work on FreeBSD (with the proviso that using arduino would require pressing the reset switch on the hardware). Can these facts be put together in a manner that makes pronterface work on FreeBSD without the hardware hack. In particular, the "driver" for the arduino's USB serial emulation is a separate driver that we can hack. On Sat, Oct 21, 2017 at 2:47 PM, Ian Lepore <ian@freebsd.org> wrote: > > 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACpH0Md%2B5-9ASDLsO3UJSL-p8ONdqCArw1LUCVxX3oipnh4kvQ>