-
Notifications
You must be signed in to change notification settings - Fork 97
Provide asynchronous interface to rusb in rusb-async #155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Very interesting! I have one question: how can zerocopy be achieved with this? As I looked at the code, the caller of |
After looking a bit at the internal representation of From what I read the Pin should not be necessary for a boxed slice either, so that greatly simplifies things too. |
|
I'd like to carry out test for this PR. Just wondering what is the test device used. Usually I will use the bulk loopback (eg: using Cypress EZUSB FX3 or FX2LP) to test libusb related library. |
|
Example run. |
|
I tried to modified the examples to match Cypress BulkSrcSink example. Now read_device works but not read_async. |
I am using a Cypress EZUSB FX3 myself too. In fact, I am using the code of this PR to implement the firmware upload (control packets) as well as bulk packets afterwards (not loopback, though).
Try running with Because it can't handle hexadecimal input, it ends up failing on this line:
This is failing on the same problem. |
That is great to know. It is one of the best tool to test libusb related projects. I use it to test libusb, libusb-win32, libusbK, libusbdotnet and pyusb. Other than the firmware upload (control transfer), it will be great to provide example for bulk_loop and bulk_src_sink. Basically Cypress have three main applications (Control Center, BulkLoop and Streamer) which kind of for the firmware upload, Bulk_loop FW and Bulk_Src_Sink and Iso_Src_Sink FW examples. Under Linux and macOS, I actually use libusb fxload example for the FW downloading. If you have rusb based example, that will be great as well. |
I think this would be another PR, since the synchronous version of rusb is also lacking these. The example I am using in this PR is simply based off the examples in the synchronous version of rusb. However, having these examples would be good for getting started and testing.
Yes, I am just using an existing device that integrates the Cypress EZUSB FX3, and the firmware blobs don't use a format that is compatible with fxload. I have a library that is based on this PR to handle the firmware download, upload and execution. I was hoping to get this merged first, but if not, I can probably publish the library anyway. |
Thanks It goes a bit further. |
I see. Maybe simple examples like read_async is also good. Probably two more simple examples will help as well, like write_async and read_write_async. There are two examples in the rusb-async branch: read_async and read_write_async.
I understand. It is indeed nice to have a rust based tool for the EZUSB FX3. |
|
I can vouch for this PR by @StephanvanSchaik. I've implemented the async APIs from this PR in one of my projects, and they work flawlessly. While the initial setup and learning curve required some time, with proper documentation and examples, this PR could be incredibly valuable. Kudos to @StephanvanSchaik! 🎉 Machine: Macbook pro M1, Sonoma 14.5 |
This is a continuation of PR #153 with the feedback provided there integrated. This PR mostly draws inspiration from: #62 (comment) and PR #143.
Contextrunning an event handling thread in the background for convenience. In addition it implements theUsbContexttrait, such that it can be used everywhererusb::Contextcan be used. This way the user can simply userusb_async::Contextinstead ofrusb::Contextfor asynchronous I/O without having to take care of the event handling.Transfer::poll()shouldn't be callinghandle_events(), that part has been removed as it is being handled by the background thread now.InnerTransferandTransferlike in Support libusb async api #62 (comment).NonNull<libusb_transfer>and implementsSendsuch it can be sent across threads, since it is effectively guarded by anArc<Mutex<T>>.CancellationTokenthat can be constructed from Transfer, such that the transfer can be cancelled from other tasks.This integrates nicely with tokio, but should be agnostic of the run-time used since it just relies on the std crate for futures, i.e. any asynchronous executor should work.
I have tried this with a device that supports USB control packets and it seems to work nicely. However, I don't have any experience with isochronous packets, so this PR does not implement that part.