Rust-native HackRf Support

[TroyNeubauer]

Adds support for HackRF via a rust native driver powered by nusb.

• Rx works. Was able to run the FM demod example on android!
• TX is mostly implemented but untested

Closes #9

[TroyNeubauer]

I am also working on a bladerf driver. This one is complicated enough that rewriting the c code in rust with nusb is impractical, so I plan on calling into libbladerf (no web support 😢 ).

What are the blocking / threading assumptions of RxStreamer? For this PR I assumed this was a blocking interface and used futures_lite::block_on to bridge the gap to async nusb.

For the blade, this is a bit more complicated since libbladerf wraps libusb with their own interface: https://libusb.sourceforge.io/api-1.0/group__libusb__poll.html#ga6deff4c7d3a6c04bb9ec9fd259b48933, so I want to know a little more so I can plan out how to do this

[bastibl]

Thanks for the PR. That's absolutely awesome. I'll also work with Android in the next weeks and look forward to trying this on Android.

Regarding the seify-hackrfone crate: would you prefer to have that in-tree or as a separate crate? I don't have strong preferences. You could maintain this separately and just make a PR for seify, when a new version is released? What do you think?

Also, in order to make a new seify release, seify-hackrfone has to be on crates.io. It would probably be the cleanest solution, if you maintain it as a separate crate and own the crate on crates.io. That means you can make new release and seify just tracks them.

(To release the crate, you'd also have to add a version to the nusb dependency, but you'll figure that out when trying to publish.)

Regarding the API, at the moment it is regarded as blocking. In FutureSDR, I mark the seify blocks as blocking, which makes sure that they are spawned in a separate thread. In the long run seify should have an additional async API, but until this was not really necessary. So what you were doing now, sounds reasonable to me.

I have some more technical comments that I'll inline.

[bastibl]

I get some errors, when I try to run the examples. When I run the rx example that is part of the hackrf crate, I get:

**basti@thrang git:(hackrf*):~/src/seify/crates/hackrf-one-rs >> cargo run --example rx
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `/home/basti/.cargo/target/debug/examples/rx`
Board ID: Ok(2)
Version: Ok("2023.01.1")
Device version: UsbVersion(1, 0, 7)
Error: Failed to receive on hackrf

Caused by:
    0: transfer
    1: endpoint STALL condition**

When I try to run it with the seify example, I get:

basti@thrang git:(hackrf*):~/src/seify >> cargo run --example  probe --features=hackrfone
   Compiling seify v0.12.0 (/home/basti/src/seify)
error[E0433]: failed to resolve: use of undeclared crate or module `info`
  --> src/impls/hackrfone.rs:63:17
   |
63 | ...   info::warn!("HackRfOne::open received invalid args: bus_number: {bus_number:?}, ...
   |       ^^^^ use of undeclared crate or module `info`

[bastibl]

Ideally, this should not become a dependency of the main crate.

[TroyNeubauer]

Removed

[bastibl]

To publish to crates.io, this will need a version.

[TroyNeubauer]

Sounds good, waiting on a new version from nusb: kevinmehall/nusb#84, then will publish and update here

[TroyNeubauer]

Splitting it into a separate github repo makes sense to me. Its now up at: https://github.com/MerchGuardian/seify-hackrfone, and I added a git submodule here.

I fixed the examples. I had to fix two funny issues:

1. I accidentally had sample_rate_div set to 0, which caused the stall since the device had no idea what to do lol.
2. Using claim_interface instead of detach_and_claim_interface would result in spurious Device busy errors on linux (worked fine without on MacOS)

I can now run both seify-hackrfone examples as well as rx_generic and rx_threaded!

[bastibl]

Works for me too. Thank you! I'll merge and just revert the default features to keep soapy as the default.

[bastibl]

I just tried to make a new Seify release, but that requires that your crate is published. Could you please do a cargo publish?

[TroyNeubauer]

Just published 0.1.0!
I disabled wrapping file descriptors for now while we wait on a new version of nusb: kevinmehall/nusb#84
Once that is released, we can re-enable in seify-hackrfone, release, and bump in here

[TroyNeubauer]

Made PR to bump here: #11. This also removes the features = ["hackrfone"] that I left by mistake