Conversation
|
Over the last week I've spent quite a few hours reading through the atmega datasheet and working on implementing this PR. In the process, I've made a few design changes; in brief:
|
|
Y'know what. I think I published this PR prematurely; I'll mark it as a draft. At work I'm so used to the design being the hard part; when I work on something difficult, I'm now in the habit of asking for feedback early in order to avoid having to rewrite the whole thing from scratch multiple times. It turns out that doesn't really apply here because the design isn't the hard part; the vast majority of the difficulty is grokking how everything works 😅 |
Fixes Rahix#40. When using `usb-device`, there are three main components to be aware of: * For `avr-hal`, the main thing we care about is `UsbBus`. This trait is a hardware abstraction layer for the actual USB hardware. We implement this trait in `mcu/atmega-hal/src/usb.rs`. * The `UsbClass` trait is used to implement support for each different type of USB device (e.g. speaker, keyboard, or serial port). These implementations are portable, so we can just use existing implementations from other crates. For `micro-usb-serial.rs`, we create a serial port using `usbd-serial`'s implementation of `UsbClass`. `usbd-serial` was chosen simply because it is the only serial class implementation that is mentioned in `usb-device`'s readme file. * `UsbDevice` is used by our users (and our example code) to actually configure the USB device. Basically, to create `UsbDevice` the user just needs to combine our `UsbBus` implementation with the list of `UsbClass`es that they want to use.
|
Status update: I got the happy path working last week, and I'm currently in the middle of cleaning up the code. |
1 participant
I've started working on USB support for the Arduino Micro (#40). There's still a lot of work left to do, but I'd like to get your feedback on the big-picture design stuff before I get too far into the implementation @Rahix.
I've got a bunch of TODOs with design questions in the PR itself, but there are a couple of other things that I wanted to ask about as well:
I've created a newusb-supportfeature in botharduino-halandmcu/atmega-hal; since I'm only testingarduino-micro, I'm thinking that it's better to have the new USB functionality disabled by default everywhere else. Is this the right call? Or is it better to remove the feature flag(s) and have the functionality always enabled inatmega-hal?When I make changes to this PR would you like me to squash the new changes with the previous version, or is it easier for you if I keep the commits separate until we're almost ready to merge?