1 /* --COPYRIGHT--,BSD\r
2 * Copyright (c) 2014, Texas Instruments Incorporated\r
3 * All rights reserved.\r
4 *\r
5 * Redistribution and use in source and binary forms, with or without\r
6 * modification, are permitted provided that the following conditions\r
7 * are met:\r
8 *\r
9 * * Redistributions of source code must retain the above copyright\r
10 * notice, this list of conditions and the following disclaimer.\r
11 *\r
12 * * Redistributions in binary form must reproduce the above copyright\r
13 * notice, this list of conditions and the following disclaimer in the\r
14 * documentation and/or other materials provided with the distribution.\r
15 *\r
16 * * Neither the name of Texas Instruments Incorporated nor the names of\r
17 * its contributors may be used to endorse or promote products derived\r
18 * from this software without specific prior written permission.\r
19 *\r
20 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"\r
21 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,\r
22 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR\r
23 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR\r
24 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,\r
25 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,\r
26 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;\r
27 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,\r
28 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR\r
29 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,\r
30 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.\r
31 * --/COPYRIGHT--*/\r
32 /** @file usbEventHandling.c\r
33 * @brief Contains required event Handler fucntions\r
34 */\r
35 /*\r
36 * ======== usbEventHandling.c ========\r
37 * Event-handling placeholder functions.\r
38 * All functios are called in interrupt context.\r
39 */\r
40 \r
41 //\r
42 //! \cond\r
43 //\r
44 \r
45 #include "USB_API/USB_Common/device.h"\r
46 #include "USB_API/USB_Common/defMSP430USB.h"\r
47 #include "USB_config/descriptors.h"\r
48 #include "USB_API/USB_Common/usb.h"\r
49 \r
50 #include "peripherals.h"\r
51 \r
52 #ifdef _CDC_\r
53 #include "USB_API/USB_CDC_API/UsbCdc.h"\r
54 #endif\r
55 \r
56 #ifdef _HID_\r
57 #include "USB_API/USB_HID_API/UsbHid.h"\r
58 #endif\r
59 \r
60 #ifdef _MSC_\r
61 #include "USB_API/USB_MSC_API/UsbMsc.h"\r
62 #endif\r
63 \r
64 #ifdef _PHDC_\r
65 #include "USB_API/USB_PHDC_API/UsbPHDC.h"\r
66 #endif\r
67 \r
68 //\r
69 //! \endcond\r
70 //\r
71 \r
72 //******************************************************************************\r
73 //\r
74 //! USB PLL has Failed\r
75 //!\r
76 //! This event signals that the output of the USB PLL has failed. This event may\r
77 //! have occurred because XT2, the source of the PLL’s reference clock, has\r
78 //! failed or is unreliable. If this event occurs, the USB connection will\r
79 //! likely be lost. It is best to handle it by calling USB_disconnect() and\r
80 //! attempting a re-connection.\r
81 //!\r
82 //! Since this event is associated with a change in state, it's a good\r
83 //! practice to return TRUE so the main loop can adapt.\r
84 //\r
85 //******************************************************************************\r
86 uint8_t USB_handleClockEvent ()\r
87 {\r
88 //Something happened to the PLL. This might also show up in the system as an oscillator fault on XT2.\r
89 //The USB connection is probably lost. Software should ensure any faults on XT2 are resolved,\r
90 //then can attempt to call USB_enable()/USB_connect() again.\r
91 USB_disconnect();\r
92 USB_disable();\r
93 \r
94 return ( TRUE) ; //Since this event is associated with a change in state, it's a good practice to return TRUE\r
95 //so the main loop can adapt.\r
96 }\r
97 \r
98 //*****************************************************************************\r
99 //\r
100 //! Valid Voltage Applied to VBUS\r
101 //!\r
102 //! If this function gets executed, it indicates that a valid voltage has been\r
103 //! applied to the VBUS pin; that is, the voltage on VBUS has transitioned from\r
104 //! low to high.\r
105 //!\r
106 //! This usually means the device has been attached to an active USB host. It is\r
107 //! recommended to attempt a USB connection from this handler, as described in\r
108 //! Sec. 6.3 of \e "Programmer’s Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC."\r
109 //! events.\r
110 //!\r
111 //! Returns TRUE to wake the main loop (if LPM was entered), so that it can\r
112 //! take into account the change in state.\r
113 //\r
114 //*****************************************************************************\r
115 uint8_t USB_handleVbusOnEvent ()\r
116 {\r
117 //The standard user experience when a USB device gets physically attached to a host is for the host to\r
118 //enumerate the device. Typically this happens as follows:\r
119 //1) the device senses 5V VBUS from the host, which tells it a host is present; (usually; but could also be a powered hub w/o a\r
120 //host! See state ST_NOENUM_SUSPENDED.)\r
121 //2) the device asserts the PUR signal, which tells the host the devicde is present;\r
122 //3) the host issues a number of USB device requests, including asking for the device's USB descriptors;\r
123 //4) the host decides if it has the appropriate driver for what it sees in the descriptors; and if so, loads it. Enumeration is\r
124 //now complete.\r
125 //So -- USB_handleVbusOnEvent occurs if a VBUS-on event has been detected. We respond by doing the following.\r
126 //However, keep in mind that USB_enable() might take a few milliseconds while the crystal starts up, and that most events handle\r
127 //in\r
128 //the context of the USB interrupt handler. If this interrupt latency is unacceptable, it might be better to set a flag for\r
129 //main() to handle it.\r
130 if (USB_enable() == kUSB_succeed){ //Start the module;\r
131 USB_reset(); //Reset the internal API\r
132 USB_connect(); //Assert PUR, to tell the host we're here\r
133 } //Enumeration will now take place in the background\r
134 return (TRUE); //Meanwhile, return TRUE to wake the main loop (if LPM was entered), so\r
135 } //that it can take into account the change in state\r
136 \r
137 //*****************************************************************************\r
138 //\r
139 //! Valid Voltage Removed from VBUS\r
140 //!\r
141 //! This event indicates that a valid voltage has just been removed from the\r
142 //! VBUS pin. That is, the voltage on VBUS has transitioned from high to low.\r
143 //!\r
144 //! This generally means the device has been removed from an active USB host. It\r
145 //! might also mean the device is still physically attached to the host, but the\r
146 //! host went into a standby mode; or it was attached to a powered hub but the\r
147 //! host upstream from that hub became inactive. The API automatically responds\r
148 //! to a VBUS-off event by powering down the USB module and PLL, which is the\r
149 //! equivalent of calling USB_disable(). It then calls this handling function,\r
150 //! if enabled.\r
151 //!\r
152 //! Since this event is associated with a change in state, it's a good\r
153 //! practice to return TRUE so the main loop can adapt.\r
154 //\r
155 //*****************************************************************************\r
156 uint8_t USB_handleVbusOffEvent ()\r
157 {\r
158 //Typically there's no need to place code here -- the main loop simply shifts to ST_USB_DISCONNECTED.\r
159 \r
160 return (TRUE); //Since this event is associated with a change in state, it's a good practice to return TRUE\r
161 //so the main loop can adapt.\r
162 }\r
163 \r
164 //*****************************************************************************\r
165 //\r
166 //! USB Host Issued a Reset\r
167 //!\r
168 //! This event indicates that the USB host has issued a reset of this USB\r
169 //! device. The API handles this automatically, and no action is required by the\r
170 //! application to maintain USB operation. After handling the reset, the API\r
171 //! calls this handling function, if enabled. In most cases there is no\r
172 //! significant reason for the application to respond to bus resets.\r
173 //\r
174 //*****************************************************************************\r
175 uint8_t USB_handleResetEvent ()\r
176 {\r
177 return (TRUE);\r
178 }\r
179 \r
180 //*****************************************************************************\r
181 //\r
182 //! USB Host Suspends USB Device\r
183 //!\r
184 //! This event indicates that the USB host has chosen to suspend this USB device\r
185 //! after a period of active operation. It’s important that a bus-powered,\r
186 //! suspended USB device limit its consumption of power from VBUS during this\r
187 //! time. The API automatically shuts down USB-related circuitry inside the\r
188 //! MSP430’s USB module. However, the application may need to shut down other\r
189 //! circuitry drawing from VBUS. This handler is a good place to do this.\r
190 //!\r
191 //! See Sec.11.1.3 of \e "Programmer’s Guide:\r
192 //! MSP430 USB API Stack for CDC/PHDC/HID/MSC." for a complete discussion\r
193 //! about handling suspend.\r
194 //!\r
195 //! Returns TRUE so that the main loop can adapt.\r
196 //\r
197 //*****************************************************************************\r
198 uint8_t USB_handleSuspendEvent ()\r
199 {\r
200 //If this device draws power from the host over VBUS, then this event is the signal for software to ensure that\r
201 //no more than 2.5mA is drawn over VBUS. Code can be placed here to do this, or it can be placed in the main loop\r
202 //under ST_ENUM_SUSPENDED (but make sure this handler returns TRUE to wake the main loop, if LPM0 was entered).\r
203 \r
204 return (TRUE); //Return TRUE so that the main loop can adapt.\r
205 }\r
206 \r
207 //*****************************************************************************\r
208 //\r
209 //! USB Host has Resumed this USB Device\r
210 //!\r
211 //! This event indicates that the USB host has resumed this USB device from\r
212 //! suspend mode. If the device is bus-powered, it is no longer restricted in\r
213 //! the amount of power it can draw from VBUS. The API automatically re-enables\r
214 //! any circuitry in the MSP430’s USB module that was disabled during suspend.\r
215 //! The application can use this handler to re-enable other circuitry as well.\r
216 //!\r
217 //! Since this event is associated with a change in state, it's a good\r
218 //! practice to return TRUE so the main loop can adapt.\r
219 //\r
220 //*****************************************************************************\r
221 uint8_t USB_handleResumeEvent ()\r
222 {\r
223 //If functionality was shut off during USB_handleSuspendEvent(), it can be re-enabled here.\r
224 \r
225 return (TRUE); //Since this event is associated with a change in state, it's a good practice to return TRUE so the main loop\r
226 //can adapt.\r
227 }\r
228 \r
229 //*****************************************************************************\r
230 //\r
231 //! Device has Become Enumerated\r
232 //!\r
233 //! This event indicates that the device has just become enumerated. This\r
234 //! corresponds with a state change to ST_ENUM_ACTIVE.\r
235 //!\r
236 //! Since this event is associated with a change in state, it's a good\r
237 //! practice to return TRUE so the main loop can adapt.\r
238 //\r
239 //*****************************************************************************\r
240 uint8_t USB_handleEnumCompleteEvent ()\r
241 {\r
242 //Typically there's no need to place code here -- the main loop shifts to ST_ENUM_ACTIVE.\r
243 \r
244 return (TRUE); //Since this event is associated with a change in state, it's a good practice to return TRUE so the main loop\r
245 //can adapt.\r
246 }\r
247 \r
248 #ifdef USE_TIMER_FOR_RESUME\r
249 //*****************************************************************************\r
250 //\r
251 //! USB_resume requires a "wait" for XT2 crystal stabilization\r
252 //!\r
253 //! When this function gets executed, it indicates that a USB_resume is in\r
254 //! progress and the USB stack requires the application to use a timer to wait\r
255 //! until the XT2 crystal has stabilized. See crystal specific datasheet for\r
256 //! delay times. When the crystal has stabilized the application needs to call\r
257 //! the function USB_enable_PLL() to allow resume to continue.\r
258 //\r
259 //*****************************************************************************\r
260 void USB_handleCrystalStartedEvent(void)\r
261 {\r
262 \r
263 }\r
264 //*****************************************************************************\r
265 //\r
266 //! USB_resume requires a "wait" for USB PLL stabilization\r
267 //!\r
268 //! When this function gets executed, it indicates that a USB_resume is in\r
269 //! progress and the USB stack requires the application to use a timer to wait\r
270 //! until the USB PLL has stabilized. See crystal specific datasheet for\r
271 //! delay times. When the PLL has stabilized the application needs to call\r
272 //! the function USB_enable_final() to allow resume to continue.\r
273 //\r
274 //*****************************************************************************\r
275 void USB_handlePLLStartedEvent(void)\r
276 {\r
277 \r
278 }\r
279 #endif\r
280 \r
281 //*****************************************************************************\r
282 //\r
283 //! Indicates Data has been Received for CDC Interface\r
284 //!\r
285 //! \param intfNum is which HID interface is being used.\r
286 //!\r
287 //! This event indicates that data has been received for CDC interface intfNum\r
288 //! with no receive operation underway. Effectively, the API doesn’t know what\r
289 //! to do with this data and is asking for instructions. The application can\r
290 //! respond by either initiating a receive operation or rejecting the data.\r
291 //! Until one of these is performed, USB data reception cannot continue; any\r
292 //! packets received from the USB host will be NAK’ed.\r
293 //!\r
294 //! Therefore, this event should be handled quickly. A receive operation cannot\r
295 //! be started directly out of this event, since USBCDC_receiveData() cannot be\r
296 //! called from the event handlers. However, the handler can set a flag for\r
297 //! main() to begin the receive operation. After this function exits, a call to\r
298 //! USBCDC_intfStatus() for this CDC interface will return kUSBDataWaiting.\r
299 //!\r
300 //! If the application is written so that a receive operation is always begun\r
301 //! prior to data arriving from the host, this event will never occur. The\r
302 //! software designer generally has a choice of whether to use this event as\r
303 //! part of code flow (initiating receive operations after data is received), or\r
304 //! to always keep a receive operation open in case data arrives. (See Sec. 11\r
305 //! of \e "Programmer’s Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" for\r
306 //! more discussion.)\r
307 //!\r
308 //! Return TRUE to wake up after data was received.\r
309 //\r
310 //*****************************************************************************\r
311 #ifdef _CDC_\r
312 \r
313 uint8_t USBCDC_handleDataReceived (uint8_t intfNum)\r
314 {\r
315 //TO DO: You can place your code here\r
316 \r
317 return (FALSE); //return TRUE to wake up after data was received\r
318 }\r
319 \r
320 //*****************************************************************************\r
321 //\r
322 //! Send Operation on CDC Interface has Completed\r
323 //!\r
324 //! \param intfNum is which HID interface is being used.\r
325 //!\r
326 //!\r
327 //! This event indicates that a send operation on CDC interface intfNum has just\r
328 //! been completed.\r
329 //!\r
330 //! In applications sending a series of data blocks, the designer may wish\r
331 //! to use this event to trigger another send operation. This cannot be done\r
332 //! directly out of this event, since USBCDC_sendData() cannot be called\r
333 //! from the event handlers. However, the handler can set a flag for main()\r
334 //! to begin the operation.\r
335 //!\r
336 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
337 //! interrupt).\r
338 //\r
339 //*****************************************************************************\r
340 uint8_t USBCDC_handleSendCompleted (uint8_t intfNum)\r
341 {\r
342 //TO DO: You can place your code here\r
343 \r
344 // Signal I2C state machine that USB send operation has just been completed.\r
345 extern volatile unsigned char bDataSendCompleted_event[]; // data send completed event\r
346 bDataSendCompleted_event[intfNum] = TRUE;\r
347 \r
348 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt)\r
349 }\r
350 \r
351 //*****************************************************************************\r
352 //\r
353 //! Receive Operation on CDC Interface has Completed\r
354 //!\r
355 //! \param intfNum is which HID interface is being used.\r
356 //!\r
357 //! This event indicates that a receive operation on CDC interface intfNum has\r
358 //! just been completed, and the data is therefore available in the user buffer\r
359 //! assigned when the call was made to USBCDC_receiveData(). If this event\r
360 //! occurs, it means that the entire buffer is full, according to the size value\r
361 //! that was requested.\r
362 //!\r
363 //! The designer may wish to use this event to trigger another receive\r
364 //! operation. This cannot be done directly out of this event, since\r
365 //! USBCDC_receiveData() cannot be called from the event handlers. However, the\r
366 //! handler can set a flag for main() to begin the operation.\r
367 //!\r
368 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
369 //! interrupt).\r
370 //\r
371 //*****************************************************************************\r
372 uint8_t USBCDC_handleReceiveCompleted (uint8_t intfNum)\r
373 {\r
374 //TO DO: You can place your code here\r
375 \r
376 // Signal I2C state machine that USB receive operation has just completed.\r
377 extern volatile unsigned char bDataReceiveCompleted_event[];\r
378 bDataReceiveCompleted_event[intfNum] = TRUE;\r
379 \r
380 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt)\r
381 }\r
382 \r
383 //*****************************************************************************\r
384 //\r
385 //! New Line Coding Parameters have been Received from the Host\r
386 //!\r
387 //! \param intfNum is which CDC interface is being used.\r
388 //! \param lBaudrate had COMport baud rate values such as 9600, 19200 etc\r
389 //!\r
390 //! This event indicates that a SetLineCoding request has been received from the\r
391 //! host and new values for baud rate are available.\r
392 //!\r
393 //! The application can use the new baud rate value to re-configure the Uart\r
394 //! in the case of a usb to uart bridge application. See C7 Example for\r
395 //! details.\r
396 //!\r
397 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
398 //! interrupt).\r
399 //\r
400 //*****************************************************************************\r
401 uint8_t USBCDC_handleSetLineCoding (uint8_t intfNum, uint32_t lBaudrate)\r
402 {\r
403 //TO DO: You can place your code here\r
404 BaudrateSelect(lBaudrate);\r
405 \r
406 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt)\r
407 }\r
408 \r
409 //*****************************************************************************\r
410 //\r
411 //! New Line State has been Received from the Host\r
412 //!\r
413 //! \param intfNum is which CDC interface is being used.\r
414 //! \param lineState BIT0 is DTR_PRESENT(1) or DTR_NOT_PRESENT(0)\r
415 //! BIT1 is RTS_PRESETNT(1) or RTS_NOT_PRESENT(0)\r
416 //!\r
417 //! This event indicates that a SetControlLineState request has been received\r
418 //! from the host and new values for RTS are available.\r
419 //!\r
420 //! The application can use the new RTS value to flow off the uart. See C7\r
421 //! Example for details.\r
422 //!\r
423 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
424 //! interrupt).\r
425 //\r
426 //*****************************************************************************\r
427 uint8_t USBCDC_handleSetControlLineState (uint8_t intfNum, uint8_t lineState)\r
428 {\r
429 return FALSE;\r
430 }\r
431 \r
432 #endif //_CDC_\r
433 \r
434 #ifdef _HID_\r
435 \r
436 //*****************************************************************************\r
437 //\r
438 //! Data has been Received for HID Interface\r
439 //!\r
440 //! \param intfNum is which HID interface is being used.\r
441 //!\r
442 //! This event applies to HID-Datapipe only, as opposed to HID-Traditional.\r
443 //! It indicates that data has been received for HID interface intfNum with no\r
444 //! receive operation underway. Effectively, the API doesn’t know what to do\r
445 //! with this data and is asking for instructions. The application can respond\r
446 //! by either initiating a receive operation or rejecting the data. Until one of\r
447 //! these is performed, USB data reception cannot continue; any packets received\r
448 //! from the USB host will be NAK’ed.\r
449 //!\r
450 //! Therefore, this event should be handled quickly. A receive operation cannot\r
451 //! be started directly out of this event, since USBHID_receiveData() cannot be\r
452 //! called from the event handlers. However, the handler can set a flag for\r
453 //! main() to begin the receive operation. After this function exits, a call to\r
454 //! USBHID_intfStatus() for this HID interface will return kUSBDataWaiting.\r
455 //!\r
456 //! If the application is written so that a receive operation is always begun\r
457 //! prior to data arriving from the host, this event will never occur. The\r
458 //! software designer generally has a choice of whether to use this event as\r
459 //! part of code flow (initiating receive operations after data is received), or\r
460 //! to always keep a receive operation open in case data arrives. (See Sec. 11\r
461 //! of \e "Programmer’s Guide: MSP430 USB API Stack for CDC/PHDC/HID/MSC" more\r
462 //! discussion.)\r
463 //!\r
464 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
465 //! interrupt).\r
466 //\r
467 //*****************************************************************************\r
468 uint8_t USBHID_handleDataReceived (uint8_t intfNum)\r
469 {\r
470 //TO DO: You can place your code here\r
471 \r
472 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt)\r
473 }\r
474 \r
475 //*****************************************************************************\r
476 //\r
477 //! Send Operation on Data Interface has been Completed\r
478 //!\r
479 //! \param intfNum is which HID interface is being used.\r
480 //!\r
481 //! This event applies to HID-Datapipe only, as opposed to HID-Traditional. It\r
482 //! indicates that a send operation on data interface intfNum has just been\r
483 //! completed.\r
484 //!\r
485 //! In applications sending a series of large blocks of data, the designer may\r
486 //! wish to use this event to trigger another send operation. This cannot be\r
487 //! done directly out of this event, since USBHID_sendData() cannot be called\r
488 //! from the event handlers. However, the handler can set a flag for main() to\r
489 //! begin the operation.\r
490 //!\r
491 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
492 //! interrupt).\r
493 //\r
494 //*****************************************************************************\r
495 uint8_t USBHID_handleSendCompleted (uint8_t intfNum)\r
496 {\r
497 //TO DO: You can place your code here\r
498 extern volatile unsigned char bDataSendCompleted_event[]; // data send completed event\r
499 bDataSendCompleted_event[intfNum] = TRUE;\r
500 \r
501 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt)\r
502 }\r
503 \r
504 //*****************************************************************************\r
505 //\r
506 //! Receive Operation has been Completed\r
507 //!\r
508 //! \param intfNum is which HID interface is being used.\r
509 //!\r
510 //! This event applies to HID-Datapipe only, as opposed to HID-Traditional. It\r
511 //! indicates that a receive operation on HID interface intfNum has just been\r
512 //! completed, and the data is therefore available in the user buffer assigned\r
513 //! when the call was made to USBHID_receiveData(). If this event occurs, it\r
514 //! means that the entire buffer is full, according to the size value that was\r
515 //! requested.\r
516 //!\r
517 //! The designer may wish to use this event to trigger another receive\r
518 //! operation. This cannot be done directly out of this event, since\r
519 //! USBHID_receiveData() cannot be called from the event handlers. However, the\r
520 //! handler can set a flag for main() to begin the operation.\r
521 //!\r
522 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
523 //! interrupt).\r
524 //\r
525 //*****************************************************************************\r
526 uint8_t USBHID_handleReceiveCompleted (uint8_t intfNum)\r
527 {\r
528 //TO DO: You can place your code here\r
529 extern volatile unsigned char bDataReceiveCompleted_event[];\r
530 bDataReceiveCompleted_event[intfNum] = TRUE;\r
531 \r
532 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt)\r
533 }\r
534 \r
535 //*****************************************************************************\r
536 //\r
537 //! Set_Protocol Request Received from the Host\r
538 //!\r
539 //! \param protocol indicates HID_BOOT_PROTOCOL or HID_REPORT_PROTOCOL\r
540 //! \param intfNum is which HID interface is being used.\r
541 //!\r
542 //! This event applies to HID Traditional only. It indicates that the host has\r
543 //! requested a change in the HID protocol – from Boot to Standard or Standard\r
544 //! to Boot. An application that maintains separate reports for boot and\r
545 //! standard protocols can switch to the appropriate report upon receiving this\r
546 //! request. The protocol field is either HID_BOOT_PROTOCOL or\r
547 //! HID_REPORT_PROTOCOL.\r
548 //!\r
549 //! Returns FALSE to go asleep after interrupt (in the case the CPU slept before\r
550 //! interrupt).\r
551 //\r
552 //*****************************************************************************\r
553 uint8_t USBHID_handleBootProtocol (uint8_t protocol, uint8_t intfnum)\r
554 {\r
555 return (FALSE);\r
556 }\r
557 \r
558 //*****************************************************************************\r
559 //\r
560 //! Set_Report request Received from the Host\r
561 //!\r
562 //! \param reportType is either USB_REQ_HID_INPUT, USB_REQ_HID_OUTPUT or\r
563 //! USB_REQ_HID_FEATURE\r
564 //! \param reportId is values defined by report descriptor\r
565 //! \param dataLength is length of report\r
566 //! \param intfNum is which HID interface is being used.\r
567 //!\r
568 //! This event indicates that a Set_Report request was received from the\r
569 //! host. The application needs to supply a buffer to retrieve the report data\r
570 //! that will be sent as part of this request. This handler is passed the\r
571 //! reportType, reportId, the length of data phase as well as the interface\r
572 //! number.\r
573 //\r
574 //*****************************************************************************\r
575 uint8_t *USBHID_handleEP0SetReport (uint8_t reportType, uint8_t reportId,\r
576 uint16_t dataLength,\r
577 uint8_t intfnum)\r
578 {\r
579 switch (reportType) {\r
580 case USB_REQ_HID_INPUT:\r
581 //Return pointer to input Report Buffer\r
582 return (0);\r
583 case USB_REQ_HID_OUTPUT:\r
584 //Return pointer to output Report Buffer\r
585 return (0);\r
586 \r
587 case USB_REQ_HID_FEATURE:\r
588 //Return pointer to feature Report Buffer\r
589 return (0);\r
590 \r
591 default:\r
592 return (0);\r
593 }\r
594 }\r
595 \r
596 //*****************************************************************************\r
597 //\r
598 //! Data as Part of Set_Report Request was Received from the Host\r
599 //!\r
600 //! \param intfNum is which HID interface is being used.\r
601 //!\r
602 //! This event indicates that data as part of Set_Report request was received\r
603 //! from the host. If the application supplied a buffer as part of\r
604 //! USBHID_handleEP0SetReport, then this buffer will contain the Set Report data.\r
605 //!\r
606 //! Returns TRUE to wake up after data was received.\r
607 //\r
608 //*****************************************************************************\r
609 uint8_t USBHID_handleEP0SetReportDataAvailable (uint8_t intfnum)\r
610 {\r
611 //Process received data based on currentReportType\r
612 return (TRUE);\r
613 }\r
614 \r
615 //*****************************************************************************\r
616 //\r
617 //! Get_Report Request was Received from the Host\r
618 //!\r
619 //! \param reportType is either USB_REQ_HID_INPUT, USB_REQ_HID_OUTPUT or\r
620 //! USB_REQ_HID_FEATURE\r
621 //! \param reportId is values defined by report descriptor\r
622 //! \param requestedLength is length of report\r
623 //! \param intfNum is which HID interface is being used.\r
624 //!\r
625 //! This event indicates that a Get_Report request was received from the host.\r
626 //! The application can supply a buffer of data that will be sent to the host.\r
627 //! This handler is passed the reportType, reportId, the requested length as\r
628 //! well as the interface number.\r
629 //!\r
630 //! Returns TRUE to wake up after data was received.\r
631 //\r
632 //*****************************************************************************\r
633 uint8_t *USBHID_handleEP0GetReport (uint8_t reportType, uint8_t reportId,\r
634 uint16_t requestedLength,\r
635 uint8_t intfnum)\r
636 {\r
637 //report data should be ready in buffers for Get Report.\r
638 switch (reportType) {\r
639 case USB_REQ_HID_INPUT:\r
640 //Return pointer to input Report Buffer\r
641 return (0);\r
642 case USB_REQ_HID_OUTPUT:\r
643 //Return pointer to OUTput Report Buffer\r
644 return (0);\r
645 case USB_REQ_HID_FEATURE:\r
646 //Return pointer to FEATURE Report Buffer\r
647 return (0);\r
648 default:\r
649 return (0);\r
650 }\r
651 }\r
652 \r
653 #endif //_HID_\r
654 \r
655 #ifdef _MSC_\r
656 //*****************************************************************************\r
657 //\r
658 //! API Requests a Buffer\r
659 //!\r
660 //! This event occurs when the API requests a buffer. Immediately prior to this,\r
661 //! the API sets the operation field of the USBMSC_RWBuf_Info structure\r
662 //! corresponding with the request, and also clears the low-power-mode bits of\r
663 //! the MCU’s status register to ensure the CPU remains awake to process the\r
664 //! buffer after the event occurs.\r
665 //!\r
666 //! NOTE: This means the return value of this event has no effect; the CPU will <-- BECAUSE OF THIS...\r
667 //! remain awake even if this function returns FALSE.\r
668 //\r
669 //*****************************************************************************\r
670 uint8_t USBMSC_handleBufferEvent (void)\r
671 {\r
672 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before interrupt) <-- ...LOSE COMMENT???\r
673 }\r
674 \r
675 #endif //_MSC_\r
676 \r
677 #ifdef _PHDC_\r
678 \r
679 //*****************************************************************************\r
680 //\r
681 //! Data Received\r
682 //!\r
683 //! \param intfNum is which interface is being used.\r
684 //!\r
685 //! This event indicates that data has been received for interface \b intfNum,\r
686 //! but no data receive operation is underway.\r
687 //!\r
688 //! Returns TRUE to keep CPU awake, or return FALSE to go asleep after interrupt\r
689 //! (in the case the CPU slept before interrupt).\r
690 //\r
691 //*****************************************************************************\r
692 uint8_t USBPHDC_handleDataReceived (uint8_t intfNum)\r
693 {\r
694 //TO DO: You can place your code here\r
695 \r
696 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before\r
697 //interrupt)\r
698 }\r
699 \r
700 //*****************************************************************************\r
701 //\r
702 //! Send Completed\r
703 //!\r
704 //! \param intfNum is which interface is being used.\r
705 //!\r
706 //! This event indicates that a send operation on interface \b intfNum has just\r
707 //! been completed.\r
708 //!\r
709 //! Returns TRUE to keep CPU awake, or return FALSE to go asleep after interrupt\r
710 //! (in the case the CPU slept before interrupt).\r
711 //\r
712 //*****************************************************************************\r
713 uint8_t USBPHDC_handleSendCompleted (uint8_t intfNum)\r
714 {\r
715 //TO DO: You can place your code here\r
716 \r
717 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before\r
718 //interrupt)\r
719 }\r
720 \r
721 //*****************************************************************************\r
722 //\r
723 //! Receive Completed\r
724 //!\r
725 //! \param intfNum is which interface is being used.\r
726 //!\r
727 //! This event indicates that a receive operation on interface \b intfNum has\r
728 //! just been completed.\r
729 //!\r
730 //! Returns TRUE to keep CPU awake, or return FALSE to go asleep after interrupt\r
731 //! (in the case the CPU slept before interrupt).\r
732 //\r
733 //*****************************************************************************\r
734 uint8_t USBPHDC_handleReceiveCompleted (uint8_t intfNum)\r
735 {\r
736 //TO DO: You can place your code here\r
737 \r
738 return (FALSE); //return FALSE to go asleep after interrupt (in the case the CPU slept before\r
739 //interrupt)\r
740 }\r
741 \r
742 #endif //_PHDC_\r
743 \r
744 /*----------------------------------------------------------------------------+\r
745 | End of source file |\r
746 +----------------------------------------------------------------------------*/\r
747 /*------------------------ Nothing Below This Line --------------------------*/\r
748 //Released_Version_4_10_02\r