USB host support (experimental) #660
Conversation
This example blinks the LEDs of an attached USB keyboard. It does not
work with any keyboard yet, but it does work with some.
Usage:
let host = hal::usb::BlockingHost::new(
usbctrl_reg,
usbctrl_dpram,
usb_clock,
&mut resets
);
host.reset();
host.run();
Also make some changes to the bus interface
|
The failing check is caused by cargo-hack no longer being compatible to our MSRV. #666 is a possible fix. |
|
@nilclass I'm keen to help in whatever way I can 🙋♂️ I don't want to be too annoying but I will probably try to contact you on matrix also |
|
sorry, i was meant to provide some useful feedback here but haven't gotten around to it yet. i've been sidetracked trying to come up with a pio based driver that uses the same usbh trait. fwiw there are no tricky conflicts to resolve in rebasing this PR onto v0.9.1 . there's no rush to do so but i just thought it's worth knowing about. i think it makes sense to bring the example into this repo if at all possible. it will make it easier for others to participate in this PR and i think it's somewhat inevitable anyways because users will want an example too. |
|
ac2da05c12814a82b3b124f86f38d75c2589078d it's maybe a bit unfortunate i had to remove console output from the example (didn't want the defmt dependency) but making the onboard led blink is probably enough to determine whether or not the example is working. |
|
@tommy-gilligan thanks, I've picked the commit over here. Alternatively the example could also go into the rp-pico examples in the rp-hal-boards repo, some of those already depend on defmt, so in that case we could keep the logging. |
Update 2023-08-06
usbhis in a state where it's possible to write simple drivers:Original description
As mentioned on matrix, I've been looking into USB host support.
While it is by no means finished or even usable, I want to share my progress and findings.
My initial draft (now removed from this branch) can be found in this commit: 0cf375f
It works to the point where a keyboard can be attached and the LEDs can be controlled.
Since then I've tried to translate that draft into a more reasonable, interrupt driven implementation.
It's tricky, since I'm not certain yet which parts of the USB host stack should go into the HAL and which parts should go into a more generic package.
I'm thinking that embedded USB host support in general could mirror the way things work on the device side:
For devices there is the
usb-devicepackage, which provides the glue between different USB functions (usbd-serial, usbd-audio, ...) on one side and the specific USB device hardware on the other side.For hosts, a similar package would provide the glue between function drivers and the specific USB host hardware.
There is some prior art in that direction: the aptly named usb-host crate defines such an interface, although it is in a very early state.
For now I decided not to target that crate though, but instead do my own experiments here: usbh.
One difference between the two is that the
usb-hostAPI for control transfers is blocking, while my attempt is using only interrupts and callbacks on the driver side to.In my version also the state machine for control transfers would not be part of the HAL, but part of the common usbh package. That means the HAL only provides methods to issue
SETUP,DATA INandDATA OUTtransactions on the control endpoint. The usbh package then calls these methods as needed for a control in / control out transfer.How to try it out?
This takes a couple of pieces:
usbhpackage https://github.com/nilclass/usbh (it's not published yet, so you'll have to use it from git or from a local clone)You'll likely have to adjust some paths in various Cargo.toml files to get this to work. The example also requires
rp2040-monotonic, I'm using a local copy of that as well, with the Cargo.toml adjusted so thatrp2040-halandrp2040-monotonicboth depend on the same localrp2040-paccopy.What is working, what is missing?
A bunch of things are working, but nothing completely useful yet 😛
Currently I am trying to get interrupt endpoints to work, but it is a bit tricky.
Besides defining a driver interface, another big thing that would be very useful is hub support.
This is a big topic, and I am not sure I can get it to a satisfactory state on my own, so if somebody wants to collaborate, please reply here or ping me on matrix :)