Atmel AVR4921: ASF - USB Device Stack Differences between ASF V1 and V2. 8-bit Atmel Microcontrollers. Application Note. Features.

Transcription

1 Atmel AVR4921: ASF - USB Device Stack Differences between ASF V1 and V2 Features Advantages Implementation differences Integration Migration from stack V1 to stack V2 8-bit Atmel Microcontrollers Application Note 1 Introduction Atmel has always provided a USB device stack to support AVR products with a USB hardware interface. The Atmel AT32UC3A and Atmel AT32UC3B products are supported in Atmel AVR Software Framework (ASF) version 1 (V1) with a specific USB device stack. Since ASF version 2 (V2), a new USB device stack has been delivered to support all AVR products. The aim of this document is to explain the implementation advantages of the new USB device stack for AT32UC3A and AT32UC3B MCUs as well as the major differences from the former USB device stack. NOTE In the rest of the document, the former USB stack will be referred to as USB Device stack V1, while new stack will be referred to as USB device stack V2. Rev.

2 2 Abbreviations ASF USB AVR Software Framework Universal serial bus 2 Atmel AVR4921

3 Atmel AVR Advantages The following list shows the advantages of USB device stack V2 over USB device stack V1: All Atmel AVR products are supported: Atmel megaavr, Atmel AVR XMEGA, and Atmel AVR UC3 Eases migration between all AVR products DMA is used when applicable for all USB transfers Increases speed and reduces CPU usage The stack is managed only by interrupt Reduces latency Avoids any task scheduler The implementation supports all AVR power reduction features Helps to create a very low-power device All USB protocol errors are taken into account Robust software solution Better software architecture Easiest to use No USB-specific code in the application Reduces development time Various detailed application notes are available Reduces development time A new USB class implementation is supported Provides peripheral health device class (PHDC) The V2 and V1 footprints (code/ram size) are the same Does not require a larger memory target space All classes available in USB device stack V1 will be supported by USB device stack V2. Table 3-1. USB device class status. Class ASF V1 status ASF V2 status Template No Q Composite (HIDs, CDC, MSC) No ASF2.3.2 HID mouse Available ASF2.3.2 HID keyboard No ASF2.3.2 HID generic No ASF2.3.2 Mass storage (MSC) Available ASF2.3.2 Communication (CDC) Available ASF2.3.2 Personal health device (PHDC) No ASF2.3.2 Audio Available Q Device firmware upgrade (DFU) Available Q

4 4 Implementation 4.1 File organization USB device stack V1 The specific USB device stack for Atmel AVR UC3 A and Atmel AVR UC3 B 32-bit products is prefixed by a _asf_v1 folder in the ASF package, and is stored in the following folders: File USB constant defines usb_ids.h Path avr32/services/usb/_asf_v1/class/ USB device core files avr32/drivers/usbb/_asf_v1/enum/ usb_task.c/h device/usb_device_task.c/h device/usb_standard_request.c/h Class protocol files avr32/services/usb/_asf_v1/class/foo/ foo.h Class and USB descriptor files duplicated in application folder device_class_task.c/h usb_specific_request.c/h usb_descriptors.c/h Driver files for AVR UC3 avr32/drivers/usbb/_asf_v1/ usb_drv.c/h usbb.h Configuration files usb_conf.h (This configuration file is mandatory) USB device stack V2 The USB device stack V2 for all AVR products is stored in the following folders: 4 Atmel AVR4921 File USB constant defines usb_protocol.h (from usb.org) usb_atmel.h (from Atmel) USB device core files udc.c/h udc_desc.h udi.h udd.h Class protocol files usb_protocol_foo.h Class and USB descriptor files Path common/services/usb/ common/services/usb/udc/ common/services/usb/class/foo/ common/services/usb/class/foo/device/

5 udi_foo.c/h udi_foo_desc.c udi_foo_conf.h Driver files for AVR UC3 avr32/drivers/ usbb/usbb_device.c/h usbb/usbb_otg.h usbc/usbc_device.c/h usbc/usbc_otg.h Driver files for AVR XMEGA xmega/drivers/ usb/usb_device.c/h Configuration files usb_conf.h (This configuration file is mandatory) Atmel AVR Integration USB device stack V1 The USB device stack V1 requires the initialization and scheduling of USB core tasks and class tasks in the main code section. It also requires the class implementation and USB descriptors in the user application: Main code section // Initialize USB clock (on PLL1) pcl_configure_usb_clock(); // Initialize USB task usb_task_init(); // Initialize device mouse USB task device_mouse_hid_task_init(); // No OS here. Need to call each task in round-robin mode. while (true) { usb_task(); device_mouse_hid_task(); } Class implementation and user interface, for example: device_class_task.c/h Class setup implementation: usb_specific_request.c/h USB descriptors: usb_descriptors.c/h USB device stack V2 The USB device stack V2 requires the clock manager software module (/common/services/clock) and sleep manager software module (/common/services/sleepmgr) from ASF. Intialization of the clock, sleep manager and 5

6 USB services is required in the main code section. The class implementation and USB descriptors are provided by ASF, and require only the definition of the user interface. For more information concerning integration, refer to the Atmel AVR4903 to AVR4909 USB device class application notes. Main code section // Initialize the sleep manager service sleepmgr_init(); // Initialize the clock service sysclk_init(); // Enable USB Stack Device udc_start(); User interface only, for example: ui.c/h 6 Atmel AVR4921

7 5 Migration from stack V1 to stack V2 Atmel AVR4921 The USB device stack V2 requires the clock manager software module and sleep manager software module from ASF V2. In the USB device stack V1 applications, however, clock configuration and sleep mode control are done by the user application code, which calls UC3 clock and sleep drivers. Because of this fundamental difference between stack V1 and stack V2, there can be no straightforward migration. It is recommended to start again from existing V2 example projects. 7

8 6 Conclusion Moving to USB device stack V2 in ASF offers greater robustness as well as ease of use for both beginners and advanced users when developing firmware with USB. It also adds performance in managing low-level USB, and takes advantage of all USB hardware features implemented in Atmel AVR products. The stack provides full support of many USB classes, with example projects in ASF and Atmel AVR Studio 5. The stack allows the sharing of code among Atmel megaavr, AVR XMEGA and AVR UC3 products. Maintenance and portability from one architecture to another is also improved. 8 Atmel AVR4921

9 Atmel AVR Table of contents Features Introduction Abbreviations Advantages Implementation File organization USB device stack V USB device stack V Integration USB device stack V USB device stack V Migration from stack V1 to stack V Conclusion Table of contents

10 Atmel Corporation 2325 Orchard Parkway San Jose, CA USA Tel: (+1)(408) Fax: (+1)(408) Atmel Asia Limited Unit 01-5 & 16, 19F BEA Tower, Milennium City Kwun Tong Road Kwun Tong, Kowloon HONG KONG Tel: (+852) Fax: (+852) Atmel Munich GmbH Business Campus Parkring 4 D Garching b. Munich GERMANY Tel: (+49) Fax: (+49) Atmel Japan 9F, Tonetsu Shinkawa Bldg Shinkawa Chou-ku, Tokyo JAPAN Tel: (+81) Fax: (+81) Atmel Corporation. All rights reserved. Atmel, Atmel logo and combinations thereof, AVR, AVR Studio, megaavr, XMEGA, and others are registered trademarks or trademarks of Atmel Corporation or its subsidiaries. Other terms and product names may be trademarks of others. Disclaimer: The information in this document is provided in connection with Atmel products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF SALES LOCATED ON THE ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in, automotive applications. Atmel products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life.