Re: STM32 USB support

[Chris Holgate <chris at zynaptic dot com>]

Frank Pagliughi 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.

My thoughts are that the current infrastructure is still pretty usable
and that the main limitations are the use of static devtab entries
(which are optional anyway) and the drivers themselves.  More
specifically, there isn't a good example of how to use the
infrastructure to write drivers for these more configurable USB devices.

My main bugbear is the way in which class drivers currently access
device endpoints.  At the moment you need to know which low level driver
is in use and the completely arbitrary names of the exported static
endpoint data structures.  This should really be hidden behind a generic
API which is defined by usbs.h.  I think that this would be an easy
change and would require mimimal additions to the existing drivers.
Existing drivers could add the endpoint 'getter' functions and still
export their static endpoint data structures for legacy class drivers.

> 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

There's quite a bit of code in the STM32 driver which addresses these
issues within the existing framework.  Maybe the thing to do would be to
factor it out into a device driver utility library which can be used
alongside the existing framework.

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

While the existing callback setup may not be the easiest to use, it does
provide all the required information.  As for buffering, this is
something which I think should be a matter for the class driver writer.
 Again, this could all be made easier by better documentation and a
possible class driver utility library.

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

It's never going to be really easy though!

Chris.