2 * @brief Master include file for the library USB functionality
\r
5 * Copyright(C) NXP Semiconductors, 2012
\r
6 * Copyright(C) Dean Camera, 2011, 2012
\r
7 * All rights reserved.
\r
10 * Software that is described herein is for illustrative purposes only
\r
11 * which provides customers with programming information regarding the
\r
12 * LPC products. This software is supplied "AS IS" without any warranties of
\r
13 * any kind, and NXP Semiconductors and its licensor disclaim any and
\r
14 * all warranties, express or implied, including all implied warranties of
\r
15 * merchantability, fitness for a particular purpose and non-infringement of
\r
16 * intellectual property rights. NXP Semiconductors assumes no responsibility
\r
17 * or liability for the use of the software, conveys no license or rights under any
\r
18 * patent, copyright, mask work right, or any other intellectual property rights in
\r
19 * or to any products. NXP Semiconductors reserves the right to make changes
\r
20 * in the software without notification. NXP Semiconductors also makes no
\r
21 * representation or warranty that such application will be suitable for the
\r
22 * specified use without further testing or modification.
\r
25 * Permission to use, copy, modify, and distribute this software and its
\r
26 * documentation is hereby granted, under NXP Semiconductors' and its
\r
27 * licensor's relevant copyrights in the software, without fee, provided that it
\r
28 * is used in conjunction with NXP Semiconductors microcontrollers. This
\r
29 * copyright, permission, and disclaimer notice must appear in all copies of
\r
33 /** @defgroup Group_USB USB Core - software/LPCUSBLib/Drivers/USB/USB.h
\r
34 * @ingroup LPCUSBlib
\r
36 * @section Sec_Dependencies Module Source Dependencies
\r
37 * The following files must be built with any user project that uses this module:
\r
38 * - LPCUSBlib/Drivers/USB/Core/ConfigDescriptor.c
\r
39 * - LPCUSBlib/Drivers/USB/Core/DeviceStandardReq.c
\r
40 * - LPCUSBlib/Drivers/USB/Core/Events.c
\r
41 * - LPCUSBlib/Drivers/USB/Core/HostStandardReq.c
\r
42 * - LPCUSBlib/Drivers/USB/Core/USBTask.c
\r
43 * - LPCUSBlib/Drivers/USB/Core/Device.c
\r
44 * - LPCUSBlib/Drivers/USB/Core/Endpoint.c
\r
45 * - LPCUSBlib/Drivers/USB/Core/EndpointStream.c
\r
46 * - LPCUSBlib/Drivers/USB/Core/Host.c
\r
47 * - LPCUSBlib/Drivers/USB/Core/Pipe.c
\r
48 * - LPCUSBlib/Drivers/USB/Core/PipeStream.c
\r
49 * - LPCUSBlib/Drivers/USB/Core/USBController.c
\r
50 * - LPCUSBlib/Drivers/USB/Class/Common/HIDParser.c
\r
52 * @section Sec_ModDescription Module Description
\r
53 * Driver and framework for the USB controller of the selected architecture and microcontroller model. This module
\r
54 * consists of many submodules, and is designed to provide an easy way to configure and control USB host, device
\r
55 * or OTG mode USB applications.
\r
57 * The USB stack requires the sole control over the USB controller in the microcontroller only; i.e. it does not
\r
58 * require any additional timers or other peripherals to operate. This ensures that the USB stack requires as few
\r
59 * resources as possible.
\r
61 * The USB stack can be used in Device Mode for connections to USB Hosts (see @ref Group_Device), in Host mode for
\r
62 * hosting of other USB devices (see @ref Group_Host), or as a dual role device which can either act as a USB host
\r
63 * or device depending on what peripheral is connected (see @ref Group_OTG). Both modes also require a common set
\r
64 * of USB management functions found @ref Group_USBManagement.
\r
67 /** @defgroup Group_USBClassDrivers USB Class Drivers
\r
68 * @ingroup LPCUSBlib
\r
70 * Drivers for both host and device mode of the standard USB classes, for rapid application development.
\r
71 * Class drivers give a framework which sits on top of the low level library API, allowing for standard
\r
72 * USB classes to be implemented in a project with minimal user code. These drivers can be used in
\r
73 * conjunction with the library low level APIs to implement interfaces both via the class drivers and via
\r
74 * the standard library APIs.
\r
76 * Multiple device mode class drivers can be used within a project, including multiple instances of the
\r
77 * same class driver. In this way, USB Hosts and Devices can be made quickly using the internal class drivers
\r
78 * so that more time and effort can be put into the end application instead of the USB protocol.
\r
80 * The available class drivers and their modes are listed below.
\r
84 * <th width="100px">USB Class</th>
\r
85 * <th width="90px">Device Mode</th>
\r
86 * <th width="90px">Host Mode</th>
\r
90 * <td bgcolor="#00EE00">Yes</td>
\r
91 * <td bgcolor="#00EE00">Yes</td>
\r
95 * <td bgcolor="#00EE00">Yes</td>
\r
96 * <td bgcolor="#00EE00">Yes</td>
\r
100 * <td bgcolor="#00EE00">Yes</td>
\r
101 * <td bgcolor="#00EE00">Yes</td>
\r
105 * <td bgcolor="#00EE00">Yes</td>
\r
106 * <td bgcolor="#00EE00">Yes</td>
\r
109 * <td>Mass Storage</td>
\r
110 * <td bgcolor="#00EE00">Yes</td>
\r
111 * <td bgcolor="#00EE00">Yes</td>
\r
115 * <td bgcolor="#EE0000">No</td>
\r
116 * <td bgcolor="#00EE00">Yes</td>
\r
120 * <td bgcolor="#00EE00">Yes</td>
\r
121 * <td bgcolor="#00EE00">Yes</td>
\r
124 * <td>Still Image</td>
\r
125 * <td bgcolor="#EE0000">No</td>
\r
126 * <td bgcolor="#00EE00">Yes</td>
\r
131 * @section Sec_UsingClassDrivers Using the Class Drivers
\r
132 * To make the Class drivers easy to integrate into a user application, they all implement a standardized
\r
133 * design with similarly named/used function, enums, defines and types. The two different modes are implemented
\r
134 * slightly differently, and thus will be explained separately. For information on a specific class driver, read
\r
135 * the class driver's module documentation.
\r
137 * @subsection Sec_ClassDriverDevice Device Mode Class Drivers
\r
138 * Implementing a Device Mode Class Driver in a user application requires a number of steps to be followed. Firstly,
\r
139 * the module configuration and state structure must be added to the project source. These structures are named in a
\r
140 * similar manner between classes, that of <tt>USB_ClassInfo_<i>{Class Name}</i>_Device_t</tt>, and are used to hold the
\r
141 * complete state and configuration for each class instance. Multiple class instances is where the power of the class
\r
142 * drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_*
\r
145 * Inside the ClassInfo structure lies two sections, a \c Config section, and a \c State section. The \c Config
\r
146 * section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>
\r
147 * before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters
\r
148 * for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.
\r
150 * The \c State section of the \c USB_ClassInfo_* structures are designed to be controlled by the Class Drivers only for
\r
151 * maintaining the Class Driver instance's state, and should not normally be set by the user application.
\r
153 * The following is an example of a properly initialized instance of the Audio Class Driver structure:
\r
156 * USB_ClassInfo_Audio_Device_t My_Audio_Interface =
\r
160 * .StreamingInterfaceNumber = 1,
\r
162 * .DataINEndpointNumber = 1,
\r
163 * .DataINEndpointSize = 256,
\r
168 * @note The class driver's configuration parameters should match those used in the device's descriptors that are
\r
169 * sent to the host.
\r
171 * To initialize the Class driver instance, the driver's <tt><i>{Class Name}</i>_Device_ConfigureEndpoints()</tt> function
\r
172 * should be called in response to the @ref EVENT_USB_Device_ConfigurationChanged() event. This function will return a
\r
173 * boolean true value if the driver successfully initialized the instance. Like all the class driver functions, this function
\r
174 * takes in the address of the specific instance you wish to initialize - in this manner, multiple separate instances of
\r
175 * the same class type can be initialized like this:
\r
178 * void EVENT_USB_Device_ConfigurationChanged(void)
\r
180 * LEDs_SetAllLEDs(LEDMASK_USB_READY);
\r
182 * if (!(Audio_Device_ConfigureEndpoints(&My_Audio_Interface)))
\r
183 * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
\r
187 * Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's
\r
188 * <tt><i>{Class Name}</i>_Device_USBTask()</tt> function in the main program loop. The exact implementation of this
\r
189 * function varies between class drivers, and can be used for any internal class driver purpose to maintain each
\r
190 * instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each
\r
191 * separate instance, just like the main USB maintenance routine @ref USB_USBTask():
\r
198 * LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
\r
202 * Create_And_Process_Samples();
\r
204 * Audio_Device_USBTask(&My_Audio_Interface);
\r
210 * The final standardized Device Class Driver function is the Control Request handler function
\r
211 * <tt><i>{Class Name}</i>_Device_ProcessControlRequest()</tt>, which should be called when the
\r
212 * @ref EVENT_USB_Device_ControlRequest() event fires. This function should also be called for
\r
213 * each class driver instance, using the address of the instance to operate on as the function's
\r
214 * parameter. The request handler will abort if it is determined that the current request is not
\r
215 * targeted at the given class driver instance, thus these methods can safely be called
\r
216 * one-after-another in the event handler with no form of error checking:
\r
219 * void EVENT_USB_Device_ControlRequest(void)
\r
221 * Audio_Device_ProcessControlRequest(&My_Audio_Interface);
\r
225 * Each class driver may also define a set of callback functions (which are prefixed by \c CALLBACK_*
\r
226 * in the function's name) which <b>must</b> also be added to the user application - refer to each
\r
227 * individual class driver's documentation for mandatory callbacks. In addition, each class driver may
\r
228 * also define a set of events (identifiable by their prefix of \c EVENT_* in the function's name), which
\r
229 * the user application <b>may</b> choose to implement, or ignore if not needed.
\r
231 * The individual Device Mode Class Driver documentation contains more information on the non-standardized,
\r
232 * class-specific functions which the user application can then use on the driver instances, such as data
\r
233 * read and write routines. See each driver's individual documentation for more information on the
\r
234 * class-specific functions.
\r
236 * @subsection Sec_ClassDriverHost Host Mode Class Drivers
\r
237 * Implementing a Host Mode Class Driver in a user application requires a number of steps to be followed. Firstly,
\r
238 * the module configuration and state structure must be added to the project source. These structures are named in a
\r
239 * similar manner between classes, that of <tt>USB_ClassInfo_<b>{Class Name}</b>_Host_t</tt>, and are used to hold the
\r
240 * complete state and configuration for each class instance. Multiple class instances is where the power of the class
\r
241 * drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_*
\r
244 * Inside the \c USB_ClassInfo_* structure lies two sections, a \c Config section, and a \c State section. The \c Config
\r
245 * section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>
\r
246 * before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters
\r
247 * for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.
\r
249 * The \c State section of the \c USB_ClassInfo_* structures are designed to be controlled by the Class Drivers only for
\r
250 * maintaining the Class Driver instance's state, and should not normally be set by the user application.
\r
252 * The following is an example of a properly initialized instance of the MIDI Class Driver structure:
\r
255 * USB_ClassInfo_MIDI_Host_t My_MIDI_Interface =
\r
259 * .DataINPipeNumber = 1,
\r
260 * .DataINPipeDoubleBank = false,
\r
262 * .DataOUTPipeNumber = 2,
\r
263 * .DataOUTPipeDoubleBank = false,
\r
268 * To initialize the Class driver instance, the driver's <tt><b>{Class Name}</b>_Host_ConfigurePipes()</tt> function
\r
269 * should be called in response to the host state machine entering the @ref HOST_STATE_Addressed state. This function
\r
270 * will return an error code from the class driver's <tt><b>{Class Name}</b>_EnumerationFailure_ErrorCodes_t</tt> enum
\r
271 * to indicate if the driver successfully initialized the instance and bound it to an interface in the attached device.
\r
272 * Like all the class driver functions, this function takes in the address of the specific instance you wish to initialize -
\r
273 * in this manner, multiple separate instances of the same class type can be initialized. A fragment of a Class Driver
\r
274 * based Host mode application may look like the following:
\r
277 * switch (USB_HostState)
\r
279 * case HOST_STATE_Addressed:
\r
280 * LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING);
\r
282 * uint16_t ConfigDescriptorSize;
\r
283 * uint8_t ConfigDescriptorData[512];
\r
285 * if (USB_Host_GetDeviceConfigDescriptor(1, &ConfigDescriptorSize, ConfigDescriptorData,
\r
286 * sizeof(ConfigDescriptorData)) != HOST_GETCONFIG_Successful)
\r
288 * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
\r
289 * USB_HostState = HOST_STATE_WaitForDeviceRemoval;
\r
293 * if (MIDI_Host_ConfigurePipes(&My_MIDI_Interface,
\r
294 * ConfigDescriptorSize, ConfigDescriptorData) != MIDI_ENUMERROR_NoError)
\r
296 * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
\r
297 * USB_HostState = HOST_STATE_WaitForDeviceRemoval;
\r
301 * // Other state handler code here
\r
304 * Note that the function also required the device's configuration descriptor so that it can determine which interface
\r
305 * in the device to bind to - this can be retrieved as shown in the above fragment using the
\r
306 * @ref USB_Host_GetDeviceConfigDescriptor() function. If the device does not implement the interface the class driver
\r
307 * is looking for, if all the matching interfaces are already bound to class driver instances or if an error occurs while
\r
308 * binding to a device interface (for example, a device endpoint bank larger that the maximum supported bank size is used)
\r
309 * the configuration will fail.
\r
311 * Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's
\r
312 * <tt><b>{Class Name}</b>_Host_USBTask()</tt> function in the main program loop. The exact implementation of this
\r
313 * function varies between class drivers, and can be used for any internal class driver purpose to maintain each
\r
314 * instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each
\r
315 * separate instance, just like the main USB maintenance routine @ref USB_USBTask():
\r
322 * LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
\r
326 * switch (USB_HostState)
\r
328 * // Host state machine handling here
\r
331 * MIDI_Host_USBTask(&My_Audio_Interface);
\r
337 * Each class driver may also define a set of callback functions (which are prefixed by \c CALLBACK_*
\r
338 * in the function's name) which <b>must</b> also be added to the user application - refer to each
\r
339 * individual class driver's documentation for mandatory callbacks. In addition, each class driver may
\r
340 * also define a set of events (identifiable by their prefix of \c EVENT_* in the function's name), which
\r
341 * the user application <b>may</b> choose to implement, or ignore if not needed.
\r
343 * The individual Host Mode Class Driver documentation contains more information on the non-standardized,
\r
344 * class-specific functions which the user application can then use on the driver instances, such as data
\r
345 * read and write routines. See each driver's individual documentation for more information on the
\r
346 * class-specific functions.
\r
353 #define __INCLUDE_FROM_USB_DRIVER
\r
356 #include "../../Common/Common.h"
\r
357 #include "Core/USBMode.h"
\r
360 #include "Core/USBTask.h"
\r
361 #include "Core/Events.h"
\r
362 #include "Core/StdDescriptors.h"
\r
363 #include "Core/ConfigDescriptor.h"
\r
364 #include "Core/USBController.h"
\r
365 #include "Core/USBInterrupt.h"
\r
367 #if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__)
\r
368 #include "Core/Host.h"
\r
369 #include "Core/Pipe.h"
\r
370 #include "Core/HostStandardReq.h"
\r
371 #include "Core/PipeStream.h"
\r
374 #if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__)
\r
375 #include "Core/Device.h"
\r
376 #include "Core/Endpoint.h"
\r
377 #include "Core/DeviceStandardReq.h"
\r
378 #include "Core/EndpointStream.h"
\r
381 #if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__)
\r
382 #include "Core/OTG.h"
\r
385 #include "Class/AudioClass.h"
\r
386 #include "Class/CDCClass.h"
\r
387 #include "Class/HIDClass.h"
\r
388 #include "Class/MassStorageClass.h"
\r
389 #include "Class/MIDIClass.h"
\r
390 #include "Class/PrinterClass.h"
\r
391 #include "Class/RNDISClass.h"
\r
392 #include "Class/StillImageClass.h"
\r
projects / freertos / blob