This is the mail archive of the
mailing list for the eCos project.
Re: STM32 USB support
My main bugbear is the way in which class drivers currently accessIn 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.
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.
Agreed that this is actually more realistic.
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.
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
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.