You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For use with the mikroe USB click adapter, it would be quite convenient to have GPIO support for the FT2232H BC pin family: as far as I understand, its BCBUS[1..4] pins should be usable as GPIO pins -- at least, that's how they are used on this particular board. Then, ftdi-embedded-hal could be directly used to develop embedded drivers from the comfort of a Linux environment.
If you don't get around to implementing it, I'd also appreciate any useful hints for when I try to implement this myself.
By the way: Thanks for providing this crate. It solves a long-standing dilemma I've been facing, which I can now resolve by just writing applications on embedded-hal, and run it on this crate, on an equivalent crate for other similar chips, or on kernel peripherals through linux-embedded-hal, as long as I'm not writing a kernel driver (which I am not) -- it implements the "Using a library to abstract away kernel-native or FTDI GPIO/SPI" route.
The text was updated successfully, but these errors were encountered:
chrysn
added a commit
to chrysn-pull-requests/ftdi-embedded-hal
that referenced
this issue
Apr 25, 2024
For use with the mikroe USB click adapter, it would be quite convenient to have GPIO support for the FT2232H BC pin family: as far as I understand, its BCBUS[1..4] pins should be usable as GPIO pins -- at least, that's how they are used on this particular board. Then, ftdi-embedded-hal could be directly used to develop embedded drivers from the comfort of a Linux environment.
If you don't get around to implementing it, I'd also appreciate any useful hints for when I try to implement this myself.
By the way: Thanks for providing this crate. It solves a long-standing dilemma I've been facing, which I can now resolve by just writing applications on embedded-hal, and run it on this crate, on an equivalent crate for other similar chips, or on kernel peripherals through linux-embedded-hal, as long as I'm not writing a kernel driver (which I am not) -- it implements the "Using a library to abstract away kernel-native or FTDI GPIO/SPI" route.
The text was updated successfully, but these errors were encountered: