Date: Wed, 25 May 2022 01:40:39 +0200 From: Tomek CEDRO <tomek@cedro.info> To: Mychaela Falconia <mychaela.falconia@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, Ian Smith <smithi@nimnet.asn.au>, Daniel Feenberg <feenberg@nber.org>, FreeBSD questions <freebsd-questions@freebsd.org>, Warner Losh <imp@freebsd.org>, Kyle Evans <kevans@freebsd.org> Subject: Re: Unwanted auto-assertion of DTR & RTS on serial port open Message-ID: <CAFYkXj=-PLWCv=vtuco0CqET7J%2B4Cbvcyp0D3t6FM1Rxp9Kv8Q@mail.gmail.com> In-Reply-To: <CA%2BuuBqZ-Dpktqi4XFv1D5MA=L8X_Feq3Fo%2BFZoF_gjqrnWVL=A@mail.gmail.com> References: <CA%2BuuBqZ=PJMcuWj%2Bz3kGAy0bG=1S8oRXUAaO13PPqTea%2BoS04Q@mail.gmail.com> <b3ca19e-e7b2-92b6-dba1-d9734c2b3a11@nber.org> <CA%2BuuBqbJtZFfPm-jMou9A=57-MGbRHKPzKu2aYn%2B-=A0rSQiPQ@mail.gmail.com> <55AF97D3-5212-4A58-9942-3207A176C179@nimnet.asn.au> <CANCZdfpOEkOxcBsvW7NdGd9i99bo5Dn2LjJUyAV9mex_NHcJVw@mail.gmail.com> <CA%2BuuBqZ-Dpktqi4XFv1D5MA=L8X_Feq3Fo%2BFZoF_gjqrnWVL=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 25, 2022 at 12:47 AM Mychaela Falconia wrote: > Sounds like good news - but I am also going to test it myself on > actual hardware, i.e., I'll go through the learning curve of > installing FreeBSD on a spare laptop. For the test setup, my current > plan is to connect a USB cable from the FreeBSD machine to an FT2232D > breakout board, see if ttyU* and cuaU* devices appear as I would > expect, then connect an oscilloscope probe to DTR/RTS (first one, then > the other), set the scope to trigger on a falling edge (set the > trigger level to 2.0 V, the most common Vih spec for 3.3V logic) and > verify that no unwanted falls happen on either control signal. Does > anyone see any problems with this plan? I am using PL2303, FT2232D, FT2232H, and CP2102 based devices with no problem on FreeBSD for years with custom and self-designed hardware :-) If the chip driver is there but no VID:PID pair in the kernel module it is trivial to add. I usually use Minicom, PySerial, recently mpremote with ESP32. 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 I have CP2102 USB adapter at hand to control and program ESP32 and ESP32-C3 chips.. but it only has RTS and CTS signals to control Reset and Boot lines as described in schematics above. I also use Prolific PL2303 USB-to-RTS232 converter that seem to have all CTS, RTS, DTR, DCD, DSR, RI lines so I can check on an oscilloscope something for you if you like (I am working on 13.1-STABLE). > Also if someone is opening a non-modem (no dial-in or dial-out > concepts) serial port for the purpose of talking to non-modem gear > (think industrial instrumentation, whatever), would it be more > "proper" to use ttyXX or cuaXX? On Linux there is only one ttyUSBx > for each port, but with FreeBSD there is a choice - hence I'd like to > know which one is more philosophically proper. I always used /dev/cuaU* for USB devices.. /dev/ttyU* showed up recently and means the same? > > despite the fact that the device uses conventions that are > > not RS-232 standard conventions This is UART transport over physical medium, TTL would be 0..5V or 0..3.3V maybe even 0..1.8V depending on the hardware. 0 is 0 (0V) and 1 is 1 (1.8V, 3.3V, 5V whatever logic is used). If you use RS-232 then 0 is +3..+12V and 1 is -5..-3V. and you need interface circuit such as MAX3232 for 3.3V logic. See: https://en.wikipedia.org/wiki/RS-232#Voltage_levels > But what's the alternative? On my target GSM device I have one full > 8-wire UART channel, another separate UART channel that is only TxD & > RxD, and two non-serial control lines which I would like to be able to > trigger from the connected host computer. My current solution covers > all of these interfaces with a single FT2232D chip. Someone could say > that I should replace this FT2232D with FT4232H (4 UART channels > instead of 2, and they don't make a 4-channel version in non-H), and > use each of the 2 extra UART channels just for its DTR (or RTS) > output, so that its control output can be independently wiggled by > opening that separate "serial" port. But this solution would have > negatives for both power efficiency and developer-user convenience: Whatever works and suits the need. I did several protocols on FT2232H chips, including UART, SPI, I2C, also Debug protocols JTAG and SWD (for ARM Cortex). The first JTAG adapters around 2010 were FT2232D and they worked too :-) I even added my custom FT2232H interface to work with AvrDude to program ATtiny10. I always carry KT-LINK interface in my backpack :-) Usually one channel on FT2232H is used for UART, the other is used for bitbang / custom protocol. If you mean Debug as JTAG or SWD not UART logging. 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 > But my GSM device is in fact a modem - or rather a cellphone handset > with built-in modem functionality. 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 :-) 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..? We were discussing Sierra modem driver recently and it seems that they Open-Sourced their whole firmware..? > Given the unavoidable problem of negatives and the desire to avoid > making it even worse with double negatives, the folks who implemented > this recent feature addition in FreeBSD settled for a somewhat > inverted sense between the underlying termios flag and stty front end: > > stty rtsdtr means CNO_RTSDTR flag is NOT set (default) > stty -rtsdtr means CNO_RTSDTR flag is SET (opposite of default) Aaah, now its clear! Thanks! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFYkXj=-PLWCv=vtuco0CqET7J%2B4Cbvcyp0D3t6FM1Rxp9Kv8Q>