This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: STM32 USB support

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

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.


[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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]