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

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.


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