public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Chris Holgate <chris@zynaptic.com>
To: Frank Pagliughi <fpagliughi@mindspring.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	  Simon Kallweit <simon.kallweit@intefo.ch>,
	 ecos-devel@sourceware.org
Subject: Re: STM32 USB support
Date: Wed, 20 May 2009 16:06:00 -0000	[thread overview]
Message-ID: <4A142A62.7040202@zynaptic.com> (raw)
In-Reply-To: <4A1419A0.3010806@mindspring.com>

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[1].  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!

Chris.

[1] 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.

  reply	other threads:[~2009-05-20 16:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4A11CAAA.8040900@intefo.ch>
     [not found] ` <4A11D861.8090206@zynaptic.com>
     [not found]   ` <4A11E5DF.2000403@intefo.ch>
2009-05-19 11:47     ` Chris Holgate
2009-05-19 12:00       ` Andrew Lunn
2009-05-19 15:17         ` Simon Kallweit
2009-05-19 16:28           ` Chris Holgate
2009-05-20  8:20             ` Simon Kallweit
2009-05-19 15:44         ` Chris Holgate
2009-05-20  3:09           ` Frank Pagliughi
2009-05-20 10:19             ` Chris Holgate
2009-05-20 14:54               ` Frank Pagliughi
2009-05-20 16:06                 ` Chris Holgate [this message]
2009-05-20 22:31                   ` Frank Pagliughi
2009-05-19 13:33       ` John Dallaway
2009-05-20 21:22         ` Chris Holgate
2009-05-21  7:27           ` John Dallaway
2009-05-31 15:01             ` Chris Holgate
2009-05-31 15:46               ` John Dallaway

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A142A62.7040202@zynaptic.com \
    --to=chris@zynaptic.com \
    --cc=andrew@lunn.ch \
    --cc=ecos-devel@sourceware.org \
    --cc=fpagliughi@mindspring.com \
    --cc=simon.kallweit@intefo.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).