cancel
Showing results for 
Search instead for 
Did you mean: 

USB Lib V2.1.0, Endpoint buffers, howto

tomaskrueger
Associate II
Posted on August 12, 2014 at 19:07

Gooood morning........STM

Today i am looking at defining more endpoints for a usb uvc ''device''.

I do understand, that endpoints shall be initialized after an appropriate SETUP message

has been received by the host.

The usblib v2.1.0 has a ''class''-callback ''Init'' or ''Interface_Init'' which handles the initalization of endpoints stated in the Configuration/Interface Descriptor.

The service routine then inits endpoints by program on this ''Interface Init'' call.

My question is, how endpoint buffers are working.

From ''usb_conf.h'' i paste the following buffer settings(mine):

/****************** USB OTG FS CONFIGURATION **********************************/

//The value of RX_FIFO_FS_SIZE should be aware of 4-byte alignment (ie. multiple of 4).

 &sharpdefine RX_FIFO_FS_SIZE                          128        //Sets the Receive FIFO size for the full speed core. which Endpoint??

 //max endpoint

 &sharpdefine TX0_FIFO_FS_SIZE                          64        //Sets the Transmit FIFO size for a device endpoint CONTROL-EP

 &sharpdefine TX1_FIFO_FS_SIZE                         128        // dito for ep1 and so on.

 &sharpdefine TX2_FIFO_FS_SIZE                          0        // 0 means, EP not used ?!

 &sharpdefine TX3_FIFO_FS_SIZE                          0

 

 //HOST mode only: Sets the non-periodic Transmit FIFO size for Host mode (Full Speed).

 &sharpdefine TXH_NP_FS_FIFOSIZ                         96

 //Sets the Periodic Transmit FIFO size for Host mode (Full Speed).

 &sharpdefine TXH_P_FS_FIFOSIZ                          96

 

i know that endpoint transfer happen on a 64-byte packet basis.(or less)(hardware related)

On F2/F4 devices there are only 4 endpoints (ep0(control),ep1,ep2,ep3)

What limits apply to above buffers?

Fe. if i set RXfifo to 1024, is that ok? (what endpoint does the rxfifo relate to?)

TxFifos can have what size?

I assume that these ''Fifos'' can be used as a buffer for data exchange, and the driver will handle status according (how).

io-routines:

DCD_EP_Tx(...)

Rx..?

#usb-lib-v2.1.0-endpoints
4 REPLIES 4
tsuneo
Senior
Posted on August 12, 2014 at 21:14

RX_FIFO_FS_SIZE is written to OTG_FS_GRXFSIZ register directly, in USB_OTG_CoreInitDev() (usb_core.c)

And then, this limitation, described in the Reference manual, is applied. a) This value is in terms of 32-bit words. b) Minimum value is 16 (words = 64 bytes) c) Maximum value is 256 The number is represented by words, not by bytes. TX0_FIFO_FS_SIZE has the same limitation. For other TXx_FIFO_FS_SIZE, above a) and b) are applied. Of course, the total size should not exceed the 1.25kBytes (ie. 320 words) FIFO Be aware, usb_conf_template.h also holds important information, not documented on the Reference manual.

usb_conf_template.h
/*******************************************************************************
* FIFO Size Configuration in Device mode
* 
* (i) Receive data FIFO size = RAM for setup packets +
* OUT endpoint control information +
* data OUT packets + miscellaneous
* Space = ONE 32-bits words
* --> RAM for setup packets = 10 spaces
* (n is the nbr of CTRL EPs the device core supports)
* --> OUT EP CTRL info = 1 space
* (one space for status information written to the FIFO along with each
* received packet)
* --> data OUT packets = (Largest Packet Size / 4) + 1 spaces
* (MINIMUM to receive packets)
* --> OR data OUT packets = at least 2*(Largest Packet Size / 4) + 1 spaces
* (if high-bandwidth EP is enabled or multiple isochronous EPs)
* --> miscellaneous = 1 space per OUT EP
* (one space for transfer complete status information also pushed to the
* FIFO with each endpoint's last packet)
*
* (ii)MINIMUM RAM space required for each IN EP Tx FIFO = MAX packet size for
* that particular IN EP. More space allocated in the IN EP Tx FIFO results
* in a better performance on the USB and can hide latencies on the AHB.
*
* (iii) TXn min size = 16 words. (n : Transmit FIFO index)
* (iv) When a TxFIFO is not used, the Configuration should be as follows:
* case 1 : n > m and Txn is not used (n,m : Transmit FIFO indexes)
* --> Txm can use the space allocated for Txn.
* case2 : n < 
m
and Txn is not used (n,m : Transmit FIFO indexes)
* --> Txn should be configured with the minimum space of 16 words
* (v) The FIFO is used optimally when used TxFIFOs are allocated in the top
* of the FIFO.Ex: use EP1 and EP2 as IN instead of EP1 and EP3 as IN ones.
*******************************************************************************/

> DCD_EP_Tx(...), Rx.? DCD_EP_PrepareRx() pass an empty buffer to the EP, to receive a transfer on the buffer. When a transfer finishes, ''DataOut'' callback is called by the stack. For example of CDC,

usbc_cdc_core.c
/* CDC interface class callbacks structure */
USBD_Class_cb_TypeDef USBD_CDC_cb =
{
usbd_cdc_Init,
usbd_cdc_DeInit,
usbd_cdc_Setup,
NULL, /* EP0_TxSent, */
usbd_cdc_EP0_RxReady,
usbd_cdc_DataIn,
usbd_cdc_DataOut, <------------ DataOut callback
usbd_cdc_SOF,
NULL,
NULL, 
USBD_cdc_GetCfgDesc,
#ifdef USE_USB_OTG_HS 
USBD_cdc_GetOtherCfgDesc, /* use same cobfig as per FS */
#endif /* USE_USB_OTG_HS */
};

Tsuneo
tomaskrueger
Associate II
Posted on August 13, 2014 at 21:57

Ok,...i admit... i havent looked into the Ref-Manual.

I learned.....the USB module has an integrated RAM of size 1.25K to be used for endpoint transactions.

Makes sense, as the ''physical layer'' exchanges data anytime and thus, this RAM functions as an internal buffer.

I grabbed some info from the manual here:

 USB data FIFOs

The USB system features 1.25 Kbyte of dedicated RAM with a sophisticated FIFO control

mechanism. The packet FIFO controller module in the OTG_FS core organizes RAM space

into Tx-FIFOs into which the application pushes the data to be temporarily stored before the

USB transmission, and into a single Rx FIFO where the data received from the USB are

temporarily stored before retrieval (popped) by the application. The number of instructed

FIFOs and how these are architectured inside the RAM depends on the device’s role. In

peripheral mode an additional Tx-FIFO is instructed for each active IN endpoint. Any FIFO

size is software configured to better meet the application requirements.

Peripheral mode:

Receive FIFO RAM

For Receive FIFO RAM, the application should allocate RAM for SETUP packets:

Transmit FIFO RAM

For Transmit FIFO RAM, the minimum RAM space required for each IN Endpoint Transmit

FIFO is the maximum packet size for this IN endpoint.

-      Management of a shared Rx FIFO and a Tx-OUT FIFO for efficient usage of the USB

data RAM

-      Management of up to 4 dedicated Tx-IN FIFOs (one for each active IN EP) to put less

load on the application

As i understand, the one and only RXfifo will receive ALL RX data from all active OUT-endpoints (including Control/ep0).

Seperate Transmit fifos are to be configured for ALL active IN-endpoints (sending)  (at least 64 byte long)

Alltogether the limit is 1.25k Bytes.

Now coming back to the Application layer.

Here we call driver functions to receive and transmit data.

USB-Driver IO functions:

uint32_t  DCD_EP_Tx ( USB_OTG_CORE_HANDLE *pdev,

                     uint8_t   ep_addr,

                     uint8_t   *pbuf,

                     uint32_t   buf_len)

This function needs the IN-endpoint, the data source-buffer, amount of bytes.

Let say, i call this function to transmit 2000 Bytes and supply the sourcebuffer.

How to i know its finished transmitting?

uint32_t   DCD_EP_PrepareRx( USB_OTG_CORE_HANDLE *pdev,

                            uint8_t   ep_addr,

                            uint8_t *pbuf,                        

                            uint16_t  buf_len)

This functions is for receive data.

It wants the OUT-endpoint, destination buffer, amount of bytes.

If i call this function to receive 2000 Bytes and supply destination buffer,

How do i know its finished?

uint32_t  DCD_EP_Flush (USB_OTG_CORE_HANDLE *pdev , uint8_t epnum)

This function flushes the internal buffer (as said above).

Whats the actual use / application?

Finally, how do these User App functions influence the (see Top) internal USB-RAM buffers?

Thanks for getting me started :)

tsuneo
Senior
Posted on August 14, 2014 at 13:39

> DCD_EP_PrepareRx() - How do i know its finished?

This question has been already answered on my above post.

> DCD_EP_Tx() - How to i know its finished transmitting?

Similarly to DCD_EP_PrepareRx(), registered ''DataIn'' callback is called by the stack.

> DCD_EP_Flush() - Whats the actual use / application?

Usually, it is used for error recovery, to cancel outstanding transfer.

> Finally, how do these User App functions influence the (see Top) internal USB-RAM buffers?

UTSL

Tsuneo

tomaskrueger
Associate II
Posted on October 06, 2014 at 19:20

Ok,

uint32_t   DCD_EP_PrepareRx( USB_OTG_CORE_HANDLE *pdev,

                            uint8_t   ep_addr,

                            uint8_t *pbuf,                        

                            uint16_t  buf_len)

will ''prepare'' the EP ''ep_addr'' for receiving data of length ''buf_len'' to be put into the buffer ''*pbuf''.

On completion, it will issue a callback ''usbd_cdc_DataOut'' to let the App know ''Data has arrived''.

uint32_t  DCD_EP_Tx ( USB_OTG_CORE_HANDLE *pdev,

                     uint8_t   ep_addr,

                     uint8_t   *pbuf,

                     uint32_t   buf_len)

will put ''buf_len'' amount of Bytes into the ''EP_internal_Ram_Fifo'' copied from ''*pbuf''.

On completion ie. when the Host has red the data, the callback ''usbd_cdc_DataIn'' is issued to let the App know that the transfer completed.

True for Bulk, but also isochronous ?

DCD_EP_Flush(pdev, ENDPOINT);

This function clears the endpoint ''internal Ram Fifo data'', invalidate it.

Any pending USB transaction is cancelled on that endpoint.?!

> Finally, how do these User App functions influence the (see Top) internal USB-RAM buffers?

UTSL ...

well, i assume that ''Application'' must be aware of the internal Fifo size limitations when issueing commands on the endpoints.