UFTDI(4)

🌸 UFTDI(4) β€” the Kernel Interfaces Manual, but make it cute πŸŽ€

okay bestie, sit down, hydrate, because we're about to talk about USB support for serial adapters based on the FTDI family of USB serial adapter chips. this is uftdi, and she is iconic, no cap. πŸ’…


✨ NAME ✨

uftdi β€” USB support for serial adapters based on the FTDI family of USB serial adapter chips.

literally that's it, that's the whole name section, and honestly? she ate. πŸ¦‹


✨ SYNOPSIS ✨

so to compile this driver into the kernel, you gotta place these lines in your kernel configuration file:

device usb
device ucom
device uftdi

or, alternatively, if you want to load the driver as a module at boot time, put this line in loader.conf(5):

uftdi_load="YES"

both paths are valid, pick your fighter πŸ’–


✨ DESCRIPTION ✨

the uftdi driver provides support for various serial adapters based on the following FTDI chips:

  • FT8U100AX
  • FT8U232AM
  • FT8U232BM
  • FT232R
  • FT2232C
  • FT2232D
  • FT2232H
  • FT4232H
  • FT230X

look at that roster. nine chips. the whole squad showed up. πŸ‘‘

the device is accessed through the ucom(4) driver which makes it behave like a tty(4). so it's giving serial port, it's giving terminal energy, we love that for her.

many of the supported chips provide additional functionality such as bitbang mode and the MPSSE engine for serial bus emulation. the uftdi driver provides access to that functionality with the following ioctl(2) calls, defined in <dev/usb/uftdiio.h>:

  • UFTDIIOC_RESET_IO (int) β€” Reset the channel to its default configuration, flush RX and TX FIFOs.
  • UFTDIIOC_RESET_RX (int) β€” Flush the RX FIFO.
  • UFTDIIOC_RESET_TX (int) β€” Flush the TX FIFO.
  • UFTDIIOC_SET_BITMODE (struct uftdi_bitmode) β€” Put the channel into the operating mode specified in mode, and set the pins indicated by ones in iomask to output mode. the mode must be one of the uftdi_bitmodes values. setting mode to UFTDI_BITMODE_NONE returns the channel to standard UART mode.

okay so here's the enum, look at her:

enum uftdi_bitmodes
{
        UFTDI_BITMODE_ASYNC = 0,
        UFTDI_BITMODE_MPSSE = 1,
        UFTDI_BITMODE_SYNC = 2,
        UFTDI_BITMODE_CPU_EMUL = 3,
        UFTDI_BITMODE_FAST_SERIAL = 4,
        UFTDI_BITMODE_CBUS = 5,
        UFTDI_BITMODE_NONE = 0xff,
};

and the struct:

struct uftdi_bitmode
{
        uint8_t mode;
        uint8_t iomask;
};

manuals and application notes published by FTDI describe these modes in detail. to use most of these modes, you first put the channel into the desired mode, then you read(2) and write(2) data which either reflects pin state or is interpreted as MPSSE commands and parameters, depending on the mode. so like, read the FTDI docs too, bestie, this manpage isn't gonna hold your hand through MPSSE. 🧚

  • UFTDIIOC_GET_BITMODE (struct uftdi_bitmode) β€” Return the current bitbang mode in the mode member, and the state of the DBUS0..DBUS7 pins at the time of the call in the iomask member. the pin state can be read while the chip is in any mode, including UFTDI_BITMODE_NONE (UART) mode. so you can peek at the pins whenever, she doesn't gatekeep. πŸ™ˆ
  • UFTDIIOC_SET_ERROR_CHAR (int) β€” Set the character which is inserted into the buffer to mark the point of an error such as FIFO overflow.
  • UFTDIIOC_SET_EVENT_CHAR (int) β€” Set the character which causes a partial FIFO full of data to be returned immediately even if the FIFO is not full.
  • UFTDIIOC_SET_LATENCY (int) β€” Set the amount of time to wait for a full FIFO, in milliseconds. if more than this much time elapses without receiving a new character, any characters in the FIFO are returned.
  • UFTDIIOC_GET_LATENCY (int) β€” Get the current value of the latency timer.
  • UFTDIIOC_GET_HWREV (int) β€” Get the hardware revision number. this is the bcdDevice value from the usb_device_descriptor.
  • UFTDIIOC_READ_EEPROM (struct uftdi_eeio) β€” Read one or more words from the configuration eeprom. the FTDI chip performs eeprom I/O in 16-bit words. set offset and length to values evenly divisible by two before the call, and the data array will contain the requested values from eeprom after the call.
struct uftdi_eeio
{
        uint16_t offset;
        uint16_t length;
        uint16_t data[64];
};

the FT232R chip has an internal eeprom. an external serial eeprom is optional on other FTDI chips. the eeprom may contain 64, 128, or 256 words, depending on the part used. multiple calls may be needed to read or write the larger parts. when no eeprom is present, all words in the returned data are 0xffff. an erased eeprom also reads as all 0xffff. so if you're getting a wall of 0xffff, that's the vibe, that's the tea. πŸ’€

  • UFTDIIOC_WRITE_EEPROM (struct uftdi_eeio) β€” Write one or more words to the configuration eeprom. the uftdi_eeio values are as described for UFTDIIOC_READ_EEPROM.
⚠️ okay listen up: the FTDI chip does a blind write to the eeprom, and it will appear to succeed even when no eeprom is present. to ensure a good write you must read back and verify the data. it is not necessary to erase before writing. any position within the eeprom can be overwritten at any time. so like, trust but verify, bestie, because the chip will lie to your face and feel zero guilt about it. 😭
  • UFTDIIOC_ERASE_EEPROM (int) β€” Erase the entire eeprom. this is useful primarily for test and debugging, as there is no need to erase before writing. to help prevent accidental erasure caused by calling the wrong ioctl, you must pass the special value UFTDI_CONFIRM_ERASE as the argument to this ioctl.
πŸ’€ she literally makes you type the confirmation value because she does NOT trust you to not nuke the eeprom by accident. and honestly? fair. iconic protective queen behavior.

✨ HARDWARE ✨

the uftdi driver supports the following adapters:

  • B&B Electronics USB->RS422/485 adapter
  • Elexol USB MOD1 and USB MOD3
  • HP USB-Serial adapter shipped with some HP laptops
  • Inland UAS111
  • QVS USC-1000
  • Buffalo PC-OP-RS / Kurouto-shikou KURO-RS universal remote
  • Prologix GPIB-USB Controller

the range?? universal remote to GPIB controller?? she contains multitudes. 🌈


✨ FILES ✨

/dev/ttyU*       for callin ports
/dev/ttyU*.init
/dev/ttyU*.lock  corresponding callin initial-state and lock-state
                 devices

/dev/cuaU*       for callout ports
/dev/cuaU*.init
/dev/cuaU*.lock  corresponding callout initial-state and lock-state
                 devices

callin ports and callout ports, each with their own .init and .lock friends. a whole little family. 🫢


✨ SEE ALSO ✨

tty(4), ucom(4), usb(4)

go read those too, they're the supporting cast and they deserve their flowers. 🌸


✨ HISTORY ✨

the uftdi driver appeared in FreeBSD 4.8 from NetBSD 1.5. a little cross-BSD glow-up moment, we love to see it. ✨


and that's the whole page, bestie!! πŸ’– this was the UFTDI(4) Kernel Interfaces Manual, from the Debian source, dated April 26, 2017 β€” she's an older queen but she still runs the game. mwah, go flash some eeproms responsibly, and remember: read back your writes. πŸŽ€πŸ’…πŸ¦‹

πŸ“¦ where this page comes from