UsbBus should take ownership of the D+ and D- pins.
agausmann opened this issue · comments
Their default configuration allows them to function as the USB data pins, but it should still consume them to make sure they are configured correctly.
That might be out of scope for this crate. For example, stm32-usbd doesn't deal with pins at all, it only manages the USB peripheral. Managing pin states is left to the HAL crates. I think that would be the best approach here too.
In order to manage the pin states, this crate would have to depend on atmega-hal, which would lead to the opposite structure of the STM crates, where the HALs depend on stm32-usbd. If we later decide to create a USB API in atmega-hal, the two crates would become co-dependent, and the only way to resolve that is (a) merge atmega-hal and atmega-usbd or (b) refactor atmega-usbd to remove the HAL dependency (return it to what it is right now) and move the HAL-dependent features into the HAL.
I'll still keep this issue open. It's not a good idea to do it in atmega-usbd directly, but it's still possible to implement in other ways. For example, we could make a separate crate that depends on both atmega-usbd and atmega-hal that extends the HAL to provide pin management for USB pins. Or, it could be a fork of atmega-hal that depends on atmega-usbd, with the goal of eventually merging those new APIs upstream.