UsbBus should take ownership of the D+ and D- pins.

[agausmann]

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.

[agausmann]

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.