Re: STM32 USB support

[Frank Pagliughi <fpagliughi@mindspring.com>]

> 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.
>   
In addition, it's difficult to specify endpoints which can be used for 
either direction. I believe several drivers specify that all their 
generic endpoints are "rx endpoints" and if you want to use one to 
transmit data you must overlay a "tx endpoint" on top of it. That's not 
a big problem, but it's confusing. In addition, then rx/tx data 
structures lack a few fields to completely (easily) handle a generic 
endpoint, like the endpoint number, and maybe some intermediate buffer 
pointers to handle a single transfer. So each driver has to add this 
functionality in one way or another.


>> 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.
>   
Agreed that this is actually more realistic.

And, keep in mind, there are a few additional tricky issues to which the 
driver writer is exposed, which can be delegated out to a common 
package. I don't think any of the drivers properly deal with the state 
change callback - most appear to emit a "current/new state" enumerated 
value (USBS_STATE_xxx) rather than a state change value 
(USBS_STATE_CHANGE_xxx).

 And the way in which transfers for bulk and interrupt endpoints need to 
be ended - in regard to short and zero packets - can get a little messy, 
but is common to all devices. With a more complete, common endpoint 
structure, this decision making could be handed off to a single, common 
set of routines.

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

True, though I worry that even the existing drivers have a number of 
bugs and deficiencies, especially since they're left to handle some 
common control messages on their own. And, since each new driver is 
written using an old one as a template, the bugs are perpetuated. But no 
one - my self included - wants to fix the old drivers since they're 
mostly for chips that are obsolete or no longer viable.

Frank