Re: Unwanted auto-assertion of DTR & RTS on serial port open

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~