[Bug 1001024] New: 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

           Summary: STM32 USB driver and proposed USB API change
           Product: eCos
           Version: 3.0
          Platform: stm32e_eval (ST STM3210E EVAL board)
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: USB driver
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: chris@zynaptic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=963)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=963)
STM32 USB slave driver package

Attached is the STM32 USB driver which has been developed and tested against
the 3.0 release.  It has had extensive testing with a proprietary USB class
driver, but there are issues with using it in conjunction with the standard
eCos class drivers which could best be fixed by an enhancement to the USB slave
API.

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:

// 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.  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.

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