device.dir

本代bootloader通过usb下载代码首先存放在sdram中

 routine should simply check the Vbus status and then %call the USBD_Connect
 and USBD_Disconnect$ function to put %device into right state.

 Finally, if an OS is being used, then the driver should probably be installed
 prior to use. Interrupt configuration may also be done differently. Please
 refer to the documentation of the OS for more information.

 This callback is #mandatory#.

 !!Reset
 When an End of bus reset has been detected, the USBDCallbacks_Reset callback
 is triggered. The callback should perform #initialization# or #re-
 initialization# of the user-level application. For example, a class driver
 like MSD should re-initialize its internal state when a USB reset is performed.

 !!Suspend
 When the USB %device enters the Suspended state, the USB API notifies this state
 change by invoking the USBDCallbacks_Suspended callback. This can happen either
 when the bus is idle or when the %device is disconnected from the USB.

 If the %device should enter low-power mode when suspended, then this callback
 must perform the required operations to do so, e.g., switching to a slow clock,
 disabling PLLs, etc.

 - }Note: The electrical specification of the USB 2.0 defines a maximum current
    consumption of 500uA for suspended %device. This includes the current passing
    through pull-ups and upll-downs.}

 !!Resume
 The USBDCallbacks_Resumed callback is invoked when the USB %device leaves the
 Suspended state and returns to its previous state (either Powered, Default,
 Address or Configured). This may happen when activity is detected on the USB,
 or when the %device gets connected.

 If the %device was in low-power mode because of the Suspend callback, then this
 callback must perform the necessary poerations to return the %device into a
 normal operation mode, e.g., switching to a fast clock.

 !!NewRequest
 When a SETUP request is received on a control endpoint, the USBD API layer
 triggers the USBDCallbacks_RequestReceived callback to notify the user
 application. The received request can then be accessed through the
 corresponding USBGenericRequest structure.

 SETUP packets are used for class-specific requests (e.g. }GetMaxLUN} in MSD)
 as well as standard USB requests (e.g. }SetConfiguration}). The former are
 described in }USB Device Class Documents}, such as the }Mass Storage Bulk
 Only 1.0}, the latter are defined in the USB Specification 2.0.

 - }Note: that SETUP requests which are not understood by the %device should
   be acknowledged with a STALL handshake. This notifies the host that the
   %device cannot process the command.}

 This callback is #mandatory#.

 !!StartOfFrame
 Every 1ms (for a full-speed %device) or 125us (for a high-speed %device) a
 new USB frame starts. A callback can be invoked whenever this occurs.

 Because the start-of-frame interrupt %puts some stress on the processor
 (since it is called a lot), it is only activated the corresponding
 callback is defined (#now it's NOT defined in current framework#).

*/

/**
 \page "USBD Standard Request Handler"

 !!!Standard Request Handler

 Chapter 9 of the USB specification 2.0 defines a set of standard requests
 which have to be implemented by all devices. Since most class drivers treat
 those requests in the standard way, the USB framework provides a way to easily
 do that.

 !!!USBDDriver_RequestHandler

 USBDDriver_RequestHandler handles the standard requests in an appropriate way.
 It can answer the following commands:

 - GET_DESCRIPTOR
 - SET_ADDRESS
 - SET_CONFIGURATION
 - GET_CONFIGURATION
 - CLEAR_FEATURE
 - SET_FEATURE
 - GET_STATUS

 Simply using this standard request handler enables a %device to be enumerated
 correctly.

 !!Get Descriptor
 The GET_DESCRIPTOR request is used by the host to retrieve information about
 the %device by means of several descriptors.

 The standard request handler simply sends the corresponding descriptor to the
 host. How these descriptors are provided to the function is discussed in
 Structures.

 !!Set Address
 Whenever the host wants to change the %device state from Default to Address, or
 vice-versa, it sends a SET_ADDRESS request. The wValue field contains the new
 address of the %device; if it is null, then the %device returns to the Default
 state.

 The USBD_SetAddress function is called to perform this operation. Note that a
 zero-length packet must be sent prior to doing that, to acknowledge the SETUP
 transfer.

 !!Set Configuration & GetConfiguration
 The SET_CONFIGURATION request makes it possible for the host to select between
 one or more configurations for the %device. GET_CONFIGURATION is used to
 retrieve the currently selected one.

 Those two requests are handled in a very basic way by
 USBDDriver_RequestHandler: it assumes that the %device has only one
 configuration. Therefore, the SET_CONFIGURATION request is simply acknowledged
 with a zero-length packet, and GET_CONFIGURATION is answered with either 0
 or 1. If the user application needs more than one configuration, it will be
 the duty of the class driver handler to service those requests.

 In addition, when the SET_CONFIGURATION request causes the %device to enter the
 Configured state, the standard request handler calls the USBD_ConfigureEndpoint
 method for each endpoint used by the %device;

 !!Clear Feature, Set Feature & Get Status
 Several features of a %device can either be activated or deactivated by the USB
 host:
 - Remote wakeup
 - Endpoint Halt state
 Three requests can be used to either set, clear or get the status of these two
 features: SET_FEATURE, CLEAR_FEATURE and GET_STATUS.
 
 The USBDDriver_RequestHandler method answers a Halt state operation by calling
 the USBD_Halt method on the endpoint with the request.

 !!!Structures
 Several pieces of information must be known to the USBDDriver_RequestHandler
 to be able to process some SETUP commands. For example, all the descriptors
 (configuration, etc.) used by the %device are needed since they must be sent
 to the host when a GET_DESCRIPTOR is received.

 The USBGenericRequest structure is a "standard USB class driver" object used
 to hold the required information. It must be passed as an argument to the
 USBDDriver_RequestHandler method. Another structure, USBDDriverDescriptors, is
 used to store the descriptors list.

 !!!Usage
 The NewRequest callback is used to notify the user application that a new SETUP
 request has been received. SETUP request can either be class-specific or
 standard.

 The correct way to handle incoming requests is to first process class-specific
 requests using a class handler. For example, a Mass Storage implementation will
 define the NewRequest callback to call MSDDriver_RequestHandler. This function
 will handle the necessary requests, and forward the rest to
 USBDDriver_RequestHandler.

 If a request cannot be processed, USBDDriver_RequestHandler will STALL control
 endpoint 0.

*/

/**
 \page "VID, PID, SN & Strings"

 This page collects the definition for USB %device to indicate the Vendor and
 Product information.


 If you need only the functions in demo %driver, you can easily modify these
 definitions to change your device's Identification and Display strings.

 They are defined in the driver c code file that suffixed with
 "DriverDescriptors" under the driver directory.

 !!!VID, PID & SN in Device Descriptor

 Defined as const and used in USBDeviceDescriptor instance initialization.
 Gives identivication to the USB %device by VID and PID. The INF installation
 file should mach the VID & PID so that the %device can be installed.

\code
const USBDeviceDescriptor deviceDescriptor = {...};
\endcode

 - "audio-speaker": "Audio Speaker Device Codes"
 - ccid: "CCID Device IDs"
 - "cdc-serial": "CDC Serial Device IDs"
 - "hid-keyboard": "HID Device Descriptor IDs"
 - massstorage: "MSD Device Descriptor IDs"

 !!!Strings

 The strings gives additional information on the USB %device, normally string
 description about the vendor, product and serial number.

 The strings are defined as a list to initialize the driver's
 USBDDriverDescriptors instance:

 - "audio-speaker": auddSpeakerDriverDescriptors
 - ccid: ccidDriverDescriptors
 - "cdc-serial": cdcdSerialDriverDescriptors
 - "hid-keyboard": hiddKeyboardDriverDescriptors
 - massstorage: msdDriverDescriptors

\code
// String descriptors
const unsigned char *stringDescriptors[] = {

    languageIdDescriptor,
    manufacturerDescriptor,
    productDescriptor,
    serialNumberDescriptor,
};
\endcode
*/