Support more targets.

[newAM]

FTDI provides support for many more targets than currently available via this crate.

https://www.ftdichip.com/Drivers/D2XX.htm

• Various mips
• aarch64-apple-darwin
• x86_64-apple-darwin static
• x86_64-apple-darwin dynamic
• aarch64-unknown-linux-gnu
• aarch64-unknown-linux-musl
• arm-unknown-linux-gnueabihf
• arm-unknown-linux-musleabihf
• armv7-unknown-linux-gnueabihf
• armv7-unknown-linux-musleabihf
• i686-pc-windows-msvc
• i686-unknown-linux-gnu
• i686-unknown-linux-musl

[Grinkers]

I'm not familiar enough with github workflows to edit. But I've tested, without issue using with --features=bindgen from x86_64 toolchains, with "--target"s:

i686-pc-windows-msvc
x86_64-pc-windows-msvc
i686-unknown-linux-gnu
x86_64-unknown-linux-gnu

https://github.com/newAM/libftd2xx-ffi-rs/blob/master/.github/workflows/ci.yml#L19
I believe at least libc6-dev-i386 will be needed.

Thank you for this project, I've learned a lot about bindgen while oxidizing a c code base with an ftdi dependency.

[newAM]

Thanks for figuring out the x86 support!

I added all of these targets to CI, the ARM targets have been on my TODO list for a while as well (raspberry pi support):

• aarch64-unknown-linux-gnu
• aarch64-unknown-linux-musl
• arm-unknown-linux-gnueabihf
• arm-unknown-linux-musleabihf
• armv7-unknown-linux-gnueabihf
• armv7-unknown-linux-musleabihf
• i686-pc-windows-msvc
• i686-unknown-linux-gnu
• i686-unknown-linux-musl

Everything seems ok, but I do not know the ins and outs of supporting 32-bit targets.

Thank you for this project, I've learned a lot about bindgen while oxidizing a c code base with an ftdi dependency.

Glad it could help!

[Grinkers]

https://github.com/Grinkers/libftd2xx-ffi-rs/runs/1824299683?check_suite_focus=true
I added the examples to be compiled so it would be more obvious if the static/dynamic linking was blowing up (just because the library compiles doesn't mean it has everything for linking). Instead, arm blew up, at least not without more dependencies and linker = x

I've never cross compiled rust for arm, but once rust or libraries mature, I can see it being highly in demand with FTDI products.

[EncinitasMechanic]

Hello,

I have this library working on x86_64-apple-darwin, if you are interested. I also have libftdi2xx-rs working, which in turn allows ftdi2xx-embedded-hal to work. I have tested it on an M1 mac mini using the adafruit ft232h breakout and i2c, but that is it. Right now it seems that FTDI doesn't have an ARM library for macos, so it has to be cross compiled for x86_64. I feel the obligation to point out that I am not a programmer , and this is my first try at contributing to a project, so I hope i'm doing this right.

The code is here https://github.com/EncinitasMechanic.

Thank you for this project, it is the foundation to a lot of the enjoyment of my hobby.

[newAM]

That's great!

I took a look at the repositories, but they seem to be even with the current main branch, are you able to push your local changes (git push)?

[EncinitasMechanic]

ok, try now! Thanks for checking it out!

[newAM]

The changes look good to me!

Do you want to open a pull-request for the changes or should I just port them over?

There is unfortunately no M1 mac support in github actions, but we should be able to add some basic build checks running on x86_64 darwin.

[EncinitasMechanic]

The pull requests are up. Thanks for helping me through this, I am happy to be able to contribute!

[Grinkers]

I noticed x86 linux was removed? I'm guessing it was because FTDI isn't supplying a build yet for 1.4.24? I use this target, but don't use the new devices supported since 1.4.24.

For the time being, I've added 1.4.22 back here
https://github.com/Grinkers/libftd2xx-ffi-rs/tree/linux_x86

I've contacted FTDI to see what their status/plans are for this target.

[newAM]

Hopefully it works out. I am guessing they want to reduce their maintenance costs and are waiting to see if any clients notice the missing x86 linux builds.

[Grinkers]

You're right, it seems like they were waiting to see if anybody would contact them. I did and I got a build for 1.4.24 and it seems fine (although they said it wasn't fully tested). I don't have any of their new devices to test against those, but I did tell them about my use case and they'll see about continuing support going forward.

I got permission to publish this here.

If they do decide to not support it, going forward maybe we can write some documentation for the latest version this crate includes, instead of completely removing it?

[newAM]

Excellent! Merged.

For future updates we will have to ask them for the Linux builds then?

If they do decide to not support it, going forward maybe we can write some documentation for the latest version this crate includes, instead of completely removing it?

That works for me, need to get around to closing #19 at some point.