May need a way to skip SetAddress response on nRF52840

[wez]

Reading up ready to take a stab at implementing for this platform and saw this:

Note: The USBD peripheral handles the SetAddress transfer by itself. As a consequence, the software shall not process this command other than updating its state machine (see Device state diagram), nor initiate a status stage. If necessary, the address assigned by the host can be read out from the USBADDR register after the command has been processed.

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52840.ps/usbd.html?cp=2_0_0_5_34_8#concept_usb_ctrl_ep

I haven't written any code for this yet, but wanted to highlight this to get you thinking about it. Seems simultaneously convenient and annoying :)

I think we need a way to skip sending the response to the SetAddress packet. I don't know if the bus implementation has enough context to know the overall state and filter it out of the appropriate write call.

[mvirkkunen]

I was sort of expecting some device to handle some or all of the control transfer state machine in hardware. I think the proper way of handling this would be to factor that part out of UsbDevice into a helper object that UsbBus implementations can use (possibly with some modifications), and UsbDevice would only see the full transactions. I wonder how much of the control transfers other chips handle in hardware?

In this specific case it would probably be possible for the UsbBus implementation to detect that specific SETUP packet (it starts with a specific byte sequence) and then just pretend it didn't receive anything.

Edit: Hmm, although then UsbDevice would never know it's been addressed... the UsbBus would probably indeed have to keep track of some "ignore next write" flag which just seems hacky. Another way would be to add "platform specific quirks" settings to the UsbBus that UsbDevice could read.

[wez]

Probably the lowest friction short term solution is to add a function to the UsbBus trait with a default implementation:

   /// override this to return true if your implementation takes
   /// care of automatically responding to the SetAddress control from the host.
   fn hardware_handles_set_address_response(&self) {
       false
   }

then we can override this for this specific device. The usb device would call that function prior to processing the response in the relevant section of its state processing.

I don't know how many different quirks will be needed in the long run; if there are a lot then this might start to feel unwieldy but certainly for now it doesn't seem like it would be overly burdensome.

If that doesn't sound terrible to you, I'd be happy to try implementing that and putting up a pull request for the changes to this crate?

[mvirkkunen]

I think that's an OK solution for now - at least until somebody finds a device that has even more control transter quirks (one that I can think of is the Linux USB Gadget API - which is a completely different beast from microcontrollers, but I'm not sure if it should be ruled out completely).

It's probably enough to check for the quirk in handle_control_setup and return early - however if that sets the device state to Addressed it theoretically does it at a different stage from other devices. I'm not sure if that actually makes a difference though, because end-users shouldn't really be concerned with that state anyways.

[mvirkkunen]

There's a "quirk" const for something similar to this, so if this is still a thing, then a quirk const for skipping the entire response can be added when writing the relevant driver.