<h1>usbps v2_2</h1><p>This file contains the implementation of the <aclass="el"href="struct_x_usb_ps.html">XUsbPs</a> driver. It is the driver for an USB controller in DEVICE or HOST mode.</p>
<p>The Spartan-3AF Embedded Peripheral Block contains a USB controller for communication with serial peripherals or hosts. The USB controller supports Host, Device and On the Go (OTG) applications.</p>
<li>(a) Configuration of the basic parameters: In this stage the basic parameters for the driver are configured, including the base address and the controller ID.</li>
<li>(b) Configuration of the DEVICE endpoints (if applicable): If DEVICE mode is desired, the endpoints of the controller need to be configured using the <aclass="el"href="struct_x_usb_ps___device_config.html">XUsbPs_DeviceConfig</a> data structure. Once the endpoint configuration is set up in the data structure, The user then needs to allocate the required amount of DMAable memory and finalize the configuration of the <aclass="el"href="struct_x_usb_ps___device_config.html">XUsbPs_DeviceConfig</a> data structure, e.g. setting the DMAMemVirt and DMAMemPhys members.</li>
<li>(c) Configuration of the DEVICE modes: In the second stage the parameters for DEVICE are configured. The caller only needs to configure the modes that are actually used. Configuration is done with the: <aclass="el"href="xusbps_8h.html#a6daace32113a806a6822a6d5943a93f4">XUsbPs_ConfigureDevice()</a> Configuration parameters are defined and passed into these functions using the: <aclass="el"href="struct_x_usb_ps___device_config.html">XUsbPs_DeviceConfig</a> data structures.</li>
<p>The USB core supports up to 4 endpoints. Each endpoint has two directions, an OUT (RX) and an IN (TX) direction. Note that the direction is viewed from the host's perspective. Endpoint 0 defaults to be the control endpoint and does not need to be set up. Other endpoints need to be configured and set up depending on the application. Only endpoints that are actuelly used by the application need to be initialized. See the example code (xusbps_intr_example.c) for more information.</p>
<p>The USB core uses one interrupt line to report interrupts to the CPU. Interrupts are handled by the driver's interrupt handler function <aclass="el"href="xusbps_8h.html#a1fa8bf48bf7488cebb101c888489efc2">XUsbPs_IntrHandler()</a>. It has to be registered with the OS's interrupt subsystem. The driver's interrupt handler divides incoming interrupts into two categories:</p>
<p>The user (typically the adapter layer) can register general interrupt handler fucntions and endpoint specific interrupt handler functions with the driver to receive those interrupts by calling the <aclass="el"href="xusbps_8h.html#a521c050d3b146bb58862f5fadf7f6ba6">XUsbPs_IntrSetHandler()</a> and <aclass="el"href="xusbps_8h.html#a04fb0b564bcd01cdf33e29ca2732656a">XUsbPs_EpSetHandler()</a> functions respectively. Calling these functions with a NULL pointer as the argument for the function pointer will "clear" the handler function.</p>
<p>The user can register one handler function for the generic interrupts and two handler functions for each endpoint, one for the RX (OUT) and one for the TX (IN) direction. For some applications it may be useful to register a single endpoint handler function for muliple endpoints/directions.</p>
<p>When a callback function is called by the driver, parameters identifying the type of the interrupt will be passed into the handler functions. For general interrupts the interrupt mask will be passed into the handler function. For endpoint interrupts the parameters include the number of the endpoint, the direction (OUT/IN) and the type of the interrupt.</p>
<p>Data buffers are sent to and received from endpoint using the <aclass="el"href="xusbps_8h.html#a6bfe53ec45a998d5673b80e11ab4d292">XUsbPs_EpBufferSend()</a>, <aclass="el"href="xusbps_8h.html#a1e4c0735be24ea24b73404db8d18133e">XUsbPs_EpBufferSendWithZLT()</a> and <aclass="el"href="xusbps_8h.html#ac27a9d64ddf33a2400d7493e301a7192">XUsbPs_EpBufferReceive()</a> functions.</p>
<p>User data buffer size is limited to 16 Kbytes. If the user wants to send a data buffer that is bigger than this limit it needs to break down the data buffer into multiple fragments and send the fragments individually.</p>
<p>From the controller perspective Data buffers can be aligned at any boundary. if the buffers are from cache region then the buffer and buffer size should be aligned to cache line aligned</p>
<p>The driver uses a zero copy mechanism which imposes certain restrictions to the way the user can handle the data buffers.</p>
<p>One restriction is that the user needs to release a buffer after it is done processing the data in the buffer.</p>
<p>Similarly, when the user sends a data buffer it MUST not re-use the buffer until it is notified by the driver that the buffer has been transmitted. The driver will notify the user via the registered endpoint interrupt handling function by sending a XUSBPS_EP_EVENT_DATA_TX event.</p>
<p>The driver uses DMA internally to move data from/to memory. This behaviour is transparent to the user. Keeping the DMA handling hidden from the user has the advantage that the same API can be used with USB cores that do not support DMA.</p>
