Issue with Port D on an FT4232H: failed to fill whole buffer

[TomDeRybel]

First of all, thank you for this very useful crate!

I've encountered a problem: while I can work with the left-over GPIO pins on Port A (I²C) and B (SPI) just fine, using the pins on Port D (GPIO) fails, and a Err Result occurs. (Port C is used as an UART.)

Specifically: writing the pins as output works, but reading them as input fails.

I have written a minimal test program that triggers the problem, attached.

• FTDI chip: FT4232H
• Ubuntu 22.04.4 LTS
• libftdi1: 1.5-5build3

Any and all advice would be greatly appreciated!

ftdi_test_port_d.zip

[TomDeRybel]

I've done some further diagnostics:

• I first validated my test hardware using a bit of Python and pyftdi. It tested good.
• Writing to Port C an D did not work using ftdi-embedded-hal, even if there were no errors. Rarely it would actually work, which was rather confusing...

After some thinking and checking the data sheets, it seems that the actual problem is in the architecture of the FT4232H vs the other members of this family:

• The FT4232H only has an MPSSE on Ports A and B. --> These work properly with ftdi-embedded-hal.
• Ports C and D only support UART and bit-bang modes. --> These fail.

Digging through the code in ftdi-embedded-hal, it seems that no such distinction is made, and that all ports are treated as if they had an MPSSE.

To validate this, I extended the test program (attached) to operate directly on Port D, using ftdi-rs directly. This works correctly.

Concluding: it seems to me that the solution to fully support the FT4232H is to include additional handling for non-MPSSE operation, in addition to MPSSE operation. (I think this would also extend the application of ftdi-embedded-hal to other chips in the FTDI range, as a bonus.) It would mean that only GPIO would be supported in the context of this crate. (Assuming that a software-based, bit-bang implementation of SPI and I²C is out-of-scope.)

ftdi_test_port_d.zip