EasyManua.ls Logo

Cypress EZ-USB FX3 SDK - USB Device Handling

Cypress EZ-USB FX3 SDK
56 pages
Print Icon
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
Cypress EZ-USB® FX3™ SDK Quick Start Guide, Version 1.3.1 27
required based on the firmware implementation. The FX3 SDK provides an
implementation of this heap using the ThreadX byte pool services.
Buffer Heap: This is a heap region which is used for runtime allocation of
buffers used for data transfers through the FX3 device. The SDK provides a
home grown implementation of a buffer heap manager, which ensures that
all allocated buffers are cache line aligned.
Runtime Heap: This is an optional heap which is required only if the
application makes use of standard memory allocation routines like malloc or
new. The size requirement for this heap will depend on the application.
The code, data, bss and runtime heap region boundaries are set through the linker
script. The mem heap and buffer heap regions are specified in code while
initializing them.
Please refer to the firmware/common/fx3.ld file for a linker script that initializes the
code, data and bss regions. Please refer to the firmware/common/fx3cpp.ld file for
a linker script that initializes the runtime heap in addition to the above regions.
Please refer to the firmware/common/cyfxtx.c source file for the placement and
initialization of the mem heap and buffer heap regions.
All of these regions have to be placed in the memory available on the FX3 device,
which includes 16 KB of I-TCM and 512 or 256 KB or System RAM.
5.4 USB Device Handling
5.4.1 USB Device Enumeration
The FX3 firmware API supports two models of handling USB device enumeration.
In the fast enumeration model, the user registers a set of USB descriptors with the
API; and the USB driver handles the control requests from the USB host using this
data. The advantage of this model is that the control request handling in the driver
has been tested to pass all USB compliance test requirements; and the user does
not need to implement all of the negative condition checks required to pass these
tests. The driver will continue to forward control request callbacks for any unknown
requests (vendor or class specific, as well as requests for unregistered strings) to
the user application.
In the application enumeration model, all control requests will trigger a callback to
the user application; and the application can handle the request as suitable. The
advantage of this model is that allows the application to implement any number of
configurations and provides greater flexibility.
The model of enumeration is selected using the
CyU3PUsbRegisterSetupCallback() API.