Date: Tue, 24 May 2022 09:09:11 -0800 From: Mychaela Falconia <mychaela.falconia@gmail.com> To: Daniel Feenberg <feenberg@nber.org> Cc: freebsd-questions@freebsd.org Subject: Re: Unwanted auto-assertion of DTR & RTS on serial port open Message-ID: <CA%2BuuBqbJtZFfPm-jMou9A=57-MGbRHKPzKu2aYn%2B-=A0rSQiPQ@mail.gmail.com> In-Reply-To: <b3ca19e-e7b2-92b6-dba1-d9734c2b3a11@nber.org> References: <CA%2BuuBqZ=PJMcuWj%2Bz3kGAy0bG=1S8oRXUAaO13PPqTea%2BoS04Q@mail.gmail.com> <b3ca19e-e7b2-92b6-dba1-d9734c2b3a11@nber.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Feenberg wrote: > The man page adds the (-)rtsdtr option in version 13.1: > > https://www.freebsd.org/cgi/man.cgi?query=stty > > and I can confirm it is an invalid argument in 13.0. Huh? That very same man.cgi on freebsd.org tells me that (-)rtsdtr first appears in 13.0 (there is a typo in the man page, the negative form is -rtsdtr, not --rtsdtr as the man page says), ditto for the appearance of CNO_RTSDTR in termios(4), the underlying kernel interface. > You should be able to test it with any old desktop computer pretty > easily though. Still a massive learning curve, given that I don't regularly use FreeBSD (or any other alphabetic-prefix-BSD) at all, only Slackware Linux. It will probably be a few months before I can make the necessary time allocation. Lots of other higher priorities: I need to finish setting up my own test GSM network, I need to get my Venus board into PCB layout, etc - you get the idea. Testing whether or not FreeBSD's recent CNO_RTSDTR addition really fixes the design flaw inherited from 1970s UNIX is only a side project here... > Documented things tend to work. It looks like the key point of my inquiry mas missed. I have no doubt that the newly added CNO_RTSDTR termios flag (and stty -rtsdtr user front end to it) works as documented, meaning that on subsequent opens of the "regular" (sans .init) tty device the unwanted auto-assertion of DTR & RTS will be suppressed. But the part which is not clear at all, which is not documented anywhere I could find, is whether or not the act of opening /dev/ttyU1.init (for the purpose of setting the termios flag) will jerk the modem control lines. If the latter line jerking still happens, then FreeBSD's recent "fix" does NOT really fix the ancient design flaw from 1970s - or if opening of the .init device does not assert modem control lines, *then* (and only then) we will be able to celebrate, and tell the world that FreeBSD is the first Unix-style OS that finally fixed the old 1970s serial port control misdesign. > Have you thought of the alternative solution of cutting some wires > in the serial cable? Ahmm, I am the _designer_ of the hardware in question. If I wanted to modify my design, I wouldn't be cutting wires, I would modify the design at the source. But why would I agree to modify what I consider to be a beautiful design? My approach is one of philosophical principle: if the flawed design of 1970s Unix is the thing that's in the wrong, then it is the flawed OS that needs to be fixed (which in my case is Linux - I am merely _inquiring_ about FreeBSD), rather than me giving up on my idea of elegant hw design to please the broken OS. > Does your device even need those signals? Yes, I put that circuit in there for a reason: with this circuit added, giving a -Prts (pulse RTS) command line flag to my FreeCalypso tools fc-loadtool, fc-iram, fc-xram, rvinterf etc causes a PWON (current hw) or RPWON (next upcoming hw) pulse to be given to Iota VRPC, whereas giving a -Pdtr (pulse DTR) command line flag to the same tools causes a deep reset pulse to be sent to the target. These host-controlled boot modes are super-helpful for both hardware bring-up and firmware development. > Would it work at a lower data rate? What do data rates have anything to do with DTR & RTS control signal issues? But as far as data rates go, "would it work at a lower data rate" is the wrong question to ask - instead it is the duty of hardware engineers like me to design our hardware so that the highest possible data rates will work. My Calypso GSM chip (no, I didn't make the chip, I only make boards with these chips on them, but I do act as a sort of Adoptive Mother to the chip design itself too) supports standard UART baud rates up to 115200 bps, and GSM-specific (otherwise non-standard) baud rates up to 812500 bps. FT2232D handles all of them just fine, and so does Linux. And when you are routinely transferring >2 MiB code images (flash or run-from-RAM) in the course of firmware development, that highest baud rate of 812500 bps really does help. Back to FreeBSD: as of right now, I don't have any active or even prospective users of my FreeCalypso GSM devices who have expressed a desire to use my GSM gear with FreeBSD instead of Linux. But about a year and a half ago, when I went to battle against Linux kernel gatekeepers^Wmaintainers, trying to get them to mainline my patch that fixes the DTR & RTS problem in Linux, one of them pointed me to that FreeBSD review D20031, showing how the problem has recently been addressed in FreeBSD. I know for certain that the solution which this particular Linux maintainer has been advocating for would not work correctly in Linux, which lacks ttyXX.init devices altogether - but I am still seeking to find out whether or not FreeBSD's seeming-fix actually fixes the problem in FreeBSD, as a matter of information gathering. It appears that the topic at hand is too obscure and specialized for anyone to have a ready answer - so it looks like there is no other way to proceed than biting the bullet and getting FreeBSD installed just for this test. I will now go back to setting up my test GSM network, but maybe I can squeeze in this FreeBSD install in between the test network and FC Venus board. M~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BuuBqbJtZFfPm-jMou9A=57-MGbRHKPzKu2aYn%2B-=A0rSQiPQ>