AVR32000

AVR32000: Introduction to AVR32 header files Features • • • • • Register and Bit-Name Definitions Use of Bit-field and Bit-mask Use of type definitions Use of Macros Deviance Between Hardware Registers and Header Register Naming 32-bit Microcontrollers 1 Introduction The purpose of this application note is to give new users a basic introduction to the header files for AVR®32 microcontrollers. The usage of I/O registers, bit-names and module type definitions. It will also cover more advanced usage of the header files like the I/O modules structures. This application note is specific for IAR Systems® AVR32 compiler and GNU GCC for AVR32 compiler. Rev. 32005A-AVR32-05/06 2 Register and Bit-Name Definitions The header files for AVR32 are split into many small files. One header file defines the core and one header file defines each module. This eases the portability of the code to other devices because the source code does not have to know which version of a module is used in a specific device, the only necessary include is the unique device header file. All code, which includes a device module, must start by including the io header file for the AVR32 devices. The io header file for devices uses the following convention: avr32/io.h The io.h header file knows the target device by a flag passed to the compiler. Within the io.h file the devices and their specific header file are included, which includes and defines all modules available for the target device. This eases the users need to know what the include file for a specific module is named, since all defines for a module are present by including a single general header file. Registers are named as they are given in the datasheet, and extended with a defined prefix. Naming of registers use the following convention: AVR32__ Example for USART control register: AVR32_USART_CR Bit-field names are named as they are given in the datasheet including a prefix. Naming of bit-fields use the following convention: AVR32___ Example for USART transceiver enable in the control register: AVR32_USART_CR_TXEN The offset and mask of a bit-field name in a register is also available with a more explained define. Naming of bit-field offsets and masks use the following convention: AVR32____OFFSET AVR32____MASK Example for USART transceiver enable in the control register: AVR32_USART_CR_TXEN_OFFSET AVR32_USART_CR_TXEN_MASK For reducing code text size it is possible to use abbreviated bit-field names. If the bitfield name is unique and all values with that name are the same for all registers, the register name is dropped in the definition of the bit-field name. 2 AVR32000 32005A-AVR32-05/06 AVR32000 Example for USART transceiver enable bit in the control register can be written: AVR32_USART_CR_TXEN Or AVR32_USART_TXEN 3 Use of Header Files 3.1 Use of Bit-field and Bit-mask Registers are available by using type definitions, typedef, or by direct access. All registers can be defined as pointers to a memory address, and are accessible by dereferencing the pointer. Registers are defined as an offset to the base address, for simplifying access to the registers of each module instance (see Figure 3-1). Naming of the pointer to the base address use the following convention: AVR32_ Example for USART module instance A pointer to base address: AVR32_USART0 Figure 3-1. Memory mapping to registers for the AP7000 USART0 module to header files. 0xFFE00C00 CR MR IER IDR Offset 0x0000 0x0004 0x0008 0x0012 Header file direct access AVR32_USART0.cr AVR32_USART0.mr AVR32_USART0.ier AVR32_USART0.idr 0x0016 - 0x00FC PDC 0x0100 - 0x0128 3.1.1 Use of type definitions All modules have a type definition, in C and C++ known as typedef. These can be used to access the I/O memory concerning this module. 3 32005A-AVR32-05/06 All type definitions are a volatile pointer that consists of one or several structures. Naming of type definitions use the following convention: volatile avr32__t * Example using type definitions for accessing the USART0: volatile avr32_usart_t * myUsart = &AVR32_USART0; myUsart->mr = (1