This is the mail archive of the
mailing list for the eCos project.
Re: STM32 USB support
- From: Frank Pagliughi <fpagliughi at mindspring dot com>
- To: Chris Holgate <chris at zynaptic dot com>
- Cc: Andrew Lunn <andrew at lunn dot ch>, Simon Kallweit <simon dot kallweit at intefo dot ch>, ecos-devel at sourceware dot org
- Date: Tue, 19 May 2009 23:08:32 -0400
- Subject: Re: STM32 USB support
- References: <4A11CAAA.firstname.lastname@example.org> <4A11D861.email@example.com> <4A11E5DF.firstname.lastname@example.org> <4A129C34.email@example.com> <20090519120004.GI20046@lunn.ch> <4A12D3CC.firstname.lastname@example.org>
Chris Holgate wrote:
Andrew Lunn wrote: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.
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 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
 I used the bidirectional mode for the control endpoint, but
otherwise decided it was more bother than it was worth!
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.