Add USB driver #135
Add USB driver #135
Conversation
Cargo.toml
Outdated
| @@ -91,7 +98,7 @@ doc = [] | |||
| rt = ["stm32f1/rt"] | |||
| stm32f100 = ["stm32f1/stm32f100", "device-selected"] | |||
| stm32f101 = ["stm32f1/stm32f101", "device-selected"] | |||
| stm32f103 = ["stm32f1/stm32f103", "device-selected"] | |||
| stm32f103 = ["stm32f1/stm32f103", "device-selected", "stm32-usbd"] | |||
There was a problem hiding this comment.
Shouldn't this rather be under the specific examples using it?
There was a problem hiding this comment.
I don't know how to make this convenient. Current solution is like "hal provides drivers for all the peripherals, so why not to enable USB". Maybe it's better to feature-gate USB support in order to reduce the dependency tree.
There was a problem hiding this comment.
Why can't we just put it in the required-features entries of the examples?
There was a problem hiding this comment.
Maybe this would work for stm32f1xx-hal, but here this stm32-usbd feature means that USB is guaranteed to work on this chip. If user provides this feature, they can possibly activate it for the chip with different configuration, which is not supported yet, or has a different register layout and the same peripheral name.
Maybe I should additionally feature-gate usb module for all the supported chips.
There was a problem hiding this comment.
Well, I'm not a big fan of restricting the user to "curated" configurations. Similar to the typically usable 128kB flash even on the "R8" versions, there are also projects which manage to use USB on lesser chips which are not supposed to have USB.
I'd rather say put in the documentation that we have USB support for the STM32F103 and if people experiment with other chips and get it to run, that's fine with me; if they fail and complain we can point them to the documentation.
In theory USB should work on the F102 and F103 unmodified, F105 and F107 do even have OTG so I'm not sure what's needed to get it to work there. There're e.g. Altera USBblaster clones using a STM32F101.
There was a problem hiding this comment.
I'd rather think of them as of "proved" or "should work according to the datasheet" configurations. I believe that porting to other configurations is quite simple. Also user can just copy usb.rs to their project and fix it to comply with the project-specific peripheral. The same thing works for chips which are not supposed to have USB, but have it.
Both F105 and F107 need another driver, I need to finish and "convert" that driver first.
| // Pull the D+ pin down to send a RESET condition to the USB bus. | ||
| let mut usb_dp = gpioa.pa12.into_push_pull_output(&mut gpioa.crh); | ||
| usb_dp.set_low(); | ||
| delay(clocks.sysclk().0 / 100); |
There was a problem hiding this comment.
Do we need that? I've removed it from my keyboard, and it still work fine.
There was a problem hiding this comment.
This code is needed only for development. Without it host doesn't reset your device when you upload new firmware.
There was a problem hiding this comment.
Maybe that could be documented in the comment above.
|
Oops, forgot to update docs.rs feature list. Will fix soon. |
See also: stm32-rs/stm32-usbd#16