This is the mail archive of the
mailing list for the eCos project.
Re: STM32 USB support
Frank Pagliughi wrote:
>> 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.
> 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.
It does make a bit of a mockery of type safety, though. To the user, Tx
and Rx endpoints are fundamentally different things and it's good to try
and prevent Tx calls to Rx endpoints and vice versa. If the driver
writer feels they must use the same data structure for each, then this
should be hidden from the user.
With the STM32 driver, it is possible to have Tx and Rx endpoints with
the same logical endpoint ID but they will be implemented on different
physical endpoints. The user doesn't need to know this - they just
tell the tx or rx endpoint getter function the logical endpoint number
they want and the corresponding, correctly typed data structure is returned.
> 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.
Yeah - that would have saved me from a lot of pain!
 The distinction being that logical endpoints are the endpoint
numbers seen by the host and physical endpoints are the actual endpoint
state machines on the chip.