AVR32408 AVR32 AVR23AP ATSTK1000 - Datasheet Archive

 

Features · · · · · Configuring GPIOs in the board setup code GPIO /dev interface GPIO in

 

AVR32408 AVR32408: AVR32 AVR32 AP7 Linux GPIO driver Features · · · · · Configuring GPIOs in the board setup code GPIO /dev interface GPIO in drivers Linux LED framework Linux input system - GPIO keys - GPIO mouse 32-bit Microcontrollers Application Note 1 Introduction This application describes how to use GPIO with Linux on AVR®32AP devices. It gives examples on how to control the GPIO hardware from user-space in an application or from kernel-space in a driver. Rev. 32073A-AVR32-02/08 2 GPIOs on the AVR32 AVR32 A "General Purpose Input/Output" (GPIO) is a flexible software-controlled digital signal. Each GPIO represents a bit connected to a particular pin, or "ball" on Ball Grid Array (BGA) packages. Depending on the hardware, these I/O lines can have different capabilities. The GPIOs on the AVR23AP AVR23AP processors provide the following features: · · · · An input change interrupt enabling level change detection on any I/O line. A glitch filter providing rejection of pulses lower than one-half of clock cycle. Control of the pull-up of the I/O line. Input visibility and output control. The Linux operating system provides a software layer that manages the configuration and I/O operations on GPIOs. This ensures a safe operation, portability and easier handling of the underlying hardware. Access to a GPIO is possible from two places. 1) User-space 2) Kernel-space The access to a GPIO from user-space is slow and therefore not adequate for implementing a bit-banging protocol. Its main purpose is to turn something on or off. A kernel-space access to a GPIO is fast and short interrupt response times can be achieved, thus it is best to implement a protocol here. A GPIO should be configured in the board setup code. Here, we have full control of all the pin settings. For a user-space application and a kernel module it is not possible to configure the following features (it is possible to set them by writing directly to the hardware but it is not recommended to do so): · Control of the I/O line pull-up. · Configuring the glitch filter. These parameters should be set in the board setup code if needed. By default the glitch filters are disabled and the pull-ups are enabled. 3 Configuring GPIOs in the board setup code All needed functions and definitions for setting up GPIOs in the board setup code are listed in the header file portmux.h. This file can be found in the Linux sources in the directory include/asm/arch/. The function at32_select_gpio(unsigned int pin, unsigned long flags) is all we need to configure a GPIO. The pin number can be calculated by using the macros in the file at32ap7000.h or in a similar file if another derivate is used. To select I/O line 0 on the peripheral I/O (PIO) controller B for instance, use the following code to get the pin number for the at32_select_gpio function: GPIO_PIN_PB(0) 2 AVR32408 AVR32408 32073A-AVR32-02/08 AVR32408 AVR32408 For the I/O lines on the other PIO controllers A,C and so forth, use GPIO_PIN_PA(), GPIO_PIN_PC() . Available flags for the at32_select_gpio function are listed in Table 3-1. Table 3-1 Flag AT32_GPIOF_PULLUP Function Enables pull-up if GPIO is configured as input AT32_GPIOF_OUTPUT Configures the GPIO as output AT32_GPIOF_HIGH Sets output pin high AT32_GPIOF_DEGLITCH Enables glitch-filter configured as input when GPIO is More examples on how to set up pins can be found in the setup code of the Atmel boards in the Linux sources under the directory arch/avr32/boards/. Two additional functions are available to configure I/O lines in the board setup code. These are: at32_select_periph(unsigned int pin, unsigned long flags) unsigned int periph, at32_reserve_pin(unsigned int pin) With at32_select_periph the pin function can be set to an on-chip module (e.g SPI, TWI .). The available module functions for each pin are listed in the device datasheet. The pin value of the function represents the I/O line number and can be calculated by using the above mentioned macros. As periph value a definition from the device header file should be used. Each definition represents a module pin function but, for each I/O line, only one out of two module functions is possible (see datasheet for possible selections). As value for the flags field the definitions in Table 3-1 can be used. The at32_reserve_pin function reserves a pin for later use and thus makes the pin unconfigurable. Once an I/O line has been claimed by either at32_select_periph or at32_select_gpio, it can not be used by the other function. This makes it impossible to reconfigure an I/O line by accident. 4 GPIO /dev interface The GPIO dev interface is not in the mainline kernel and will never be there either. This interface is AVR32 AVR32 specific and it is not available on other platforms. This chapter is here because many use this interface already and maybe do not want to switch to another solution. Following solutions are recommended instead of the GPIO /dev interface: · To get input states of a pin to user-space, use the gpio-keys driver. · To set output pins in user-space, use the Linux LED driver. · If you intend to write a bit-banging protocol or need a fast response time to a pin change, write a driver. 3 32073A-AVR32-02/08 The GPIO /dev interface uses the Linux configfs to configure a GPIO from userspace. The configfs is a filesystem-based manager of kernel objects. This file system exists only in RAM and is empty until client modules are loaded. The GPIO /dev driver is such a client. It registers itself with configfs and is visible as sudirectory gpio. The registering is carried out whether configfs is mounted or not, as the filesystem is always there. A GPIO object (sub-directory in /configfs/gpio) can be created or destroyed from user-space with simple file system commands like mkdir and rmdir (removing an object is only possible if there is no symlink to it). Upon creation of a new object, attributes will show up in the directory as files. By reading of and writing to those files, a user-space application can configure GPIOs. The actual I/O is performed on a device file in the /dev directory. This file will be created by the mdev program (if installed; otherwise the device file can be created with the mknod application) upon activation of the GPIO configuration. 4.1 Using the GPIO dev interface The configfs and the GPIO /dev module must be compiled as a module, or into the kernel, to be able to set up GPIOs from user-space. In most cases, these modules are already selected in the kernel configuration and are thus present. The configfs must then be mounted to a dedicated mountpoint. On most systems, this is already done by the startup scripts. If this is not the case, use the following commands to mount the configfs to the directory /config. mkdir /config mount -t configfs config /config If the GPIO /dev driver is present in the kernel, we will find a gpio subdirectory in /config. 4.1.1 Configuration of GPIOs To create a new GPIO object, for instance "leds", we have to create a subdirectory in /config/gpio with the following command: mkdir /config/gpio/leds Now all available attributes of the GPIO object will appear in the /config/gpio/leds directory as files. All files accept ASCII strings as input and deliver a string on a read. Numbers can either be written as a decimal (e.g. 255) or a hexadecimal value (e.g. 0xFF). The attribute files in /config/gpio/leds are: · gpio_id: Selects the Parallel Input/Output controller (PIO). By writing "0" to the file PIOA is selected, by writing a "1" PIOB etc. Check the datasheet for available modules. · pin_mask: Selects pins on the PIO controller configured in gpio_id. Each PIO controller has up to 32 programmable I/O lines. The pins we want to act as GPIO are therefore specified as a 32-bit hexadecimal value. For instance, if you want I/O line 0 to act as GPIO, write 0x00000001 (or 0x1, or just 1) to pin_mask because pin 0 is the least significant bit. If the desired I/O line is already in use by a peripheral (SPI, TWI .), it is not possible to request it as a GPIO. · oe_mask: Selects output or input functionality of pins. If an I/O line was successfully requested as GPIO through the pin_mask file, you can select its functionality by writing to oe_mask. By default the pin is an input. If you want it to 4 AVR32408 AVR32408 32073A-AVR32-02/08 AVR32408 AVR32408 act as an output, set the appropriate bit in the bit-mask and write this value to the file. To configure pin 0 as output, write 0x00000001 to oe_mask. · enabled: Enables the gpio object. Writing "1" to enabled activates the configuration settings of gpio_id, pin_mask and oe_mask. As result a /dev/gpio0 device file will be created. The number of the gpio device may be different if other gpio devices have been created before. A check by running dmesg can help to find the right device. If the device does not appear at all, either your configuration was not correct or the mdev application is not installed. Mdev creates the device files dynamically and is normally installed by default. If you want to control the pins 0-3 as outputs and 4-7 as inputs on PIOB, you can do it like this: echo 1 > /config/gpio/leds/gpio_id # Use PIOB echo 0xff > /config/gpio/leds/pin_mask echo 0x0f > /config/gpio/leds/oe_mask echo 1 > /config/gpio/leds/enabled # Use pins 0-7 # output on pins 0-3, input on pins 4-7 # Create the device It is also possible to create GPIO objects for each single I/O pin instead of one for all. When we want to configure these settings in an application and not from the shell (or a shell script), the following considerations must be taken into account: Configfs expects a write call to store the entire buffer at once. A user-space application should therefore first read the entire file, modify it and then write the entire buffer back. The maximum size of an attribute file is the size of a page (4096 bytes on the AVR32 AVR32, but should always be read out by using a library function as getpagesize() or similar). 4.1.2 Doing I/O on GPIOs After enabling the GPIO object, a device file is used to read status from pins and set the state if it is an output. This interface is binary, thus writing an ASCII bit-mask to it will lead to confusing results. The device file returns four bytes containing the pin state on read and expects the same as write input. 4.1.2.1 Using GPOIs on the shell The echo shell command can also write binary values. Check the man pages for the detailed description. With the echo command, we can set the previously configured output pins "high" by writing 0x0000000F to the device file. The following command does the trick: echo ­ne "\x00\x00\x00\x0F" > /dev/gpio0 To read out the pin state, the use of the commands less or cat is not adequate because these applications expect an ASCII string, so the output is neither readable nor interpretable. For this purpose the dd and hexdump tools are more suitable. To read out the four bytes, use these commands in following constellation: dd bs=4 count=1 if=/dev/gpio0 2> /dev/zero | hexdump The dd program reads out the four bytes (bs=number of bytes, count=how many times to read out bs bytes) from /dev/gpio0, dumps any error messages to /dev/zero and pipes the data to hexdump. The hexdump program will print out the four bytes as a nice hexadecimal value. 5 32073A-AVR32-02/08 4.1.2.2 Using GPIOs in an application Usually reading of and writing to the GPIO device file is done in an application and not on the shell. In an application, we can make use of the different file I/O methods like blocking, non-blocking and asynchronous I/O. · Blocking: A read from the device will always succeed and deliver the pin state. This is actually not really a blocking method in this case as the pin state is always available upon a read. This is the standard method when opening files on Linux. · Non-blocking: A read will only succeed if new data is available. This means only if a GPIO has changed its status since the last read. An unsuccessful read will return EAGAIN. The non-blocking method can be used in conjunction with the poll interface. This makes it possible for an application to sleep or do something else until the pin status changes. · Asynchronous: This method is based on the Linux signaling system. A signal handler is installed as callback function for the GPIO device. Thus every time the GPIO framework detects a change of an activated I/O line (this means if it is configured as input for the GPIO device), this dedicated handler function will be called. The above methods, except for the blocking method and their possible implementations, are shown in the gpio-test application. Run the program with the flag ­h to get all available options. 5 Controlling GPIOs in a module The use of GPOs in a driver is straight forward. The API is defined in include/asm/arch/gpio.h (do not include this directly, use include/asm/gpio.h instead) and a good documentation is available in Documentation/gpio.txt. The functions gpio_request and gpio_free will not succeed, unless the used GPIO is already set up in the board setup code. However, these are only optional functions. The gpio module shipped with this application note shows how to configure an I/O line as input and how to register an interrupt for the pin on the ATSTK1000 ATSTK1000. There is no need to change the board setup code in this example, unless the switches are reserved for other purposes there. This is the case if e.g. the mouse driver is active in your system. In that case remove this driver either in the Buildroot configuration or directly in the board setup code. To build the module, edit the Makefile and change the path settings to make it point to your Linux kernel sources. Configure the kernel for your board before and run "make ARCH=avr32 CROSS_COMPILE=avr32-linux- prepare" in the kernel source directory. This may not be necessary if you already have build the kernel for your board. At last run make in the module source directory and copy the module to the target board. To load the module run insmod gpio-example Connect header J1 with the SWITCH header and press SW0. Some messages should appear when we print out the kernel messages with dmesg. In addition, the interrupt count for switch 0 in /proc/interrupts should have increased. As the button is not debounced, the number of messages (or interrupts in /proc/interrupts) varies. To unload the module, run rmmod gpio-example 6 AVR32408 AVR32408 32073A-AVR32-02/08 AVR32408 AVR32408 6 Linux LED framework Linux provides an own class for controlling LEDs but this framework can also be used for controlling other things over a GPIO. Therefore, if LED is mentioned in this chapter, the term is exchangeable to any other peripheral. To be able to control a LED with this class, the board setup code must be modified, if not already done on Atmel boards (e.g. on the NGW are the LEDs on the board set up for the Linux LED interface). To build the LED functionality into the kernel or as module, following options should be enabled in the kernel configuration (Device Drivers LED devices): · LED Support o LED Class Support o LED Support for GPIO connected LEDs Optionally, triggers can be selected (see chapter 6.2). 6.1 Adding LEDs to the framework If a LED that is connected to a I/O line of the microcontroller shall be used by the LED framework, this can be configured in the board setup code. The LED framework API is defined in /include/linux/leds.h. A LED is described by the structure gpio_led struct gpio_led { const char *name; /* Led name */ char *default_trigger; /* Trigger name if used*/ unsigned gpio; /* Number of the GPIO line */ u8 active_low; /* Set to 1 if active low*/ }; If you have more than one LED, an array containing all gpio_led structures should be created. Next step is to declare a gpio_led_platform_data structure and fill it out with the LED array length and its start address. struct gpio_led_platform_data { int num_leds; /* Number of LEDs in our array*/ struct gpio_led *leds; /* Start address of LED array */ }; The last structure we need is the platform_device structure to register all LEDs as a platform device. The definition can be found in include/linux/platform_device.h. struct platform_device { const char *name; u32 id; struct device dev; u32 num_resources; struct resource *resource; }; The fields we need to fill out are the name, id and platform_data, which is defined in the device structure (take a look at include/linux/device.h for a detailed description of this structure). The name chosen appears under the sys filesystem as a directory in class/leds/ and must be "gpio-leds". If we have just one device instance, we can set 7 32073A-AVR32-02/08 the id field to 0. If we have several instances, each must have a different id. The platform_data field gets the address of our gpio_led_platfrom_data structure. Before registering our platform device with the Linux system by calling the platform_device_register function, we have to set up the I/O lines appropriately. Take a look at chapter 3 on how to configure GPIOs. A good example on how to register LEDs with the Linux LED framework is the board setup code for the ATSTK1000 ATSTK1000. The code is in arch/avr32/boards/atstk1000/. 6.2 Using the LED framework from user-space After an I/O line is assigned to the Linux LED framework, it can not be used by other drivers. The LEDs appear in /sys/class/leds/ and can be controlled by user-space applications there. For instance, on the NGW the three subdirectories a, b and sys are in that directory. Each of them represents a LED on the board. In these subdirectories you can find files that can be used to control the LEDs. · brightness: By writing a nonzero value (the possible range is from 0 to 255) the LED is activated. Accordingly, a write of "0" turns the LED off. As most LEDs do not have any brightness support, it does not matter which nonzero value is written to this file, as long as it is in the supported range. · trigger: This is an optional attribute of the LED class. A trigger is a function that turns the LED on/off in a predefined way. To view the available triggers, read out the file (cat or a similar application). The currently active trigger is enclosed in square brackets []. To let the sys LED on the NGW flash like a heartbeat, use following command: echo heartbeat > /sys/class/leds/sys/trigger Depending on the current LED configuration, there may be more attribute files in that directory. For instance, if we select the timer trigger, two more attributes are available: · delay_on: Time in milliseconds during which the LED should be turned on · delay_off: Time in milliseconds during which the LED should be turned off If one of the above values is 0, the LED will be turned off. For more information on available triggers take a look at the Linux kernel documentation (Documentation/leds.txt and the kernel configuration system to select available triggers). 7 Linux input system The Linux input system is used by keyboards, joysticks and mouse drivers to send events from the hardware to user-space applications. The documentation is available in Documentation/input/. An event is described by the following structure: struct input_event { struct timeval time; _u16 type; _u16 code; _s32 value; }; The time field relates to the moment when the event occurred. type describes the event types which are defined in include/linux/input.h. A keyboard uses type EV_KEY and a mouse EV_REL. Depending on the type, various codes are available, such as KEY_A, KEY_B for an EV_KEY type. value contains information that is also related to the type field. In case of an EV_KEY event for example, value 0 means that a key 8 AVR32408 AVR32408 32073A-AVR32-02/08 AVR32408 AVR32408 was released, 1 that a key was pressed, 2 autorepeate. In case of an EV_REL event, value contains a relative position change. Applications read these events from the input system to get control information from devices. For instance, the X-server gets the mouse movements as events from the input system. 7.1 GPIO keyboard The gpio-keys driver translates and delivers GPIO events to the Linux input system. These hardware events can be tied to various standard input events such as key "E" pressed or "backspace". Thus it is possible to emulate parts of a keyboard or to create your own input device. To enable the gpio-keys driver, activate the following selections in the kernel configuration (Device Drivers Input device support): · Generic input layer o Event interface o Keyboards GPIO Buttons A GPIO is represented by the following structure in the gpio-keys driver. struct gpio_keys_button { int code; /* input event code */ int gpio; /* gpio number */ int active_low; /* set to 1 if active low */ char *desc; /* button description*/ int type; /* input event type EV_* */ }; The gpio field contains the GPIO number. See chapter 3 for detailed information on how to get the correct number. A description of the button can be written into the desc field and active_low is used to configure the button as active low or active high. The possible input event types for the type field are defined in include/linux/input.h. For a simple button, the most likely solution is EV_KEY. Depending on the event type, there are different event codes. If you want to simulate the "E" key on a keyboard with a GPIO, use EV_KEY as type and KEY_E as code. All available codes are defined in include/linux/input.h. If we have more than one button, we can put these structures in an array. Next step is to implement the button data in the gpio_keys_platform_data structure. struct gpio_keys_platform_data { struct gpio_keys_button *buttons; int nbuttons; }; The array (or, if just one button used, the single structure) address is stored in buttons and the array length in nbuttons. The platform data is then tied to a platform device structure. The platform device name must be "gpio-keys" to achieve the loading of the correct driver. The device id in combination with the name must be unique. In most cases, the id can be set to 0 if just one gpio-keys device is registered. The following example shows how two switches on the ATSTK1000 ATSTK1000 board can be used as inputs for the gpio-keys driver. static struct gpio_keys_button stk_j1_button[] = { { .desc = "Switch0", .gpio = GPIO_PIN_PB(0), .active_low = 1, .code = KEY_A, .type = EV_KEY,}, 9 32073A-AVR32-02/08 { .desc = "Switch1", .gpio = GPIO_PIN_PB(1), .active_low = 1, .code = KEY_B, .type = EV_KEY,}, }; static struct gpio_keys_platform_data stk_j1_button_data = { .buttons = stk_j1_button, .nbuttons = ARRAY_SIZE(stk_j1_button), }; static struct platform_device gpio_keys_dev = { .name = "gpio-keys", .id = 0, .dev = { .platform_data = &stk_j1_button_data, } }; static void setup_gpio_keys(void){ int i; for(i=0; i < ARRAY_SIZE(stk_j1_button); i+) at32_select_gpio(stk_j1_button[i].gpio, 0); platform_device_register(&gpio_keys_dev); } From the board init function setup_gpio_keys() must be called and the header files and must be included to add the switches to the gpio-keys driver. The events generated by the gpio-keys driver, on an input change of an I/O line, are delivered to the input system and can be obtained from the event interface. Upon successful initialization of all needed drivers, an event device will be created by the mdev application in /dev. The name will be event0 if this is the first device or event1, event2 . if more devices are installed. To associate the correct event device with the gpio-keys device, a search in the /sys file system delivers the answer. If there is no event device in /dev, maybe the mdev application is not available on your system. The files can also be created by hand with the mknod tool (mknod /dev/input/event0 c 13 64; mknod /dev/input/event1 c 13 65 .). The gpio-keys application included with this application note grabs events from an event device and prints it to stdout. This program shall give you an example on how these events can be processed in a user-space application. Two readout methods are available, blocking and non-blocking. Use the ­n flag to set the non-blocking method. To see all available options run the application with the ­h flag. 7.2 GPIO mouse driver The GPIO mouse driver uses, as the name already implies, GPIOs to emulate a mouse device. This is achieved through reading out the pin state in a distinct time period (scan interval). The driver uses the Linux input system to deliver mouse events to user-space. To enable the GPIO mouse support in the kernel, the following settings must be activated in the configuration (Device Drivers Input device support): · Generic input layer o Mouse interface o Event interface 10 AVR32408 AVR32408 32073A-AVR32-02/08 AVR32408 AVR32408 o Mice GPIO mouse The "mouse interface" is needed to access the GPIO mouse as a char device. By adding this module /dev/input/mouseX and /dev/input/mice will be created. The "X" after "mouse" will be replaced by a number starting from 0 for each mouse input driver (mouse0, mouse1 .). An optional selection is the event interface. This interface can also be used to get raw input mouse events. A GPIO mouse is represented by the following platform data structure and can be found in include/linux/gpio_mouse.h: struct gpio_mouse_platform_data { int scan_ms; int polarity; union { struct { int int int int up; down; left; right; int bleft; int bmiddle; int bright; }; int pins[GPIO_MOUSE_PIN_MAX]; }; }; The time period in which the GPIO lines should be scanned is set in milliseconds in scan_ms. The definitions GPIO_MOUSE_POLARITY_ACT_LOW and GPIO_MOUSE_POLARITY_ACT_HIGH can be use in conjunction with the polarity field to set the correct polarity. The used I/O line number must be filled into the fields up, down, left and right. The selection of the correct I/O line number is described in chapter 3. The remaining three fields bleft, bmiddle and bright are the mouse buttons. Next step is to set up the I/O lines and to register the GPIO mouse as platform device. Following code is used on the ATSTK1000 ATSTK1000 development board to implement a GPIO mouse. static struct gpio_mouse_platform_data gpio_mouse0_data = { .scan_ms = 10, .polarity = GPIO_MOUSE_POLARITY_ACT_LOW, { { .up = GPIO_PIN_PB(2), .down = GPIO_PIN_PB(1), .left = GPIO_PIN_PB(3), .right = GPIO_PIN_PB(0), .bleft = GPIO_PIN_PB(7), .bmiddle = GPIO_PIN_PB(6), .bright = GPIO_PIN_PB(5), }, }, }; 11 32073A-AVR32-02/08 static struct platform_device gpio_mouse0_device = { .name = "gpio_mouse", .id = 0, .dev ={ .platform_data = &gpio_mouse0_data, }, }; static void _init add_device_gpio_mouse0(void) { struct platform_device *pdev = &gpio_mouse0_device; struct gpio_mouse_platform_data *data = pdev->dev.platform_data; at32_select_gpio(data->up, 0); at32_select_gpio(data->down, 0); at32_select_gpio(data->left, 0); at32_select_gpio(data->right, 0); at32_select_gpio(data->bleft, 0); at32_select_gpio(data->bmiddle, 0); at32_select_gpio(data->bright, 0); platform_device_register(pdev); } The only thing left to do is to call the function add_device_gpio from the board initialization function. The complete patch for the ATSTK1000 ATSTK1000 development board is available in the "buildroot" Linux build system on the Atmel website. 8 Literature and references The Linux kernel documentation Documentation/filesystems/configfs/configfs.txt) (Documentation/gpio.txt and http://www.avr32linux.org http://www.avrfreaks.net 12 AVR32408 AVR32408 32073A-AVR32-02/08 Disclaimer Headquarters International Atmel Corporation 2325 Orchard Parkway San Jose, CA 95131 USA Tel: 1(408) 441-0311 Fax: 1(408) 487-2600 Atmel Asia Room 1219 Chinachem Golden Plaza 77 Mody Road Tsimshatsui East Kowloon Hong Kong Tel: (852) 2721-9778 Fax: (852) 2722-1369 Atmel Europe Le Krebs 8, Rue Jean-Pierre Timbaud BP 309 78054 Saint-Quentin-enYvelines Cedex France Tel: (33) 1-30-60-70-00 Fax: (33) 1-30-60-71-11 Atmel Japan 9F, Tonetsu Shinkawa Bldg. 1-24-8 Shinkawa Chuo-ku, Tokyo 104-0033 Japan Tel: (81) 3-3523-3551 Fax: (81) 3-3523-7581 Technical Support avr@atmel.com Sales Contact www.atmel.com/contacts Product Contact Web Site www.atmel.com Literature Request www.atmel.com/literature 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 ATMEL'S TERMS AND CONDITIONS OF SALE LOCATED ON ATMEL'S WEB SITE, 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 OF 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's products are not intended, authorized, or warranted for use as components in applications intended to support or sustain life. © 2008 Atmel Corporation. All rights reserved. Atmel®, logo and combinations thereof, AVR®and others, are the registered trademarks or trademarks of Atmel Corporation or its subsidiaries. Other terms and product names may be trademarks of others. 32073A-AVR32-02/08