Arca Noae USB Stack Requirements and Limitations
The Arca Noae USB stack has been written to be as compatible as possible with existing class drivers. Recent changes in modern USB hardware makes maintaining complete compatibility impossible, particularly with XHCI connected devices. However, a class driver should not be concerned about which type of Host Controller a device is connected to. The Arca Noae USB stack implementation handles Host Controller differences so that class drivers don’t need to. This wiki documents the requirements and limitations of the Arca Noae USB stack particularly where they might differ from older stacks. Following these guidelines will ensure that your class driver will work regardless of how the device is attached to the system.
The Arca Noae USB stack attempts to comply with the USB specifications as much as possible, and you can use applicable USB specifications for your device class as a guide to writing your class drivers. However, beware that when interfacing to the Arca Noae USB stack you are interfacing with an implementation, not a specification. Your driver must comply with the requirements of the implementation regardless of what any specification says.
Handling Stalled Endpoints
Class drivers must issue a Clear Stall to any stalled endpoint including endpoint zero using the USBD ClearStall function. The Arca Noae stack handles whatever needs to be done at the lower levels so that class drivers don’t need to worry about Host Controllers or low level connections.
Seting the Configuration
USBD sets the first configuration (configuration 1) when a new device is attached. Class drivers should only set a different configuration if they need a different configuration than what is already set. The current configuration can be determined by looking at bConfigurationValue in the DeviceInfo structure. Class drivers should set a new configuration only by calling the USBD Set Configuration function. The USBD Set Configuration function handles whatever needs to be done at the lower levels so that class drivers don’t need to worry about Host Controllers or low level connections. Sending a set configuration transaction directly to the device outside of the USBD Set Configuration function may have undefined and undesired results.
Class drivers should not use the bConfigurationValue for any purpose other than to determine which configuration is already set. Class drivers should never write to the bConfigurationValue entry in the DeviceInfo structure.
Setting the Interface
USBD sets interface 0 alt 0 when a new device is attached. If a class driver only needs to use interface 0 alt 0 and only the endpoints in that interface, then the class driver does not need to set an interface. If a class driver needs to use a different interface then the class driver will need to set that interface. A class driver may set the interface it wants even if it is already set.
Class drivers may not send transactions to endpoints that are not in the interface that has been set. Sending a transaction to any endpoint that has not been enabled by an appropriate set interface operation will return an error 18 (Endpoint not ready) from the AcceptIO function. Note that a set interface operation may not be successful. You must check status to ensure that the interface was set.
Set interface is additive only with regard to endpoints. This means that every set interface action adds/activates any new endpoints in that interface that have not already been activated. Setting a different interface that has fewer or different endpoints will not deactivate already activated endpoints. Setting a different interface that has the same endpoints, but with different attributes will update the endpoint attributes. Indiscriminately enabling multiple interfaces with multiple different endpoints can result in bandwidth problems.
This entry last updated: by