[Bug 1001024] STM32 USB driver and proposed USB API change

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001024

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ecos-patches@ecos.sourcewar
                   |                            |e.org, john@dallaway.org.uk
          Component|USB driver                  |Patches and contributions

--- Comment #1 from John Dallaway <john@dallaway.org.uk> 2010-08-26 10:13:50 BST ---
(In reply to comment #0)

Chris, thank you for the contribution. In the absence of a complete
implementation, can you clarify how you envisage the new endpoint retrieval
scheme to work please?

At present, the Rx and Tx endpoint structures to be used by a function device
package are specified using CDL options in the function device package (eg
CYGDAT_IO_USB_SLAVE_SERIAL_EP0). The relationship between endpoints and
function devices is fixed at build time.

> Instead of using static endpoint references as per existing USB slave drivers,
> STM32 USB endpoints may only be accessed after USB device configuration via
> the two following 'getter' functions:

Is specifying the endpoint structures at build time simply not possible? Or are
you proposing the new scheme to allow greater flexibility with more modern
hardware? What additional flexibility is achieved?

> // Get a handle on the specified transmit (in) endpoint.  Calling this
> // function with a given logical endpoint ID will return the transmit
> // endpoint data structure associated with that endpoint ID.
> extern usbs_tx_endpoint* cyg_usbs_cortexm_stm32_tx_endpoint
     (cyg_uint32 ep_id);
> 
> // Get a handle on the specified receive (out) endpoint.  Calling this
> // function with a given logical endpoint ID will return the receive
> // endpoint data structure associated with that endpoint ID.
> extern usbs_rx_endpoint* cyg_usbs_cortexm_stm32_rx_endpoint
     (cyg_uint32 ep_id);
> 
> This approach allows the STM32 USB driver to support multiple USB
> configurations if required.

Can you explain what you mean by "multiple configurations" here?

> However, the existing standard eCos class drivers assume the use of static
> endpoint definitions which will require changes to work against this driver.
> 
> IMHO, the best way to resolve this would be to introduce a new pair of
> functions to the standard USB slave API, which are generic variants of the
> ones given above for the STM32.  This would be easy to add to existing
> drivers and would provide a consistent way of accessing old-style fixed
> endpoint USB hardware and more modern configurable USB hardware.  In addition
> they will hide the native types of the endpoint data structures which
> currently 'leak' from hardware specific slave drivers into class driver
> implementations.

If we provide the following functions in the generic USB slave API:

  usbs_rx_endpoint* cyg_usbs_rx_endpoint (cyg_uint32 ep_id);
  usbs_rx_endpoint* cyg_usbs_tx_endpoint (cyg_uint32 ep_id);

how do you propose that the implementation of these functions looks up the
endpoint structure? Another parameter to specify the hardware device driver
lookup function?

How would the user of the USB function driver continue to specify the endpoints
using CDL options?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.