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

On Tue, May 24, 2022 at 12:18 PM Ian Smith <smithi@nimnet.asn.au> wrote:

> On 25 May 2022 3:09:11 am AEST, Mychaela Falconia <
> mychaela.falconia@gmail.com> wrote:
>  > 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.
>
> I'm not sure if that is a typo, going on the discussion of double
> negatives in the review, reposted here:
> https://reviews.freebsd.org/D20031
>
> The manual page footer actually says FreeBSD 13.0, and could be much
> clearer about which of those settings are or are not defaults, at least to
> this bear of little brain.
>

Yes. This was added. The default is rtsdtr, which means "do the rts/dtr
wiggling when the data device is opened."
The option is -rtsdtr to turn off this historic behavior. The -- is a typo
that's still present in the system. I've just pushed
a fix.


>  > > 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...
>
> You don't know anyone running FreeBSD who could help with testing?
>

I can test.


>  > > 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.
>
> Mychaela, I'm not sure that telling everyone that what they've been doing
> for 50 years was mistaken will cut much ice; please respect people and the
> equipment we were dealing with back then, and still are now - having built
> a couple of UART-based circuits c.1977 for a 'handmade' computer myself.
>

The .init device node exists to open the device to do initialization without
line wiggle. If we go examine the tty driver in FreeBSD (it sys/kern/tty*.c)
we can find the answers directly. For the init device, we just lock the
device, check
to see if it is still there, and unlock the device (see ttyil_open in
sys/kern/tty.c,
it's simple enough to follow). The normal device open will do the rts/dtr
wiggle,
unless it's been disabled with the option we're talking about. See
ttydev_open
in sys/kern/tty.c, which is a lot more complex, has lots of indirection, but
clearly has a test for the option:
                if ((tp->t_termios.c_cflag & CNO_RTSDTR) == 0)
                        ttydevsw_modem(tp, SER_DTR|SER_RTS, 0);

So absent direct observations to the contrary, I'd say that opening
the .init device will do what's desired here.


>  > > 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.
>
> See above.  I perceive Daniel's response as only trying to be helpful.
>
> You've posted to a general questions list but you'd likely do better on a
> more technical list, especially if you are expecting a very rapid response.
>
> At some risk to their equanimity, I've cc'd the participants in that code,
> man page and review, who are best equipped to help, should they be
> encouraged to do so.
>
> I'll leave the tail quote below for completeness.
>
> Good luck and cheers, Ian
>

All I have to add is that there's a trivial setting to make this work as
the device
designer desires, despite the fact that the device uses conventions that are
not RS-232 standard conventions (though most of them are somewhat
dated, I'll admit, given the near total lack of modems today). It's hard to
support both legacy devices and innovative devices without breaking
somebody by default, and there's not been a ground-swell to change
the defaults as of yet so it's rather favored the archaic traditions out
of inertia.

Anyway, I hope this has been helpful. I don't normally monitor the
questions@
list (and hopefully I've done the right subscribe dance for this answer to
appear).

Warner


>  > > 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~
>
>