This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: Updated version of the STM32 USB driver.
- From: Sunder819 <sunder dot ganesan at lnties dot com>
- To: ecos-devel at ecos dot sourceware dot org
- Date: Tue, 17 May 2011 04:16:24 -0700 (PDT)
- Subject: Re: Updated version of the STM32 USB driver.
- References: <4A23A4B1.9020805@zynaptic.com> <23867737.post@talk.nabble.com> <4A2CE4C2.9010108@zynaptic.com> <23941242.post@talk.nabble.com>
Hi Gaurang,
It may be long break,
I am still facing the same problem "undefined reference to
usb_at91_ep1".....
What did you do to overcome this compilation error?
Request to reply me.
Thanks & Regards,
Sunder
GaurangT wrote:
>
> Hi Chris,
> What is CDL settings for the serial class driver for stm32?
> When I am replacing this function
> extern usbs_tx_endpoint* cyg_usbs_cortexm_stm32_tx_endpoint (1)
> extern usbs_tx_endpoint* cyg_usbs_cortexm_stm32_rx_endpoint (1)
>
> instead of
>
> extern usbs_tx_endpoint CYGDAT_IO_USB_SLAVE_SERIAL_TX_EP;
> extern usbs_rx_endpoint CYGDAT_IO_USB_SLAVE_SERIAL_RX_EP;
>
>
> and disable this structure
>
> usbs_serial usbs_ser0 = {
> tx_ep: TX_EP,
> rx_ep: RX_EP,
> tx_result: 0,
> rx_result: 0,
> };
> I got error in build library using configtool.
>
>
> Chris Holgate wrote:
>>
>> GaurangT wrote:
>>> Hi Chris,
>>>
>>> I tried your latest STM32 driver and was successfully add USB
>>> slave-side serial drivers package.
>>> when I select enable control the endpoint 0 and enable all usb slave
>>> serial
>>> support in configtool.
>>> What is defined data structure in USB IN and OUT endpoint structure in
>>> stm32
>>> evel board.
>>
>> This was discussed a while ago here...
>>
>> http://ecos.sourceware.org/ml/ecos-devel/2009-05/msg00033.html
>>
>> In summary, while you can just use something like &usbs_at91_ep1 to get
>> a pointer to endpoint one of a driver with statically assigned fixed
>> endpoints, with the STM32 you need to use an 'endpoint getter' function
>> to return the pointer. The 'endpoint getter' functions only return
>> valid endpoint pointers once the USB device has been configured by the
>> host.
>>
>> So for OUT endpoint 1 it would be a case of replacing...
>>
>> &usbs_at91_ep1
>>
>> with...
>>
>> cyg_usbs_cortexm_stm32_rx_endpoint(1)
>>
>> This results in me having to use knarly code like the following in my
>> own class driver:
>>
>> #if (defined CYGPKG_DEVS_USB_AT91)
>> #include "cyg/io/usb/usbs_at91.h"
>> #define EP1_DATA_STRUCT &usbs_at91_ep1
>> #define EP1_INIT_FUNC usbs_at91_endpoint_init
>>
>> #elif (defined CYGPKG_DEVS_USB_CORTEXM_STM32)
>> #include "cyg/io/usb/usb_stm32.h"
>> #define EP1_DATA_STRUCT cyg_usbs_cortexm_stm32_rx_endpoint(1)
>> #define EP1_INIT_FUNC(_args_...) {}
>>
>> And then I can use something like:
>>
>> usbs_start_rx_buffer (EP1_DATA_STRUCT, cmd_buf, MAX_FRAME_SIZE,
>> completion_handler, 0);
>>
>> Unfortunately the CDL settings for the serial class driver currently
>> require you to specify static endpoint names, so it will not work out of
>> the box with the STM32 driver.
>>
>>> If I mention default data structure,I got compile error (like undefined
>>> reference to usbs_at91_ep1 and usbs_at91_ep2) in usb2serial test
>>> program.
>>
>> Hopefully the above information explains why this is and what you would
>> need to do to fix it. We are stuck with this approach of exposing the
>> low-level driver API for any drivers which are compatible with the
>> release 3.0 USB framework. However, it would be nice to clean this up
>> for future versions.
>>
>> Chris.
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Updated-version-of-the-STM32-USB-driver.-tp23812467p31636814.html
Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.