Andrew Lunn wrote:
The AT91 USB driver has something similar to this. It can configure
the endpoints by looking at the USB descriptors.
I've just had a quick look back at the AT91, and while there's a certain
degree of flexibility there, it's still limited to the particular
configuration decreed by Atmel as far as buffer sizes, endpoint number
etc. is concerned.
With the STM32, ST seem to have taken the opposite approach - you have a
chunk of buffer memory and 8 endpoint state machines. Beyond that
you've got complete flexibility to choose how many endpoints you want -
input or output (or bidirectional[1] if you don't need double
buffering). You can also choose an arbitrary set of logical (ie visible
to the host) endpoint IDs and buffer sizes.
Given this flexibility, it seemed to be a bit of a waste to define a
fixed standard configuration similar to the Atmel device. Instead, when
the host sends the configuration select to the STM32 EP0 I intercept it
and scan the descriptor data structures for a corresponding
configuration. Using the descriptor configuration I can then set up the
buffer memory and endpoint state machines 'on the fly' to correspond
directly to the configuration requested by the host.
All this gives the application specific driver layered on top of the
STM32 driver complete freedom to specify one or more supported endpoint
configurations.
I don't remember how it works with respect to devtab entries.
Since the Atmel and other USB drivers have fixed endpoint
configurations, it's reasonable to statically allocate and configure the
devtab entries during the device init sequence. Unfortunately, this has
obvious problems when using the dynamic configuration scheme described
above.
Chris.
[1] I used the bidirectional mode for the control endpoint, but
otherwise decided it was more bother than it was worth!