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

Tomek CEDRO <tomek@cedro.info> wrote:

> If the chip driver is there but no VID:PID pair in the kernel module
> it is trivial to add.

For a basic *test* of CNO_RTSDTR functionality (to make sure that it
is implemented correctly, that the .init device really does avoid
wiggling the control lines, etc) I will use an FT2232D board with the
standard VID:PID.  OTOH, if an actual "real" user ever comes forth who
would like to use my GSM devices (custom USB ID) with FreeBSD, *then*
we shall talk about adding the necessary support in uftdi.  In that
for-now-hypothetical scenario, I _would like_ to have a quirk where
the driver would see "aha, it is that special FreeCalypso GSM device,
set CNO_RTSDTR on Channel B by default" - but as of right now, I have
no idea whether or not such "quirky" USB ID handling would be
acceptable for official inclusion into FreeBSD.

> If you look for DTR / RTS reset/boot circuit here is an example from
> ESP32-DevKitC-V4:
>
> https://dl.espressif.com/dl/schematics/esp32_devkitc_v4-sch.pdf

"The reasonable man adapts himself to the world: the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man."

- George Bernard Shaw, Man and Superman

Aside from being a woman, I act as Bernard Shaw's unreasonable man
here.  The circuit in your linked schematic drawing is a clever
example of working around the stupidity of OSes that insist on
asserting both DTR & RTS on serial port open: they did it so that when
both signals assert simultaneously, then nothing happens, and instead
you need to have one but not the other to effect the corresponding
virtual pushbutton press.

My circuit is different: I don't have any graphical schematics to
point you to (I use a text-based PCB hardware description language
instead of graphical schematics, once again going against the
standards of all society around me), but it is just one 74LVC2G07 IC.
DTR and RTS from the USB-serial chip (FT2232D Channel B in my specific
case, but could be any other, conceptually) go to the two inputs of
this 74LVC2G07, and the two OD outputs connect to two control lines
just like in your application.  My circuit is that of Bernard Shaw's
unreasonable man: it _requires_ that host OSes fix their act and not
auto-assert DTR & RTS on open.

In any case, it's too late for me to change now.  I already have my
DUART28C adapter, and I already have fully working support for it in
FreeCalypso host tools, including -Pdtr and -Prts flags in the
relevant tools.  If I were to switch to the other design from my next
board onward, then there will be two incompatible schemes to support,
and I am not willing to gum up my FC host tools software in such a
manner.

> Be aware of the USB bottleneck here. If you transfer big amounts of
> small data (bits over bytes) with buffer switches inside it will be
> slow. You may consider creating custom USB based interface on some
> cheap MCU, so MCU will handle gpio operations and bitstream protocol
> so USB will onty read/write commands. See:
> https://github.com/ARMmbed/DAPLink

Nope, not changing - I am quite happy with FT2232D, I've been using it
in exactly this application (talking to two UARTs of TI Calypso GSM
chip) since 2017, it works great for me, and I won't change.

> In current world situation I would rather go into independent Mesh
> Networking (LoRa, Bluetooth, WiFi, whatever) rather than GSM that
> depends on a complex infrastructure that is a single point of failure
> that can be easily kill-switched that its not going to be easy to
> restore :-)

Can we please avoid telling each other what we should do with our
respective lives?  You do your thing, I do GSM - can we please
peacefully coexist?

> Anyways, if you use GSM then you also need a radio chip from a
> specific single vendor (that is also SPOF) with fairly complex radio
> circuit if you design that from scratch.. or you need to use some sort
> of module that will use proprietary firmware inside..?

The chip I use is TI Calypso.  It's been out of production for almost
20 y now, but I have enough for my needs.  The formerly-proprietary
firmware is now maintained by me, and unlike my predecessors, I freely
publish my source:

https://www.freecalypso.org/hg/fc-tourmaline/

> We were discussing Sierra modem driver recently and it seems that they
> Open-Sourced their whole firmware..?

Do you have any links?  I will never give up my own FreeCalypso, I
will never switch to anyone else's stuff for my own personal use, but
it would be nice to know what exists / what other people are doing.

M~