Re: STM32 USB support

[Frank Pagliughi <fpagliughi@mindspring.com>]

Chris Holgate wrote:
> 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!
>
>   
Yeah, the USB subsystem for eCos was written at a time when USB chips 
were quite rigid - endpoints with fixed sizes and functions. Now, most 
chips are more flexible than not, with generic endpoints and 
configurable memory allocation. So the existing eCos infrastructure is 
showing it's age.  So each new driver is hitting this same problem and 
trying to solve it in a new and different way.

A search of this mailing list and 'ecos-devel' will show a couple 
different complaints and suggestions that I and a few other people made 
a while back. I haven't used eCos all year, but am close to jumping back 
in for a bit, and would need to refresh my own memory with the details.

IIRC, at the time I had fairly convinced myself that what was needed was 
an entirely new USB subsystem that would:
- make it much easier to work with the flexible new chips
- handle much more of the device enumeration
- provide a very specific callbacks structure (like read/write an 
endpoint, respond to a bus reset, set the chips' address, etc)
- handle more of the buffering

In general, make it much easier to knock out USB drivers.

Maybe now it's time to start considering this in earnest?  Count me in.

Frank