1 Atmel AVR4920: ASF - USB Device Stack - Compliance and Performance Figures Features Compliance to USB Chapters 8 and 9 - Classes: HID, MSC, CDC, PHDC Interoperability: OS, classes, self- and bus-powered Performance figures - Interrupt latency measurement - Code and RAM footprint - Low, full, and high speed - USB power consumption Atmel Microcontrollers Application Note 1 Introduction Atmel has always provided a USB device stack that supports AVR products with a USB hardware interface. The Atmel AVR UC3 A and B series microcontrollers are supported with a specific USB device stack in the Atmel AVR Software Framework (ASF). Since ASF version 2, a new USB device stack is delivered to support all AVR products. This document describes the validation tests used to check USB 2.0 compliance for this new USB device stack and the performance tests used to provide information about stack capabilities. Rev.
2 2 Abbreviations ASF CDC FS HID HS LS MSC OS PHDC UDC UDD UDI USB AVR Software Framework Communication device class USB full speed Human interface device USB high speed USB low speed Mass storage class Operating system Peripheral health device class USB device controller USB device descriptor USB device interface Universal serial bus 2 Atmel AVR4920
3 Atmel AVR Overview This application note relies on the AVR4900: ASF - USB Device Stack application note, which should be read first to get information on the USB device stack implementation. This document includes results concerning validation and performance: The validation tests used to check USB 2.0 compliance The performance tests used to give information about USB device stack capabilities 3
4 4 USB Compliance 4.1 USB compliance tests Chapter 8 tests The chapter 8 tests validate the UDD module of the USB device stack. The chapter 9 tests validate the UDD and UDC modules of the USB device stack. The chapter 9 class tests validate the UDI modules of the USB device stack. USB chapter 8 compliance of USB device drivers (UDD) is performed using the Ch8ck v2.00 tool from Testronic Laboratories Chapter 9 tests Chapter 9 compliance Chapter 9 classes High speed test feature USB chapter 9 compliance is performed using the USB 2.0 Command Verifier tool from the USB Implementers Forum (usb.org). All LS/FS/HS modes are exercised on a USB golden tree given as reference. The aim of the class compliance tests is to verify the class implementation (UDI modules). USB class compliance of HID, PHDC in FS mode, and MSC in FS/HS modes is performed using the USB 2.0 Command Verifier tool from the USB Implementers Forum (usb.org). High speed test feature implementation (Test J, Test K, Test SE0_NAK, and Test PACKET) is performed using the High Speed Electrical Test Tool from the USB Implementers Forum (usb.org). 4 Atmel AVR4920
5 Atmel AVR USB interoperability The interoperability tests validate the compliance and robustness of the USB device stack for various types of USB host operating systems in both bus- and self-powered modes. These tests are performed using the most common USB device classes. 5.1 Operating systems Microsoft Windows XP SP3, Windows Vista, Windows 7 (32-bit) Apple Mac OS X Ubuntu 8.04 and Ubuntu 9 OpenSUSE 11.1 Fedora 9 and Fedora Power modes and wake up Plug/unplug robustness test in USB self-powered mode Plug/unplug robustness test in USB bus-powered mode Remote wake up feature in high, full and low speed modes 5.3 USB classes HID mouse HID keyboard MSC CDC 5
6 6 Performance figures USB device stack performance is evaluated on various parameters: The footprint; that is, the total size of code and RAM memory used to run the USB device stack Timing performance Transfer rate on various USB device classes Power consumption 6.1 Footprint Table 6-1. USB device example code and RAM size. Example HID device mouse full speed CDC device full speed MSC device high speed The USB device stack footprint depends on: The AVR core (XMEGA, megaavr, UC3) The USB hardware version The USB class The compiler and the optimization level These parameters may result in many values for the footprint, but on average the USB device stack does not exceed 10KB of flash and 1KB of RAM when using a high level of compiler optimization. All the examples shown in Table 6-1 have been performed using: IAR Embedded Workbench for 32-bit AVR 3.30 and 8-bit AVR 6.10, with high size-optimization level ASF with the following modules: sleep management service, interrupt management, startup, external flash memory control, and others Part USB device stack Code size (KB) RAM size (KB) Code size (KB) Full example RAM size (KB) ATxmega256A3BU AT32UC3A AT32UC3C ATxmega256A3BU AT32UC3C ATxmega256A3BU AT32UC3A AT32UC3C AT32UC3A Interrupt timing All USB events are managed by one or two USB interrupt vectors. Each USB event performs an interrupt, and only one event is decoded by the interrupt process. Thus, there is no waiting loop in the USB interrupt routine. 6 Atmel AVR4920
7 Atmel AVR4920 The timing to process an interrupt depends on the compilation level and the USB interrupt source (USB reset, suspend, end of transfer, etc.). However, this timing does not exceed 100µs with a high optimization level and a 12MHz CPU frequency. For more information about USB interrupt behavior and configuration, see the section entitled Behavior in the AVR4900: ASF USB Device Stack application note. 6.3 Transfer rate Atmel AVR device USB interfaces support all USB transfer types. The interfaces are able to support the maximum rate allowed using USB DMA. The speed limit for each transfer type is given by the USB specification in Table 6-2. Table 6-2. USB transfer type and limits. Maximum bandwidth (MB/s) LS FS HS Control Interrupt (1) Bulk Isochronous Note: 1. One transaction per start of frame. However, the final speed performance of a class depends on: Class protocol overhead Source/destination speed USB host performance The MSC and CDC classes use the USB bulk transfer type, which allows the high performance of USB device hardware and the associated USB firmware stack to be easily measured. All the tests are done with a USB host with no latency in order to measure the full performance limit of the USB device MSC The mass storage class (MSC) uses the USB bulk transfer. The MSC specification includes a protocol overhead, which reduces the useful data transfer rate. This reduction is fully dependent on the useful data size requested by a MSC read/write command. The useful data transfer rate limitation is shown by the MSC possibility patterns in Figure 6-1 and Figure 6-2. The MSC protocol is managed by software on AVR products, thus speed performance is dependent on CPU frequency. This is shown by the patterns for the speeds measured with different CPU frequencies in Figure 6-1 and Figure 6-2. A memory based on internal RAM gives the real limit of the MSC USB device by removing the programming latency inherent in mass storage devices. However, the speed is mainly reduced by memory interface limitations and memory performance. The SD High Speed card and MMC Plus card, which use a memory card interface (MCI), show the dependency of the interface and the memory (Figure 6-1, Figure 6-2). NOTE The firmware used for the following measurements is compiled using the GCC or IAR compiler with a high optimization level. 7
8 Figure 6-1. MSC speed limits for full speed Speed (KB/s) Useful data / command (KB) MSC possibility AT32UC3A0, CPU 12MHz on RAM AT32UC3A3, CPU 66MHz on SD card High Speed ATxmega256A3BU, CPU 24MHz on RAM NOTE Read and write speed limits are the same. Figure 6-2. MSC speed limits for high speed Speed (MB/s) MSC possibility Useful data / command (KB) AT32UC3A3, CPU 66MHz on RAM AT32UC3A3, CPU 48MHz on RAM AT32UC3A3, CPU 12MHz on RAM AT32UC3A3, CPU 66MHz on MCI - MMC Plus card AT32UC3A3, CPU 66MHz on MCI - SD High Speed card NOTE 8 Atmel AVR4920 Read and write speed limits are the same.
9 Atmel AVR CDC NOTE The communication class device uses the USB bulk transfer, and does not include a protocol to transfer data. Thus, the CDC limitation is the bulk limitation shown by the CDC possibility patterns in Figure 6-3. However, the CDC implementation in the USB device stack requires control of the data flow between two different flow behaviors (for example, USB and UART) and can limit the actual speed. The ASF CDC implementation provides two interfaces to send or receive data on a USB line. The first is a byte access with the putc and getc functions, and the second is a data array access with the ReadBuf and WriteBuf functions to target the maximum of full speed. The maximum speed performance of these accesses is shown in Figure 6-3, Figure 6-4 and Figure 6-5. The CDC class can be used as a bridge between UART and USB connections. In this case, the speed limitation is the UART baud rate. The firmware used for the following measures is compiled using the GCC or IAR compiler with a high optimization level. Figure 6-3. CDC speed limits for full speed on an Atmel AT32UC3A (CDC possibility) 1200 ReadBuf WriteBuf 1000 Speed (KB/s) Putc 400 Getc CPU Freq. (MHz) 9
10 Figure 6-4. CDC speed limits for full speed on an Atmel ATxmega256A3BU CDC possibility WriteBuf ReadBuf Speed (KB/s) Putc Getc CPU Freq. (MHz) Figure 6-5. CDC speed limits for high speed on Atmel AT32UC3A ReadBuf WriteBuf 5 Speed (MB/s) Putc CPU Freq. (MHz) Getc 10 Atmel AVR4920
11 Atmel AVR Power consumption Atmel AVR products have been designed to support a USB device application in bus power mode. In suspend mode, the bus-powered application needs to reduce its power consumption to be less than 2.5mA at 5V. All Atmel UC3 products support the static sleep mode in USB suspend mode, which has a current consumption of less than 1mA at 3.3V. All Atmel XMEGA products support the power down sleep mode in USB suspend mode, which has a current consumption of less than 0.5mA at 3.3V. 11
12 7 Table of contents Features Introduction Abbreviations Overview USB Compliance USB compliance tests Chapter 8 tests Chapter 9 tests High speed test feature USB interoperability Operating systems Power modes and wake up USB classes Performance figures Footprint Interrupt timing Transfer rate MSC CDC Power consumption Table of contents Atmel AVR4920
13 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, megaavr, XMEGA, and others are registered trademarks or trademarks of Atmel Corporation or its subsidiaries. Windows and others are registered trademarks or trademarks of Microsoft Corporation in U.S. and or other countries. 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.