Context

FTDI chips like the FT2232H are USB peripherals that are typically used as serial ports (UARTs with the RS232 standard RTS/CTS/etc lines), but can also be used as parallel ports, I2C or SPI drivers as well as as GPIOs.

On Linux, there are two implementations of the USB protocol used by them: libftdi and the Linux kernel version (the page was last touched in 2010, but seems to be up to date; the mailing list is still useful; the code lives in the linux kernel).

The FTDI library offers comparatively comprehensive support (enhanced by libmpsse? Not sure how much which library does) in a platform-independent way.

The kernel driver only supports the serial interface.

The Decision

Applications built for accessing hardware behind FTDI chips need to decide which interface to use, based on the following criteria:

1) libftdi is platform independent; the software can run on other OSes as well. (Even other POSIX systems deal with GPIOs differently).

2) Kernel device are hardware independent; the software can run no matter whether the hardware is connected to an FTDI chip, a native bus or an MCP2210.

3) If the application is a kernel driver, it can only use kernel devices.

4) The required features (GPIO, SPI) might force the decision.

5) Using kernel devices is the True Linux Way (or so they say).

For many applications, hardware independence (item 2) is not that much of an issue, because devices are built as a unit containing the FTDI chip (arbitrary example). It becomes an issue, however, when using extensible hardware platofrorms (eg. mikroBUS native vs. USB).

Item 3 is relevant in those situation when there is already a kernel driver for a hardware module (eg. mrf24j40 for the BEE click / MOD-MRF24J40, or exploring the ENC28J60 driver).

Personally, I also appreciate a standardized interface in embedded systems development (developing lwIP drivers natively and then switching the SPI backend from Linux to native would be nice), but that's even more niche than the above.

Possible solutions

Additional considerations

Previous approaches

The topic of enhancing the FTDI driver pops up regularly; conculsions from the last iterations:

Except for Sascha Silbe's approach, there has been followup interaction, but I haven't found any second round of patches.

None of this has made it into mainline: the latest functional changes to the ftdi_sio driver, as of 4.3-rc3, date to 2011, when in f6c259a39, baud rate precision was enhanced cover new features of the FT232H chip. (Everything else looks like new USB IDs, bug fixes, kernel infrastructure adaptions or the introduction of a new chip without new features).

Other devices

For the MCP221, ther is an out-of-tree linux driver. The author faces a similar situation (there is a pre-existing more featureful userspace implementation), but focuses on performance and self-configuration in the rationale.

Incubator status

Unsure; I've been almost at git checkout -b ftdi-gpio, but asking around and further research have shown that the most promising approach is probably to see where (and why) exactly the previous approaches stopped or failed.

--chrysn 2015-09-21


This page is part of chrysn's public personal idea incubator; go up for its other entries, or read about the idea of having an idea incubator for more information on what this is.