From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16744 invoked by alias); 8 Jun 2009 10:15:44 -0000 Received: (qmail 16732 invoked by uid 22791); 8 Jun 2009 10:15:43 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_91,SPF_PASS X-Spam-Check-By: sourceware.org Received: from alicia.2020media.com (HELO alicia.2020mail.com) (212.124.192.215) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Jun 2009 10:15:36 +0000 Received: from [212.124.199.38] (helo=[192.168.0.2]) by alicia.2020mail.com with esmtp (Exim 4.30; FreeBSD) id 1MDbt5-000FIH-6t; Mon, 08 Jun 2009 11:15:31 +0100 Message-ID: <4A2CE4C2.9010108@zynaptic.com> Date: Mon, 08 Jun 2009 10:15:00 -0000 From: Chris Holgate User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: GaurangT CC: ecos-devel@ecos.sourceware.org Subject: Re: Updated version of the STM32 USB driver. References: <4A23A4B1.9020805@zynaptic.com> <23867737.post@talk.nabble.com> In-Reply-To: <23867737.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-06/txt/msg00015.txt.bz2 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.