AVR® IAR C/C++ Compiler Reference Guide for Atmel® Corporation’s AVR® Microcontroller CAVR-4
COPYRIGHT NOTICE © Copyright 1996–2005 IAR Systems. All rights reserved. No part of this document may be reproduced without the prior written consent of IAR Systems. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such a license. DISCLAIMER The information in this document is subject to change without notice and does not represent a commitment on any part of IAR Systems.
Brief contents Tables ...................................................................................................................... xv Preface ................................................................................................................... xix Part 1. Using the compiler Getting started Data storage Functions ......................................................... 1 .................................................................................................... 3 ....
Implementation-defined behavior IAR language extensions Diagnostics Index AVR® IAR C/C++ Compiler iv Reference Guide CAVR-4 .......................................................... 255 ............................................................................. 269 ......................................................................................................... 279 .....................................................................................................................
Contents Tables ...................................................................................................................... xv Preface ................................................................................................................... xix Who should read this guide .............................................................. xix How to use this guide ......................................................................... xix What this guide contains .......................
Data storage ...................................................................................................... 15 Introduction .............................................................................................. 15 Storing data ........................................................................................ 15 Extended keywords for data ............................................................... 16 Memory models ..................................................................
Contents The return address stack .................................................................... 43 The heap ............................................................................................ 44 Located data ....................................................................................... 46 User-defined data segments ............................................................... 46 Code segments .......................................................................................
System startup and termination ...................................................... 64 System startup .................................................................................... 65 System termination ............................................................................ 65 Customizing system initialization ................................................... 66 __low_level_init ............................................................................... 66 Modifying the file cstartup.
Contents math.h ................................................................................................. 83 stdio.h ................................................................................................. 83 stdlib.h ................................................................................................ 83 printf, scanf and strtod ....................................................................... 84 The CLIB runtime environment .............................................
Preserved versus scratch registers ................................................... 101 Function call .................................................................................... 102 Function exit ................................................................................... 105 Return address handling ................................................................... 106 Restrictions for special function types ............................................. 106 Examples .....................
Contents Writing efficient code ......................................................................... 130 Saving stack space and RAM memory ............................................ 131 Function prototypes .......................................................................... 131 Integer types and bit negation .......................................................... 132 Protecting simultaneously accessed variables .................................. 132 Accessing special function registers ....
Compiler options ........................................................................................... 167 Setting command line options ........................................................ 167 Specifying parameters ...................................................................... 168 Specifying environment variables .................................................... 169 Error return codes ............................................................................. 169 Options summary ..
Contents Library functions as intrinsic functions ........................................... 248 IAR CLIB Library .................................................................................. 248 Library definitions summary ............................................................ 249 AVR–specific library functions ........................................................ 249 Specifying read and write formatters ...............................................
AVR® IAR C/C++ Compiler xiv Reference Guide CAVR-4
Tables 1: Typographic conventions used in this guide ....................................................... xxii 2: Mapping of processor options ................................................................................. 6 3: Summary of processor configuration ...................................................................... 8 4: Summary of memory models ................................................................................
32: Floating-point types .......................................................................................... 139 33: Function pointers ............................................................................................... 141 34: Data pointers ..................................................................................................... 141 35: size_t typedef ....................................................................................................
Tables 66: Nearfunc pointer size ........................................................................................ 211 67: Tiny address ranges ........................................................................................... 213 68: Tinyflash address ranges ................................................................................... 213 69: Pragma directives summary .............................................................................. 215 70: Predefined symbols summary ....
AVR® IAR C/C++ Compiler xviii Reference Guide CAVR-4
Preface Welcome to the AVR® IAR C/C++ Compiler Reference Guide. The purpose of this guide is to provide you with detailed reference information that can help you to use the AVR IAR C/C++ Compiler to best suit your application requirements. This guide also gives you suggestions on coding techniques so that you can develop applications with maximum efficiency.
What this guide contains What this guide contains Below is a brief outline and summary of the chapters in this guide. Part 1. Using the compiler ● ● ● ● ● ● ● ● ● Getting started gives the information you need to get started using the AVR IAR C/C++ Compiler for efficiently developing your application. Data storage describes how data can be stored in memory, with emphasis on the different memory models and memory type attributes.
Preface ● ● ● ● Library functions gives an introduction to the C or C++ library functions, and summarizes the header files. Implementation-defined behavior describes how the AVR IAR C/C++ Compiler. handles the implementation-defined areas of the C language standard. IAR language extensions describes the IAR extensions to the ISO/ANSI standard for the C programming language. Diagnostics describes how the compiler’s diagnostic system works.
Document conventions We recommend that you visit the following websites: ● ● ● The Atmel® Corporation website, www.atmel.com, contains information and news about the AVR microcontrollers. The IAR website, www.iar.com, holds application notes and other product information. Finally, the Embedded C++ Technical Committee website, www.caravan.net/ec2plus, contains information about the Embedded C++ standard.
Part 1. Using the compiler This part of the AVR® IAR C/C++ Compiler Reference Guide includes the following chapters: ● Getting started ● Data storage ● Functions ● Placing code and data ● The DLIB runtime environment ● The CLIB runtime environment ● Assembler language interface ● Using C++ ● Efficient coding for embedded applications.
2 CAVR-4
Getting started This chapter gives the information you need to get started using the AVR IAR C/C++ Compiler for efficiently developing your application. First you will get an overview of the supported programming languages, followed by a description of the steps involved for compiling and linking an application. Next, the compiler is introduced.
Building applications—an overview For more information about the Embedded C++ language and IAR Extended Embedded C++, see the chapter Using C++. Building applications—an overview A typical application is built from a number of source files and libraries. The source files can be written in C, C++, or assembler language, and can be compiled into object files by the AVR IAR C/C++ Compiler or the AVR IAR Assembler. A library is a collection of object files.
Getting started In this example, myfile.r90 and myfile2.r90 are object files, lnkm128s.xcl is the linker command file, and cl3s-ec.r90 is the runtime library. The option -s specifies the label where the application starts. The option -o specifies the name of the output file, and the option -F can be used for specifying the output format. (The default output format is Motorola.) The IAR XLINK Linker produces output according to your specifications. Choose the output format that suits your purpose.
Basic settings for project configuration Both options set up default behavior—implicit assumptions—but note that the --cpu option is more precise because it contains more information about the intended target than the more generic -v option. The --cpu option knows, for example, how much flash memory is available in the given target and allows the compiler to optimize accesses to code memory in a way that the -v option does not. See Mapping of processor options --cpu and -v, page 6.
Getting started Processor variant Generic processor option Supported AVR derivative --cpu=at43usb320a -v3 AT43USB320A --cpu=at43usb325 -v3 AT43USB325 --cpu=at43usb326 -v3 AT43USB326 --cpu=at43usb351m -v3 AT43USB351m --cpu=at43usb353m -v3 AT43USB353m --cpu=at43usb355 -v3 AT43USB355 --cpu=at94k -v3 FpSLic --cpu=at86rf401 -v0 AT86RF401 --cpu=can128 -v3 AT90CAN128 --cpu=m8 -v1 ATmega8 --cpu=m16 -v3 ATmega16 --cpu=m32 -v3 ATmega32 --cpu=m48 -v1 ATmega48 --cpu=m64 -v3
Basic settings for project configuration Processor variant Generic processor option Supported AVR derivative --cpu=m329 -v3 ATmega329 --cpu=m3290 -v3 ATmega3290 --cpu=m406 -v3 ATmega406 --cpu=m645 -v3 ATmega645 --cpu=m6450 -v3 ATmega6450 --cpu=m649 -v3 ATmega649 --cpu=m6490 -v3 ATmega6490 --cpu=m8515 -v1 ATmega8515 --cpu=m8535 -v1 ATmega8535 --cpu=tiny10 -v0 ATtiny10 --cpu=tiny11 -v0 ATtiny11 --cpu=tiny12 -v0 ATtiny12 --cpu=tiny13 -v0 ATtiny13 --cpu=tiny15 -v0 AT
Getting started Generic processor Available option memory models -v2 Tiny -v3 -v4 -v5 Max addressable Max module and/or memory data program size __nearfunc ≤ 256 bytes ≤ 128 Kbytes Tiny, Small __nearfunc ≤ 64 Kbytes ≤ 128 Kbytes Small, Large __nearfunc ≤ 16 Mbytes ≤ 128 Kbytes Tiny, Small __farfunc* ≤ 64 Kbytes ≤ 8 Mbytes * ≤ 16 Mbytes ≤ 8 Mbytes Small, Large -v6 Function attribute __farfunc Table 3: Summary of processor configuration (Continued) Note: ● ● ● ● *) When usi
Basic settings for project configuration Your program may use only one memory model at a time, and the same model must be used by all user modules and all library modules.
Getting started RUNTIME ENVIRONMENT To create the required runtime environment you should choose a runtime library and set library options. You may also need to override certain library modules with your own customized versions. There are two different sets of runtime libraries provided: ● ● The IAR DLIB Library, which supports ISO/ANSI C and C++.
Special support for embedded systems Choosing a runtime library from the command line Use the following command line options to specify the library and the dependency files: Command line Description -I\avr\inc Specifies the include paths -I\avr\inc\{clib|dlib} Specifies the library-specific include path. Use clib or dlib depending on which library you are using. libraryfile.r90 Specifies the library object file --dlib_config C:\...\configfile.
Getting started The command line option -e makes the extended keywords available, and reserves them so that they cannot be used as variable names. See, -e, page 179 for additional information. For detailed descriptions of the extended keywords, see the chapter Extended keywords. To read about special function types, see Special function types, page 29.
Special support for embedded systems AVR® IAR C/C++ Compiler 14 Reference Guide CAVR-4
Data storage This chapter gives a brief introduction to the memory layout of the AVR microcontroller and the fundamental ways data can be stored in memory: on the stack, in static (global) memory, or in heap memory. For efficient memory usage, AVR IAR C/C++ Compiler provides a set of memory models and memory attributes, allowing you to fine-tune the access methods, resulting in smaller code size.
Introduction ● On the heap. Once memory has been allocated on the heap, it remains valid until it is explicitly released back to the system by the application. This type of memory is useful when the number of objects is not known until the application executes. Note that there are potential risks connected with using the heap in systems with a limited amount of memory, or systems that are expected to run for a long time.
Data storage Note that the location of the pointer variable p is not affected by the keyword. In the following example, however, the pointer variable p2 is placed in far memory. Like p, p2 points to a character in EEPROM memory. char __eeprom * __far p2; Type definitions Storage can also be specified using type definitions.
Memory types and memory attributes Your project can only use one memory model at a time, and the same model must be used by all user modules and all library modules. If you do not specify a memory model option, the compiler will use the Tiny memory model for all processor options, except for -v4 and -v6, where the Small memory model will be used.
Data storage By selecting a memory model, you have selected a default memory type that your application will use. However, it is possible to specify—for individual variables or pointers—different memory types. This makes it possible to create an application that can contain a large amount of data, and at the same time make sure that variables that are used often are placed in memory that can be efficiently accessed.
Memory types and memory attributes Memory Max object Pointer size Memory space Address range __generic 2 bytes 3 bytes Data or Code The most significant bit (MSB) 32 Kbytes determines whether this pointer 8 Mbytes points to code space (1) or data space (0). The small generic pointer is generated for the processor options -v0 and -v1.
Data storage Differences between pointer types A pointer must contain information needed to specify a memory location of a certain memory type. This means that the pointer sizes are different for different memory types. For information about the sizes of the different pointer types, seePointer types, page 141. In the AVR IAR C/C++ Compiler, it is illegal to convert pointers between different types without using explicit casts. For more details, see Casting, page 142.
C++ and memory types int __flash * e; A pointer stored in default memory. The pointer points to an integer in flash memory. int __flash * __eeprom f; A pointer stored in eeprom memory pointing to an integer stored in flash memory. int __eeprom * myFunction( int __flash *); A declaration of a function that takes a parameter which is a pointer to an integer stored in flash memory. The function returns a pointer to an integer stored in eeprom memory. In short: int The basic type is an integer.
Data storage Example In the example below, an object, named delta, of the type MyClass is defined in data16 memory. The class contains a static member variable that is stored in data20 memory.
The stack and auto variables The stack is a fixed block of memory, divided into two parts. The first part contains allocated memory used by the function that called the current function, and the function that called it, etc. The second part contains free memory that can be allocated. The borderline between the two areas is called the top of stack and is represented by the stack pointer, which is a dedicated processor register. Memory is allocated on the stack by moving the stack pointer.
Data storage Dynamic memory on the heap Memory for objects allocated on the heap will live until the objects are explicitly released. This type of memory storage is very useful for applications where the amount of data is not known until runtime. In C, memory is allocated using the standard library function malloc, or one of the related functions calloc and realloc. The memory is released again using free. In C++, there is a special keyword, new, designed to allocate memory and run constructors.
Dynamic memory on the heap AVR® IAR C/C++ Compiler 26 Reference Guide CAVR-4
Functions This chapter contains information about functions. First, you get a brief overview of mechanisms for controlling functions, as well as information about memory type attributes for function storage. Then, the special function types interrupt and monitor are described, including how to declare C++ member functions by using special function types.
Function storage Syntax The extended keywords are specified before the return type, for example: __interrupt void alpha(void); The keywords that are type attributes must be specified both when they are defined and in the declaration. Object attributes only have to be specified when they are defined since they do not affect the way an object or function is used.
Functions Special function types This section describes the special function types interrupt and monitor. The AVR IAR C/C++ Compiler allows an application to take full advantage of these AVR features, without forcing you to implement anything in assembler language. INTERRUPT FUNCTIONS In embedded systems, the use of interrupts is a method of detecting external events immediately; for example, detecting that a button has been pressed.
Special function types MONITOR FUNCTIONS A monitor function causes interrupts to be disabled during execution of the function. At function entry, the status register is saved and interrupts are disabled. At function exit, the original status register is restored, and thereby the interrupt status that existed before the function call is also restored. To define a monitor function, you can use the __monitor keyword. For reference information, see __monitor, page 210.
Functions The following is an example of a program fragment that uses the semaphore: void my_program(void) { if (get_lock()) { /* ... Do something ... */ /* When done, release the lock. */ release_lock(); } } The drawback using this method is that interrupts are disabled for the entire monitor function. Example of implementing a semaphore in C++ In C++, it is common to implement small methods with the intention that they should be inlined.
Special function types void f() { static long next_stop = 100; extern void do_stuff(); long tick; /* A critical block */ { Mutex m; /* Read volatile variable 'tick_count' in a safe way and put the value in a local variable */ tick = tick_count; } if (tick >= next_stop) { next_stop += 100; do_stuff(); } } C++ AND SPECIAL FUNCTION TYPES C++ member functions can be declared using special function types. However, the following restriction apply: Interrupt member functions must be static.
Placing code and data This chapter introduces the concept of segments, and describes the different segment groups and segment types. It also describes how they correspond to the memory and function types, and how they interact with the runtime environment. The methods for placing segments in memory, which means customizing a linker command file, are described.
Placing segments in memory For detailed information about individual segments, see the chapter Segment reference in Part 2. Compiler reference. Segment memory type XLINK assigns a segment memory type to each of the segments. In some cases, the individual segments may have the same name as the segment memory type they belong to, for example CODE. Make sure not to confuse the individual segment names with the segment memory types in those cases.
Placing code and data CUSTOMIZING THE LINKER COMMAND FILE The only change you will normally have to make to the supplied linker command file is to customize it so it reflects the target system memory map.
Placing segments in memory See the IAR Linker and Library Tools Reference Guide for more details. Using the -Z command for sequential placement Use the -Z command when you need to keep a segment in one consecutive chunk, when you need to preserve the order of segment parts in a segment, or, more unlikely, when you need to put segments in a specific order.
Placing code and data Note: Copy initialization segments—BASENAME_I and BASENAME_ID—must be placed using -Z. Data segments This section contains descriptions of the segments used for storing the different types of data—static, stack, heap, and located. In moste cases these segments are located in the data memory space. However, some of the segments are located in the code memory space.
Data segments would yield the segment base name NEAR. The suffix indicates what type of declared data the segment holds.
Placing code and data Initialized data In ISO/ANSI C all static variables—variables that are allocated at a fixed memory address—have to be initialized by the run-time system to a known value. This value is either an explicit value assigned to the variable, or if no value is given, it is cleared to zero. In the AVR IAR C/C++ Compiler, there are two exceptions to this rule and they both use keywords for ISO/ANSI C language extensions. Variables declared __no_init are not initialized at all.
Data segments 3 Finally, global C++ objects are constructed, if any. Initialization of local aggregates at function invocation Initialized aggregate auto variables—struct, union, and array variables local to a function—have the initial values in blocks of memory As an auto variable is allocated either in registers or on the stack, the initialization has to take place every time the function is called. Assume the following example: void f() { struct block b = { 3, 4, 2, 3, 6634, 234 }; ...
Placing code and data address of a constant __flash object and use it as a default pointer object, the compiler will issue an error. If you make an explicit cast of the object to a default pointer object, the error message disappears, instead there will be problems at run-time as the cast cannot copy the object from the flash memory to the data memory. Note: To access strings located in flash, you must use alternative library routines that expect flash strings.
Data segments If external SRAM is available it is possible to place the stack there. However, the external memory is slower than the internal stack so moving it to external memory will decrease the performance. Allocating a memory area for the stack is done differently when you use the command line interface compared to when you use the IAR Embedded Workbench IDE. Data stack size allocation in IAR Embedded Workbench Select Project>Options. In the General Options category, click the System page.
Placing code and data THE RETURN ADDRESS STACK The return address stack is used for storing the return address when a CALL, RCALL, ICALL, or EICALL instruction is executed. Each call will use two or three bytes of return address stack. An interrupt will also place a return address on this stack. To determine the size of the return address stack, see Stack size considerations, page 42.
Data segments THE HEAP The heap contains dynamic data allocated by use of the C function malloc (or one of its relatives) or the C++ operator new. If your application uses dynamic memory allocation, you should be familiar with the following: ● ● ● Linker segment used for the heap, which differs between the DLIB and the CLIB runtime environment Allocating the heap size, which differs depending on which build interface you are using Placing the heap segments in memory.
Placing code and data Heap size allocation in IAR Embedded Workbench Select Project>Options. In the General Options category, click the Heap configuration page. Add the required heap size in the appropriate text box. Heap size allocation from the command line The size of the heap segments are defined in the linker command file.
Code segments LOCATED DATA A variable that has been explicitly placed at an address, for example by using the compiler @ syntax, will be placed in either the SEGMENT_AC or the SEGMENT_AN segment. The former is used for constant-initialized data, and the latter for items declared as __no_init. The individual segment part of the segment knows its location in the memory space, and it should not be specified in the linker command file.
Placing code and data In the linker command file it can look like this: -Z(CODE)CODE=0-1FFF USER-DEFINED SEGMENTS If you create your own segments—see Controlling data and function placement, page 47—these must also be defined in the linker command file using the -Z or -P segment control directives.
Efficient usage of segments and memory Note: Take care when explicitly placing a variable or function in a predefined segment other than the one used by default. This is possible and useful in some situations, but incorrect placement can result in anything from error messages during compilation and linking to a malfunctioning application. Carefully consider the circumstances; there might be strict requirements on the declaration and use of the function or variable.
Placing code and data Example __no_init int alpha @ "MYSEGMENT"; /* OK */ #pragma location="MYSEGMENT" const int beta=5; /* OK */ const int gamma @ "MYSEGMENT" = 3; /* OK */ int delta @ "MYSEGMENT"; /* Error, neither */ /* "__no_init" nor "const" */ Function placement into named segments It is possible to place functions into named segments using either the @ operator or the #pragma location directive. When placing functions into segments, the segment is specified as a string literal.
Verifying the linked result of code and data placement A typical situation where this can be useful is if you need to optimize accesses to code and data that is frequently used, and place it in a different physical memory. To use your own segments, use the #pragma location directive, or the --segment option. If you use your own segments, these must also be defined in the linker command file using the -Z or the -P segment control directives.
Placing code and data Normally, XLINK will not generate an output file if there are any errors, such as range errors, during the linking process. Use the option Always generate output in IAR Embedded Workbench, or the option -B on the command line, to generate an output file even if a range error was encountered. For further information about the listing options and the linker listing, see the IAR Linker and Library Tools Reference Guide, and the AVR® IAR Embedded Workbench™ IDE User Guide.
Verifying the linked result of code and data placement The IAR Postlink utility You can also use the IAR Postlink utility, delivered with the AVR IAR C/C++ Compiler to generate multiple output files. This application takes as input an object file (of the XLINK simple format) and extracts one or more of its XLINK segment types into one file (which can be in either Intel extended hex format or Motorola S-record format).
The DLIB runtime environment This chapter describes the runtime environment in which an application executes. In particular, the chapter covers the DLIB runtime library and how you can modify it—setting options, overriding default library modules, or building your own library—to optimize it for your application. The chapter also covers system initialization and termination; how an application can control what happens before the function main is called, and how you can customize the initialization.
Introduction to the runtime environment The runtime library is delivered both as prebuilt libraries and as source files, and you can find them in the product subdirectories avr\lib and avr\src, respectively.
The DLIB runtime environment SITUATIONS THAT REQUIRE LIBRARY BUILDING Building a customized library is complex. You should therefore carefully consider whether it is really necessary. You must build your own library when: ● ● There is no prebuilt library for the required combination of compiler options or hardware support You want to define your own library configuration with support for locale, file descriptors, multibyte characters, et cetera.
Using a prebuilt library DEBUG SUPPORT IN THE RUNTIME LIBRARY You can make the library provide different levels of debugging support—basic, runtime, and I/O debugging.
The DLIB runtime environment ● ● ● Small flash memory option (--64k_flash) 64-bit doubles option (--64bit_doubles) Library configuration—Normal or Full. For the AVR IAR C/C++ Compiler and the Normal library configuration, there are prebuilt runtime libraries for all combinations of these options. For the Full library configuration there is one prebuilt runtime library delivered.
Using a prebuilt library On the command line, you must specify the following items: ● Specify which library object file to use on the XLINK command line, for instance: dlavr-3s-ec-64-f.r90 ● Specify the include paths for the compiler and assembler: -I avr\inc ● Specify the library configuration file for the compiler: --dlib_config C:\...\dlavr-3s-ec-64-f.h You can find the library object files and the library configuration files in the subdirectory avr\lib\dlib.
The DLIB runtime environment Choosing formatters for printf and scanf To override the default formatter for all the printf- and scanf-related functions, except for wprintf and wscanf variants, you simply set the appropriate library options. This section describes the different options available.
Choosing formatters for printf and scanf For information about how to fine-tune the formatting capabilities even further, see Configuration symbols for printf and scanf, page 69. Specifying print formatter in IAR Embedded Workbench To specify the printf formatter in IAR Embedded Workbench, choose Project>Options and select the General Options category. Select the appropriate option on the Library options page.
The DLIB runtime environment For information about how to fine-tune the formatting capabilities even further, see Configuration symbols for printf and scanf, page 69. Specifying scanf formatter in IAR Embedded Workbench To specify the scanf formatter in IAR Embedded Workbench, choose Project>Options and select the General Options category. Select the appropriate option on the Library options page.
Building and using a customized library Overriding library modules from the command line This procedure is applicable to any source file in the library, which means library_module.c in this example can be any module in the library. 1 Copy the appropriate library_module.c to your project directory. 2 Make the required additions to the file (or create your own routine, using the default file as a model), and make sure that it has the same module name as the original module.
The DLIB runtime environment SETTING UP A LIBRARY PROJECT IAR Embedded Workbench provides a library project template which can be used for customizing the runtime environment configuration. This library template has full library configuration, see Table 13, Library configurations, page 55. In IAR Embedded Workbench, modify the generic options in the created library project to suit your application, see Basic settings for project configuration, page 5.
System startup and termination System startup and termination This section describes the runtime environment actions performs during startup and termination of applications.
The DLIB runtime environment SYSTEM STARTUP When an application is initialized, a number of steps are performed: ● ● ● ● ● ● ● When the cpu is reset it will jump to the program entry label __program_start in the system startup code.
Customizing system initialization C-SPY interface to system termination If your project is linked with the XLINK options With runtime control modules or With I/O emulation modules, the normal __exit and abort functions are replaced with special ones. C-SPY will then recognize when those functions are called and can take appropriate actions to simulate program termination. For more information, see C-SPY Debugger runtime interface, page 76.
The DLIB runtime environment MODIFYING THE FILE CSTARTUP.S90 As noted earlier, you should not modify the file cstartup.s90 if a customized version of __low_level_init is enough for your needs. However, if you do need to modify the file cstartup.s90, we recommend that you follow the general procedure for creating a modified copy of the file and adding it to your project, see Overriding library modules, page 61.
Standard streams for input and output { int nChars = 0; /* Check for stdout and stderr (only necessary if file descriptors are enabled.
The DLIB runtime environment Configuration symbols for printf and scanf When you set up your application project, you typically need to consider what printf and scanf formatting capabilities your application requires, see Choosing formatters for printf and scanf, page 59. If the provided formatters do not meet your requirements, you can customize the full formatters. However, that means you need to rebuild the runtime library.
File input and output CUSTOMIZING FORMATTING CAPABILITIES To customize the formatting capabilities, you need to set up a library project, see Building and using a customized library, page 62. Define the configuration symbols according to your application requirements. File input and output The library contains a large number of powerful functions for file I/O operations. If you use any of these functions you need to customize them to suit your hardware.
The DLIB runtime environment Locale Locale is a part of the C language that allows language- and country-specific settings for a number of areas, such as currency symbols, date and time, and multibyte encoding. Depending on what runtime library you are using you get different level of locale support. However, the more locale support, the larger your code will get. It is therefore necessary to consider what level of support your application needs.
Locale Note: If you use multibyte characters in your C or assembler source code, make sure that you select the correct locale symbol (the local host locale). Building a library without support for locale interface The locale interface is not included if the configuration symbol _DLIB_FULL_LOCALE_SUPPORT is set to 0 (zero). This means that a hardwired locale is used—by default the standard C locale—but you can choose one of the supported locale configuration symbols.
The DLIB runtime environment Environment interaction According to the C standard, your application can interact with the environment using the functions getenv and system. Note: The putenv function is not required by the standard, and the library does not provide an implementation of it. The getenv function searches the string, pointed to by the global variable __environ, for the key that was passed as argument. If the key is found, the value of it is returned, otherwise 0 (zero) is returned.
Time This does not require that you rebuild the library. You can find source templates in the files Signal.c and Raise.c in the avr\src\lib directory. For information about overriding default library modules, see Overriding library modules, page 61. If you decide to rebuild the library, you can find source templates in the library project template. For further information, see Building and using a customized library, page 62.
The DLIB runtime environment Assert If you have linked your application with support for runtime debugging, C-SPY will be notified about failed asserts. If this is not the behavior you require, you must add the source file xReportAssert.c to your application project. Alternatively, you can rebuild the library. The __ReportAssert function generates the assert notification.You can find template code in the avr\src directory. For further information, see Building and using a customized library, page 62.
C-SPY Debugger runtime interface C-SPY Debugger runtime interface To include support for runtime and I/O debugging, you must link your application with the XLINK options With runtime control modules or With I/O emulation modules, see Debug support in the runtime library, page 56.
The DLIB runtime environment The mechanism used for implementing this feature works as follows. The debugger will detect the presence of the function __DebugBreak, which will be part of the application if you have linked it with the XLINK options for C-SPY runtime interface. In this case, the debugger will automatically set a breakpoint at the __DebugBreak function.
Checking module consistency Example In the following table, the object files could (but do not have to) define the two runtime attributes color and taste. In this case, file1 cannot be linked with any of the other files, since the runtime attribute color does not match. Also, file4 and file5 cannot be linked together, because the taste runtime attribute does not match. On the other hand, file2 and file3 can be linked with each other, and with either file4 or file5, but not with both.
The DLIB runtime environment PREDEFINED RUNTIME ATTRIBUTES The table below shows the predefined runtime model attributes that are available for the AVR IAR C/C++ Compiler. These can be included in assembler code or in mixed C or C++ and assembler code. Runtime model attribute Value Description __rt_version 2.30 This runtime key is always present in all modules generated by the AVR IAR C/C++ Compiler. If a major change in the runtime characteristics occurs, the value of this key changes.
Checking module consistency Examples For an example of using the runtime model attribute __rt_version for checking module consistency on used calling convention, see Hints for using the new calling convention, page 100. The following assembler source code provides a function, part2, that counts the number of times it has been called by increasing the register R4. The routine assumes that the application does not use R4 for anything else, that is, the register has been locked for usage.
The DLIB runtime environment Implementation of system startup code This section presents some general techniques used in the system startup code, including background information that might be useful if you need to modify it. Note: Do not modify the file cstartup.s90 unless required by your application. Your first option should be to use a customized version of __low_level_init for initialization code. The source files are well commented and are not described in detail in this guide.
Added C functionality This lets the system startup code specify code in subsequent segment parts and modules that are designed so that some of the parts may not be included by XLINK. The code simply falls through to the next piece of code not discarded by the linker. The following example shows this technique: MODULE doSomething RSEG PUBLIC EXTERN REQUIRE MYSEG:CODE:NOROOT(1) ?do_something ?end_of_test ?end_of_test ?do_something: ... // // // // // First segment part.
The DLIB runtime environment ● stdlib.h STDINT.H This include file provides integer characteristics. STDBOOL.H This include file makes the bool type available if the Allow IAR extensions (-e) option is used. MATH.H In math.h all functions exist in a float variant and a long double variant, suffixed by f and l respectively. For example, sinf and sinl. STDIO.H In stdio.
Added C functionality PRINTF, SCANF AND STRTOD The functions printf, scanf and strtod have added functionality from the C99 standard. For reference information about these functions, see the library reference available from the Help menu.
The CLIB runtime environment This chapter describes the runtime environment in which an application executes. In particular, it covers the CLIB runtime library and how you can optimize it for your application. The standard library uses a small set of low-level input and output routines for character-based I/O. This chapter describes how the low-level routines can be replaced by your own version. The chapter also describes how you can choose printf and scanf formatters.
Runtime environment ● ● Small flash memory option (--64k_flash) 64-bit doubles option (--64bit_doubles). For the AVR IAR C/C++ Compiler, this means there are prebuilt runtime libraries for different combination of these options. The following table shows the names of the libraries and how they reflect the used settings: Generic Library file processor option Memory Enhanced model core Small flash 64-bit doubles cl0t.r90 -v0 Tiny -- -- -- cl1s-64.r90 -v1 Small -- -- X cl61-ec-64.
The CLIB runtime environment Input and output You can customize: ● ● The functions related to character-based I/O The formatters used by printf/sprintf and scanf/sscanf. CHARACTER-BASED I/O The functions putchar and getchar are the fundamental functions through which C performs all character-based I/O. For any character-based I/O to be available, you must provide definitions for these two functions, using whatever facilities the hardware environment provides.
Input and output _medium_write The _medium_write formatter has the same functions as _formatted_write, except that floating-point numbers are not supported. Any attempt to use a %f, %g, %G, %e, or %E specifier will produce a runtime error: FLOATS? wrong formatter installed! _medium_write is considerably smaller than _formatted_write.
The CLIB runtime environment FORMATTERS USED BY SCANF AND SSCANF Similar to the printf and sprintf functions, scanf and sscanf use a common formatter, called _formatted_read. The full version of _formatted_read is very large, and provides facilities that are not required in many embedded applications. To reduce the memory consumption, an alternative smaller version is also provided.
Overriding default library modules ● ● Static variables are initialized except for __no_init and __eeprom declared variables; this includes clearing zero-initialized memory and copying the ROM image of the RAM memory of the remaining initialized variables The main function is called, which starts the application. Note that the system startup code contains code for more steps than described here. The other steps are applicable to the DLIB runtime environment.
The CLIB runtime environment C-SPY runtime interface The low-level debugger interface is used for communication between the application being debugged and the debugger itself. The interface is simple: C-SPY will place breakpoints on certain assembler labels in the application. When code located at the special labels is about to be executed, C-SPY will be notified and can perform an action.
Checking module consistency AVR® IAR C/C++ Compiler 92 Reference Guide CAVR-4
Assembler language interface When you develop an application for an embedded system, there may be situations where you will find it necessary to write parts of the code in assembler, for example, when using mechanisms in the AVR microcontroller that require precise timing and special instruction sequences. This chapter describes the available methods for this, as well as some C alternatives, with their pros and cons.
Mixing C and assembler The advantage of an intrinsic function compared to using inline assembler is that the compiler has all necessary information to interface the sequence properly with register allocation and variables. The compiler also knows how to optimize functions with such sequences; something the compiler is unable to do with inline assembler sequences. The result is, that you get the desired sequence properly integrated in your code, and that the compiler can optimize the result.
Assembler language interface INLINE ASSEMBLER It is possible to insert assembler code directly into a C or C++ function. The asm keyword assembles and inserts the supplied assembler statement, or statements, in-line. The following example shows how to use inline assembler to insert assembler instructions directly in the C source code. This example also shows the risks of using inline assembler. bool flag; void foo() { while (!flag) { asm("IN R0,PIND \n STS flag,R0"); } } In this example, the assignment of
Calling assembler routines from C Calling assembler routines from C An assembler routine that is to be called from C must: ● ● ● Conform to the calling convention Have a PUBLIC entry-point label Be declared as external before any call, to allow type checking and optional promotion of parameters, as in the following examples: extern int foo(void); or extern int foo(int i, int j); One way of fulfilling these requirements is to create skeleton code in C, compile it, and study the assembler list file.
Assembler language interface Note: In this example we use a low optimization level when compiling the code to show local and global variable access. If a higher level of optimization is used, the required references to local variables could be removed during the optimization. The actual function declaration is not changed by the optimization level. COMPILING THE CODE In IAR Embedded Workbench, specify list options on file level. Select the file in the workspace window. Then choose Project>Options.
Calling assembler routines from C++ Calling assembler routines from C++ The C calling convention does not apply to C++ functions. Most importantly, a function name is not sufficient to identify a C++ function. The scope and the type of the function are also required to guarantee type-safe linkage, and to resolve overloading. Another difference is that non-static member functions get an extra, hidden argument, the this pointer.
Assembler language interface Calling convention A calling convention is the way a function in a program calls another function. The compiler handles this automatically, but, if a function is written in assembler language, you must know where and how its parameters can be found, how to return to the program location from where it was called, and how to return the resulting value. It is also important to know which registers an assembler-level routine must preserve.
Calling convention For details about the --version1_calls option and the __version_1 attribute, see --version1_calls, page 199 and __version_1, page 214, respectively. Hints for using the new calling convention The new calling convention is very complex, and therefore not recommended for use when calling assembler routines. However, if you intend to use it for your assembler routines, you should create a list file and see how the compiler assigns the different parameters to the available registers.
Assembler language interface It is often practical to share header files between C and C++. The following is an example of a declaration that declares a function with C linkage in both C and C++: #ifdef __cplusplus extern "C" { #endif int f(int); #ifdef __cplusplus } #endif PRESERVED VERSUS SCRATCH REGISTERS The general AVR CPU registers are divided into three separate sets, which are described in this section. Scratch registers Any function may destroy the contents of a scratch register.
Calling convention Special registers For some registers there are certain prerequisites that you must consider: ● ● ● The stack pointer—register Y—must at all times point to the last element on the stack. In the eventuality of an interrupt, everything below the point that the stack pointer points to, will be destroyed. If using the -v4 or -v6 processor option, the RAMPY register is part of the data stack pointer.
Assembler language interface Parameters Alignment Passed in registers 16-bit values 2 R17:R16, R19:R18, R21:R20, R23:R22 24-bit values 4 R18:R17:R16, R22:R21:R20 32-bit values 4 R19:R18:R17:R16, R23:R22:R21:R20 Table 27: Registers used for passing parameters (Continued) Register assignment using the old calling convention In the old calling convention, the two left-most parameters are passed in registers if they are scalar and up to 32 bits in size.
Calling convention This would result in a being allocated to R16 (first fit), b to R19:R18 (alignment), c to R23:R22:R21:R20 (first fit), and d to R17 (first fit). A third example: void baz(char a, char __far * b, int c, int d) This would give, a being allocated to R16, b to R22:R21:R20, c to R19:R18, and d to the stack.
Assembler language interface Hidden parameters In addition to the parameters visible in a function declaration and definition, there can be hidden parameters: ● ● A function returning structures or unions larger than four bytes gets an extra hidden parameter, which is a default pointer—depending on the used memory model—pointing to the location where the result should be stored. This pointer must be returned to the called by the assembler function.
Calling convention Registers used for returning values For both calling conventions, the registers available for returning values are R16–R19. Return values Passed in registers 8-bit values R16 16-bit values R17:R16 24-bit values R18:R17:R16 32-bit values R19:R18:R17:R16 Table 29: Registers used for returning values Note that the size of a returned pointer depends on the memory model in use; appropriate registers are used accordingly.
Assembler language interface Monitor functions A monitor function causes interrupts to be disabled during execution of the function. At function entry, the status register SREG is saved and global interrupts are disabled. At function exit, the global interrupt enable bit (I) is restored in the SREG register, and thereby the interrupt status existing before the function call is also restored. For more information about monitor functions, see Monitor functions, page 30.
Call frame information It is the responsibility of the calling function to allocate a memory location for the return value and pass a pointer to it as a hidden first parameter. The pointer to the location where the return value should be stored is passed in the first suitable register/register pair, which is R16, R17:R16, and R18:R17:R16 for the Tiny, Small, and Large memory model, respectively.
Using C++ IAR Systems supports two levels of the C++ language: The industry-standard Embedded C++ and IAR Extended Embedded C++. They are described in this chapter. Overview Embedded C++ is a subset of the C++ programming language which is intended for embedded systems programming. It was defined by an industry consortium, the Embedded C++ Technical Committee. Performance and portability are particularly important in embedded systems development, which was considered when defining the language.
Overview ● ● ● New cast syntax (the operators dynamic_cast, static_cast, reinterpret_cast, and const_cast) Namespaces Mutable attribute. The exclusion of these language features makes the runtime library significantly more efficient.
Using C++ To set the equivalent option in IAR Embedded Workbench, select Project>Options>C/C++ Compiler>Language. Feature descriptions When writing C++ source code for the IAR C/C++ Compiler, there are some benefits and some possible quirks that you need to be aware of when mixing C++ features—such as classes, and class members—with IAR language extensions, such as IAR-specific attributes.
Feature descriptions Example class B { public: void f(); int i; }; Class memory To compensate for this limitation, a class can be associated with a class memory type.
Using C++ Note: Whenever a class type associated with a class memory type, like C, must be declared, the class memory type must be mentioned as well: class __far C; Also note that class types associated with different class memories are not compatible types. There is a built-in operator that returns the class memory type associated with a class, __memory_of(class). For instance, __memory_of(C) returns __far.
Feature descriptions To override the default new and delete operator for a class, declare: void *operator new(size_t); void operator delete(void *); as member functions, just like in ordinary C++. If a pointer to class memory cannot be implicitly casted into a default pointer type, no temporaries can be created for that class. For more information about memory types, see Memory types and memory attributes, page 18.
Using C++ Use this syntax if you want to override both global and class-specific operator new and operator delete for any data memory. Note that there is a special syntax to name the operator new functions for each memory, while the naming for the operator delete functions relies on normal overloading. New and delete expressions A new expression calls the operator new function for the memory of the type given.
Feature descriptions Templates and data memory attributes For data memory attributes to work as expected in templates, two elements of the standard C++ template handling have been changed—class template partial specialization matching and function template parameter deduction.
Using C++ For templates that are matched using this modified algorithm, it is impossible to get automatic generation of special code for pointers to small memory types. For large and “other” memory types (memory that cannot be pointed to by a default pointer) it is possible. In order to make it possible to write templates that are fully memory-aware—in the rare cases where this is useful—use the #pragma basic_template_matching directive in front of the template function declaration.
Feature descriptions Example vector d; // // // vector __near x; // // // vector __near y; // // // vector __huge z; // d placed in default memory, using the default heap, uses default pointers x placed in near memory, heap allocation from near, uses pointers to near memory y placed in near memory, heap allocation from huge, uses pointers to huge memory Illegal Note that map, multimap, hash_map, and hash_multimap all use the memory
Using C++ NAMESPACE The namespace feature is only supported in Extended EC++. This means that you can use namespaces to partition your code. Note, however, that the library itself is not placed in the std namespace. THE STD NAMESPACE The std namespace is not used in either standard EC++ or in Extended EC++.
Feature descriptions To avoid interrupts, place a call to the intrinsic function __disable_interrupt before the call to _exit.
Efficient coding for embedded applications For embedded systems, the size of the generated code and data is very important, because using smaller external memory or on-chip memory can significantly decrease the cost and power consumption of a system. This chapter gives an overview about how to write code that compiles to efficient code for an embedded application.
Taking advantage of the compilation system CONTROLLING COMPILER OPTIMIZATIONS The AVR IAR C/C++ Compiler allows you to specify whether generated code should be optimized for size or for speed, at a selectable optimization level. The purpose of optimization is to reduce the code size and to improve the execution speed. When only one of these two goals can be reached, the compiler prioritizes according to the settings you specify.
Efficient coding for embedded applications Both compiler options and pragma directives are available for specifying the preferred type and level of optimization. The chapter Compiler options contains reference information about the command line options used for specifying optimization type and level. Refer to the AVR® IAR Embedded Workbench™ IDE User Guide for information about the compiler options available in IAR Embedded Workbench.
Taking advantage of the compilation system Code motion Evaluation of loop-invariant expressions and common subexpressions are moved to avoid redundant re-evaluation. This optimization, which is performed at optimization level Medium, normally reduces code size and execution time. The resulting code might however be difficult to debug. Note: This option has no effect at optimization levels None, and Low.
Efficient coding for embedded applications Clustering of variables When clustering of variables is enabled, static and global variables are arranged so that variables that are accessed in the same function are stored close to each other. This makes it possible for the compiler to use the same base pointer for several accesses. Note: This option has no effect at optimization levels None and Low. Cross call Common code sequences are extracted to local subroutines.
Selecting data types and placing data in memory Putting strings in flash This can be done on individual strings or for the whole application/file using the option --string_literals_in_flash. Examples on how to put individual strings into flash: __flash char str1[] = "abcdef"; __flash char str2[] = "ghi"; __flash char __flash * pVar[] = { str1, str2 }; String literals cannot be put in flash automatically, but you can use a local static variable instead: #include
Efficient coding for embedded applications For details about representation of supported data types, pointers, and structures types, see the chapter Data representation. Floating-point types Using floating-point types on a microprocessor without a math coprocessor is very inefficient, both in terms of code size and execution speed. The AVR IAR C/C++ Compiler supports two floating-point formats—32 and 64 bits. The 32-bit floating-point type float is more efficient in terms of code size and execution speed.
Selecting data types and placing data in memory MEMORY MODEL AND MEMORY ATTRIBUTES FOR DATA For many applications it is sufficient to use the memory model feature to specify the default memory for the data objects. However, for individual objects it might be necessary to specify other memory attributes in certain cases, for example: ● ● ● An application where some global variables are accessed from a large number of locations.
Efficient coding for embedded applications Example In the following example, the members in the anonymous union can be accessed, in function f, without explicitly specifying the union name: struct s { char tag; union { long l; float f; }; } st; void f(void) { st.l = 5; } The member names must be unique in the surrounding scope. Having an anonymous struct or union at file scope, as a global, external, or static variable is also allowed.
Writing efficient code Anonymous structures and unions are implemented in terms of objects named after the first field, with a prefix _A to place the name in the implementation part of the namespace. In this example, the anonymous union will be implemented through an object named _A_IOPORT. Writing efficient code This section contains general programming hints on how to implement functions to make your applications robust, but at the same time facilitate compiler optimizations.
Efficient coding for embedded applications SAVING STACK SPACE AND RAM MEMORY The following is a list of programming techniques that will, when followed, save memory and stack space: ● ● If stack space is limited, avoid long call chains and recursive functions. Avoid using large non-scalar types, such as structures, as parameters or return type; in order to save stack space, you should instead pass them as pointers or, in C++, as references.
Writing efficient code INTEGER TYPES AND BIT NEGATION There are situations when the rules for integer types and their conversion lead to possibly confusing behavior. Things to look out for are assignments or conditionals (test expressions) involving types with different size and logical operations, especially bit negation. Here, types also include types of constants.
Efficient coding for embedded applications Protecting the eeprom write mechanism A typical example of when it can be necessary to use the __monitor keyword is when protecting the eeprom write mechanism, which can be used from two threads (for example, main code and interrupts). Servicing an interrupt during an EEPROM write sequence can in many cases corrupt the written data.
Writing efficient code NON-INITIALIZED VARIABLES Normally, the runtime environment will initialize all global and static variables when the application is started. The compiler supports the declaration of variables that will not be initialized, using the __no_init type modifier. They can be specified either as a keyword or using the #pragma object_attribute directive. The compiler places such variables in separate segments, according to the specified memory keyword.
Part 2. Compiler reference This part of the AVR® IAR C/C++ Compiler Reference Guide contains the following chapters: ● Data representation ● Segment reference ● Compiler options ● Extended keywords ● Pragma directives ● The preprocessor ● Intrinsic functions ● Library functions ● Implementation-defined behavior ● IAR language extensions ● Diagnostics.
136 CAVR-4
Data representation This chapter describes the data types, pointers, and structure types supported by the AVR IAR C/C++ Compiler. See the chapter Efficient coding for embedded applications for information about which data types and pointers provide the most efficient code for your application. Alignment Every C data object has an alignment that controls how the object can be stored in memory.
Basic data types Basic data types The compiler supports both all ISO/ANSI C basic data types and some additional types.
Data representation The char type The char type is by default unsigned in the compiler, but the --char_is_signed compiler option allows you to make it signed. Note, however, that the library is compiled with the char type as unsigned. The wchar_t type The wchar_t data type is an integer type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locals. The wchar_t data type is supported by default in the C++ language.
Basic data types * Depends on whether the --64bit_doubles option is used, see --64bit_doubles, page 201. The type long double use the same precision as double. 32-bit floating-point format The representation of a 32-bit floating-point number as an integer is: 23 22 31 30 S Exponent 0 Mantissa The value of the number is: (-1)S * 2(Exponent-127) * 1.Mantissa The precision of the float operators (+, -, *, and /) is approximately 7 decimal digits.
Data representation The value of a denormalized number is: (-1)S * 2(1-BIAS) * 0.Mantissa where BIAS is 127 and 1023 for 32-bit and 64-bit floating-point values, respectively. Note: The IAR CLIB Library does not fully support the special cases of floating-point numbers, such as infinity, NaN, and subnormal numbers. Pointer types The AVR IAR C/C++ Compiler has two basic types of pointers: function pointers and data pointers.
Pointer types Keyword Pointer size Memory space Index type Range __farflash 3 bytes Code signed int __hugeflash 3 bytes Code signed long 0x0–0xFFFFFF 0x0–0xFFFFFF (16-bit arithmetics) __eeprom 1 byte EEPROM signed char 0x0–0xFF __eeprom 2 bytes EEPROM signed int __generic 2 bytes 3 bytes Data/Code signed int The most significant bit (MSB) signed long determines whether __generic points to CODE (1) or DATA (0).
Data representation ptrdiff_t ptrdiff_t is the type of the signed integer required to hold the difference between two pointers to elements of the same array.
Type and object attributes Example struct { short s; char c; long l; char c2; } s; /* /* /* /* stored stored stored stored in in in in byte byte byte byte 0 and 1 */ 2 */ 4, 5, and 6 */ 7 */ The following diagram shows the layout in memory: s.s 2 bytes s.c 1 byte s.l 4 bytes s.c2 1 byte The alignment of the structure is 1 byte, and its size is 8 bytes. Type and object attributes The AVR IAR C/C++ Compiler provides a set of attributes that support specific features of the AVR microcontroller.
Data representation Type attributes can be further divided into memory attributes and general type attributes. Memory attributes A memory attribute corresponds to a certain logical or physical memory in the microcontroller.
Type and object attributes DECLARING OBJECTS IN SOURCE FILES When declaring objects, note that the IAR-specific attributes work exactly like const. One exception to this is that attributes that are declared in front of the type specifier apply to all declared objects. See More examples, page 21.
Data representation The AVR IAR C/C++ Compiler adheres to these rules for all 8-bit types. The following object types are treated in a special way: Type of object Treated as Global register variables Treated as a non-triggering volatile __io declared variables located in 0x–0x1F An assignment to a bitfield always generates a write access, in some cases also a read access. If only one bit is updated—set or cleared—the sci/cbi instructions are executed.
Data types in C++ AVR® IAR C/C++ Compiler 148 Reference Guide CAVR-4
Segment reference The AVR IAR C/C++ Compiler places code and data into named segments which are referred to by the IAR XLINK Linker™. Details about the segments are required for programming assembler language modules, and are also useful when interpreting the assembler language output from the compiler. For information about how to define segments in the linker command file, see Customizing the linker command file, page 35.
Summary of segments Segment Description Type HEAP Holds the heap used for dynamically allocated data using the CLIB library. DATA HUGE_C Holds __huge declared constant data, including literal strings. DATA HUGE_F Holds static and global __hugeflash variables. CODE HUGE_HEAP Holds the heap used for dynamically allocated data in huge memory using the DLIB library. DATA HUGE_I Holds non-zero initialized static and global __huge variables.
Segment reference Descriptions of segments The following section gives reference information about each segment. For detailed information about the extended keywords mentioned here, see the chapter Extended keywords. CODE Holds __nearfunc program code. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0x01FFFE. Description By default, functions are placed in the CODE segment when using any of the processor options -v0, -v1, -v2, -v3, or -v4.
Descriptions of segments Description Holds the internal data stack. This segment and its length is normally defined in the linker command file with the following command: -Z(DATA)CSTACK+nn=start or -Z(DATA)CSTACK=start-end where nn is the length, start is the first memory location, and end is the last memory location. DIFUNCT Holds pointers to constructor blocks in C++ code. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0xFFFF.
Segment reference EEPROM_I Holds non-zero initialized static and global __eeprom variables. XLINK segment memory type XDATA Memory space EEPROM. Description Holds static and global __eeprom variables that have been defined with non-zero initial values. This segment is not copied to EEPROM during system startup. Instead it is used for programming the EEPROM during the download of the code.
Descriptions of segments Description Holds user program code that has been declared __farfunc. The __farfunc memory attribute is available when using the -v5 and -v6 options, in which case the __farfunc is implicitly used for all functions. FAR_C Holds __far constant data, including string literals. XLINK segment memory type CONST Memory space Data. The address range is 0x0–0xFFFFFF. Description Holds __far constant data, including string literals. Note: This segment is located in external ROM.
Segment reference FAR_HEAP Holds the heap used for dynamically allocated data in far memory when using the DLIB library. XLINK segment memory type DATA Memory space Data. The address range is 0x0–0xFFFFFF. Description This segment holds dynamically allocated data in far memory, in other words data used by far_malloc and far_free, and in C++, new and delete.
Descriptions of segments FAR_ID Holds __far variable initializers. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0x7FFFFF. Description Holds initial values for the variables located in the FAR_I segment. These values are copied from FAR_ID to FAR_I during system initialization. FAR_N Holds __no_init static and global __far variables. XLINK segment memory type DATA Memory space Data. The address range is 0x0–0xFFFFFF.
Segment reference HEAP Used for the heap when using the CLIB library. XLINK segment memory type DATA Memory space Data. The address range depends on the memory model: Memory model Address range Tiny 0x0–0xFF Small 0x0–0xFFFF Large 0x0–0xFFFFFF Table 40: Heap memory address range Description Holds the heap used for dynamically allocated data.
Descriptions of segments HUGE_F Holds static and global __hugeflash variables. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0xFFFFFF. Description Holds static and global __hugeflash variables and aggregate initializers. HUGE_HEAP Holds the heap used for dynamically allocated data in huge memory when using the DLIB library. XLINK segment memory type DATA Memory space Data. The address range is 0x0–0xFFFFFF.
Segment reference Memory space Data. The address range is 0x0–0xFFFFFF. Description Holds static and global __huge variables that have been defined with non-zero initial values. When the -y compiler option is used, __huge constant data is located in this segment. HUGE_ID Holds __huge variable initializers. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0x7FFFFF. Description Holds initial values for the variables located in the HUGE_I segment.
Descriptions of segments HUGE_Z Holds zero-initialized static and global __huge variables. XLINK segment memory type DATA Memory space Data. The address range is 0x0–0xFFFFFF. Description Holds static and global __huge variables that have been declared without initial values or with zero initial values. INITTAB Segment initialization descriptions. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0xFFFF (0x7FFFFF if farflash is enabled).
Segment reference NEAR_C Holds __tiny and __near constant data, including string literals. XLINK segment memory type CONST Memory space Data. The address range is 0x0–0xFFFF. Description Holds __tiny and __near constant data, including string literals. Note: This segment is located in external ROM. Systems without external ROM may not use this segment. NEAR_F Holds static and global __flash variables. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0xFFFF.
Descriptions of segments This segment and its length is normally defined in the linker command file by the command: -Z(DATA)NEAR_HEAP+nn=start where nn is the length and start is the location. For more information about dynamically allocated data and the heap, see The return address stack, page 43. For information about using the new and delete operators for a heap in near memory, see New and Delete operators, page 114. NEAR_I Holds non-zero initialized static and global __near variables.
Segment reference NEAR_N Holds __no_init static and global __near variables. XLINK segment memory type DATA Memory space Data. The address range is 0x0–0xFFFF. Description Holds static and global __near variables that will not be initialized at system startup, for example variables that are to be placed in non-volatile memory. These variables have been declared __no_init. NEAR_Z Holds zero-initialized static and global __near variables. XLINK segment memory type DATA Memory space Data.
Descriptions of segments SWITCH Holds switch tables for all functions. XLINK segment memory type CODE Memory space Flash. The address range is 0x0–0xFFFF. If the __farflash extended keyword and the --enhanced_core option are used, the range is 0x0–0x7FFFFF. This segment must not cross a 64-Kbyte boundary. Description The SWITCH segment is for compiler internal use only and should always be defined. The segment allocates, if necessary, jump tables for C switch statements.
Segment reference This segment and its length is normally defined in the linker command file by the command: -Z(DATA)TINY_HEAP+nn=start where nn is the length and start is the location. For more information about dynamically allocated data and the heap, see The return address stack, page 43. For information about using the new and delete operators for a heap in tiny memory, see New and Delete operators, page 114. TINY_I Holds non-zero initialized static and global __tiny variables.
Descriptions of segments TINY_N Holds __no_init static and global __tiny variables. XLINK segment memory type DATA Memory space Data. The address range is 0x0–0xFF. Description Holds static and global __tiny variables that will not be initialized at system startup, for example variables that are to be placed in non-volatile memory. These variables have been declared __no_init. TINY_Z Holds zero-initialized static and global __tiny variables. XLINK segment memory type DATA Memory space Data.
Compiler options This chapter explains how to set the compiler options from the command line, and gives detailed reference information about each option. Refer to the AVR® IAR Embedded Workbench™ IDE User Guide for information about the compiler options available in IAR Embedded Workbench and how to set them. Setting command line options To set compiler options from the command line, include them on the command line after the iccavr command, either before or after the source filename.
Setting command line options SPECIFYING PARAMETERS When a parameter is needed for an option with a short name, it can be specified either immediately following the option or as the next command line argument. For instance, an include file path of \usr\include can be specified either as: -I\usr\include or as: -I \usr\include Note: / can be used instead of \ as the directory delimiter. Additionally, output file options can take a parameter that is a directory name.
Compiler options SPECIFYING ENVIRONMENT VARIABLES Compiler options can also be specified in the QCCAVR environment variable. The compiler automatically appends the value of this variable to every command line, so it provides a convenient method of specifying options that are required for every compilation.
Options summary Command line option Description -Dsymbol[=value] Defines preprocessor symbols --debug Generates debug information --dependencies[=[i|m]] {filename|directory} Lists file dependencies --diag_error=tag,tag,... Treats these as errors --diag_remark=tag,tag,... Treats these as remarks --diag_suppress=tag,tag,... Suppresses these diagnostics --diag_warning=tag,tag,...
Compiler options Command line option Description -Ipath Specifies include file path --initializers_in_flash Places aggregate initializers in flash memory -l[a|A|b|B|c|C|D][N][H] {filename|directory} Creates a list file --library_module Creates a library module --lock_regs N Locks registers -mname Memory model --memory_model=name Memory model --migration_preprocessor_extensions Extends the preprocessor --misrac Enables MISRA C-specific error messages --misrac_verbose Enables verbose log
Options summary Command line option Description --omit_types Excludes type information --only_stdout Uses standard output only --preinclude includefile Includes an include file before reading the source file --preprocess[=[c][n][l]] {filename|directory} Generates preprocessor output --public_equ symbol[=value] Defines a global named assembler label -r Generates debug information --remarks Enables remarks --require_prototypes Verifies that prototypes are proper --root_variables Specifies va
Compiler options Command line option Description --zero_register Specifies register R15 as zero register --64bit_doubles Use 64-bit doubles --64k_flash Specifies a maximum of 64 Kbytes flash memory. Table 43: Compiler options summary (Continued) Descriptions of options The following section gives detailed reference information about each compiler option. --char_is_signed --char_is_signed By default, the compiler interprets the char type as unsigned.
Descriptions of options --cross_call_passes --cross_call_passes=N Use this option to decrease the RSTACK usage by running the cross-call optimizer N times, where N can be 1–5. The default is to run it until no more improvements can be made. For additional information, see --no_cross_call, page 189. Note: Use this option if you have a target processor with a hardware stack or a small internal return stack segment, RSTACK.
Compiler options Production version: Test version: iccavr prog iccavr prog -DTESTVER To set the equivalent option in IAR Embedded Workbench, select Project>Options>C/C++ Compiler>Preprocessor. --debug, -r --debug -r Use the --debug or -r option to make the compiler include information required by the IAR C-SPY™ Debugger and other symbolic debuggers in the object modules. Note: Including debug information will make the object files larger than otherwise.
Descriptions of options For example: foo.r90: c:\iar\product\include\stdio.h foo.r90: d:\myproject\include\foo.h Example 1 To generate a listing of file dependencies to the file listing.i, use: iccavr prog --dependencies=i listing Example 2 To generate a listing of file dependencies to a file called listing.i in the mypath directory, you would use: iccavr prog --dependencies mypath\listing Note: Both \ and / can be used as directory delimiters.
Compiler options To set the equivalent option in IAR Embedded Workbench, select Project>Options>C/C++ Compiler>Diagnostics. --diag_remark --diag_remark=tag,tag,... Use this option to classify diagnostic messages as remarks. A remark is the least severe type of diagnostic message and indicates a source code construct that may cause strange behavior in the generated code.
Descriptions of options --diagnostics_tables --diagnostics_tables {filename|directory} Use this option to list all possible diagnostic messages in a named file. This can be very convenient, for example, if you have used a pragma directive to suppress or change the severity level of any diagnostic messages, but forgot to document why. This option cannot be given together with other options. If a filename is specified, the compiler stores the output in that file.
Compiler options If you build your own customized runtime library, you should also create a corresponding customized library configuration file, which must be specified to the compiler. For more information, see Building and using a customized library, page 62. Note: This option only applies to the IAR DLIB runtime environment. To set the related option in IAR Embedded Workbench, select Project>Options>General Options>Library Configuration.
Descriptions of options --eec++ --eec++ In the AVR IAR C/C++ Compiler, the default language is C. If you take advantage of Extended Embedded C++ features like namespaces or the standard template library in your source code, you must use this option to set the language the compiler uses to Extended Embedded C++. See IAR Extended Embedded C++, page 110. To set the equivalent option in IAR Embedded Workbench, select Project>Options>C/C++ Compiler>Language.
Compiler options --enable_external_bus --enable_external_bus This option will make the compiler add the special __require statement which will make XLINK include the code in cstartup.s90 that enables the external data bus. Use this option if you intend to place RSTACK in external RAM. Note: The code in cstartup.s90 that enables the external data bus is preferably placed in low_level_inti instead. To set the equivalent option in IAR Embedded Workbench, choose Project>Options>General Options>System.
Descriptions of options -f -f filename Reads command line options from the named file, with the default extension xcl. By default, the compiler accepts command parameters only from the command line itself and the QCCAVR environment variable. To make long command lines more manageable, and to avoid any operating system command line length limit, you can use the -f option to specify a command file, from which the compiler reads command line items as if they had been entered at the position of the option.
Compiler options --header_context --header_context Occasionally, to find the cause of a problem it is necessary to know which header file was included from which source line. Use this option to list, for each diagnostic message, not only the source position of the problem, but also the entire include stack at that point. -I -Ipath -I path Use this option to specify the search path for #include files. This option may be used more than once on a single command line.
Descriptions of options Then the following directories are searched in the order listed below for the file config.h, which in this example is located in the dir\debugconfig directory: dir\include Current file. dir\src File including current file. dir\include As specified with the first -I option. dir\debugconfig As specified with the second -I option. Use angle brackets for standard header files, like stdio.h, and double quotes for files that are part of your application. Note: Both \ and / can be
Compiler options -l -l[a|A|b|B|c|C|D][N][H] {filename|directory} By default, the compiler does not generate a listing. Use this option to generate a listing to a file. The following modifiers are available: Option modifier Description a Assembler list file A Assembler file with C or C++ source as comments b Basic assembler list file.
Descriptions of options Example 2 If you compile the file mysource.c and want to generate a listing to a file mysource.lst in the working directory, you could use: iccavr mysource -l . Note: Both \ and / can be used as directory delimiters. To set the equivalent option in IAR Embedded Workbench, select Project>Options>C/C++ Compiler>List. --library_module --library_module Use this option to make the compiler generate a library module rather than a program module.
Compiler options By default the compiler generates code for the Tiny memory model for all processor options except -v4 and -v6 where the Small memory model is the default. Use the -m or the --memory_model option if you want to generate code for a different memory model. For example, to generate code for the Large memory model, give the command: iccavr filename -ml or: iccavr filename --memory_model=large To read more about the available memory models, see Memory model, page 9.
Descriptions of options Command line option Description --misrac=k-n Enables checking for all MISRA C rules with numbers from k to n --misrac=k,m,r-t Enables checking for MISRA C rules with numbers k, m, and from r to t --misrac=all Enables checking for all MISRA C rules --misrac=required Enables checking for all MISRA C rules categorized as required Table 48: Enabling MISRA C rules (--misrac) (Continued) If the compiler is unable to check for a rule, specifying the option for that rule has no e
Compiler options Example The following example—in which %1 is an operating system variable containing the name of the source file—will give duplicate name errors from the linker: preproc %1.c temp.c iccavr temp.c ; ; ; ; preprocess source, generating temp.c module name is always 'temp' To avoid this, use --module_name=name to retain the original name: preproc %1.c temp.c iccavr temp.c --module_name=%1 ; ; ; ; preprocess source, generating temp.
Descriptions of options For additional information, see --cross_call_passes, page 174. This option is related to the Optimization options in the C/C++ Compiler category in IAR Embedded Workbench. --no_cse --no_cse Use --no_cse to disable common subexpression elimination. At optimization levels 6 and 9, the compiler avoids calculating the same expression more than once. This optimization normally reduces both code size and execution time. However, the resulting code may be difficult to debug.
Compiler options --no_ubrof_messages --no_ubrof_messages Use this option to minimize the size of your application object file by excluding messages from the UBROF files. A file size decrease of up to 60% can be expected. Note that the XLINK diagnostic messages will, however, be less useful when you use this option. This option is related to the Output options in the C/C++ Compiler category in IAR Embedded Workbench. --no_tbaa --no_tbaa Use --no_tbaa to disable type-based alias analysis.
Descriptions of options --no_wrap_diagnostics --no_wrap_diagnostics By default, long lines in compiler diagnostic messages are broken into several lines to make the message easier to read. Use this option to disable line wrapping of diagnostic messages. -o -o {filename|directory} Use the -o option to specify an output file for object code. If a filename is specified, the compiler stores the object code in that file.
Compiler options --only_stdout --only_stdout Use this option to make the compiler use the standard output stream (stdout) also for messages that are normally directed to the error output stream (stderr). --preinclude --preinclude includefile Use this option to make the compiler include the specified include file before it starts to read the source file. This is useful if you want to change something in the source code for the entire application, for instance if you want to define a new symbol.
Descriptions of options To set the equivalent option in IAR Embedded Workbench, select Project>Options>C/C++ Compiler>Preprocessor. --public_equ --public_equ symbol[=value] This option is equivalent to defining a label in assembler language by using the EQU directive and exporting it using the PUBLIC directive. -r, --debug -r --debug Use the -r or the --debug option to make the compiler include information required by the IAR C-SPY Debugger and other symbolic debuggers in the object modules.
Compiler options --root_variables --root_variables Use this option to apply the __root extended keyword to all global and static variables. This will make sure that the variables are not removed by the IAR XLINK Linker. Notice that the --root_variables option is always available, even if you do not specify the compiler option -e, language extensions. This option is related to the Code options in the C/C++ Compiler category in IAR Embedded Workbench.
Descriptions of options For descriptions of the available memory attributes, see Table 7, Memory attributes for data on page 19 and Table 8, Memory attributes for functions on page 28. For a description of the segment name suffixes, see Segment naming, page 37. --separate_cluster_for_ --separate_cluster_for_initialized_variables initialized_variables Separates initialized and non-initialized variables when using variable clustering. Makes the *_ID segments smaller but can generate bigger code.
Compiler options -v -v[0|1|2|3|4|5|6] Use this option to select the processor derivative for which the code is to be generated. The following processor variants are available: Generic processor Processor variant Description -v0 AT90S2313 AT90S2323 AT90S2333 AT90S2343 AT90S4433 ATtiny13 ATtiny26 ATtiny2313 The code space is physically limited to 8 Kbytes, and the RCALL/RJMP instructions are used for reaching the code space. Interrupt vectors are 2 bytes long.
Descriptions of options Generic processor Processor variant Description -v2 Reserved for future derivatives The code space is physically limited to 128 Kbytes, and, if possible, the RCALL/RJMP instructions are used for reaching the code space. If that is not possible, CALL/JMP is used. Function calls through function pointers use ICALL/IJMP. 2 bytes are used for all function pointers. Interrupt vectors are 4 bytes long.
Compiler options Generic processor Processor variant Description -v5 Reserved for future derivatives Allows function calls through farfunc function pointers to cover the entire 8 Mbyte code space by using EICALL/EIJMP. 3 bytes are used for function pointers. Interrupt vectors are 4 bytes long. The compiler assumes that it is possible to have external memory and will therefore generate _C segments.
Descriptions of options --warnings_are_errors --warnings_are_errors Use this option to make the compiler treat all warnings as errors. If the compiler encounters an error, no object code is generated. Warnings that have been changed into remarks are not treated as errors. Note: Any diagnostic messages that have been reclassified as warnings by the compiler option --diag_warning or the #pragma diag_warning directive will also be treated as errors when --warnings_are_errors is used.
Compiler options *The most important difference between -z2 and -z3 is that at level 2, all non-static variables will live during their entire scope. A low level of optimization makes it relatively easy to follow the program flow in the debugger, and, conversely, a high level of optimization makes it relatively hard. Note: The -s and -z options cannot be used at the same time. To set the equivalent option in IAR Embedded Workbench, select Project>Options>C/C++ Compiler>Code.
Descriptions of options AVR® IAR C/C++ Compiler 202 Reference Guide CAVR-4
Extended keywords This chapter describes the extended keywords that support specific features of the AVR microcontroller, the general syntax rules for the keywords, and a detailed description of each keyword. For information about the address ranges of the different memory areas, see the chapter Segment reference. Summary of extended keywords Some extended keywords are used on data, some on functions, and some can be used on both data and functions.
Descriptions of extended keywords The following table summarizes the extended keywords that can be used on data: Extended keywords for data Description @ Controls the storage of data objects and functions __eeprom Controls the storage of data objects in code memory space __ext_io Controls the storage of data objects in I/O memory space Supports I/O instructions; used for SFRs __far Controls the storage of data objects in data memory space __farflash Controls the storage of data objects in code m
Extended keywords asm, __asm The asm and __asm extended keywords both insert an assembler instruction. However, when compiling C source code, the asm keyword is not available when the option --strict_ansi is used. The __asm keyword is always available. Note: Not all assembler directives or operators can be inserted using this keyword. Syntax asm ("string"); The string can be a valid assembler instruction or an assembler directive, but not a comment.
Descriptions of extended keywords __ext_io Controls the storage of data objects in data memory space. The __ext_io memory attribute implies that objects are __no_init and volatile, and allows objects to be accessed by use of the special I/O instructions in the AVR microcontroller.
Extended keywords __farfunc Controls the storage of functions in code memory space. The __farfunc memory attribute places a function in farfunc code memory space. Functions declared __farfunc have no restrictions on code placement, and can be placed anywhere in code memory. The default code pointer for the -v5 and -v6 processor options is __farfunc, and it only affects the size of the function pointers.
Descriptions of extended keywords Using the strcpy_P function declared in pgmspace.h, a string in flash memory can be copied to another string in RAM as follows: strcpy_P(dest, msg); Address range Max object size Pointer size Memory space 0-0xFFFF (64 Kbytes) 65535 bytes 16 bits Code Table 60: Flash address ranges __generic Declares a generic pointer. The __generic pointer type attribute declares a generic pointer that can point to objects in both code and data space.
Extended keywords __hugeflash Controls the storage of data objects in flash (code) memory space. The __hugeflash memory attribute places objects in flash (code) memory. Note that it is preferable to declare flash objects as constant. The __hugeflash memory attribute is only available for AVR chips with at least 64 Kbytes of flash memory.
Descriptions of extended keywords __intrinsic The __intrinsic keyword is reserved for compiler internal use only. __io Controls the storage of data objects in I/O memory space, alternatively data memory space. The __io memory attribute implies that objects are __no_init and volatile, and allows objects to be accessed by use of the special I/O instructions in the AVR microcontroller.
Extended keywords __nearfunc Controls the storage of functions in code memory space. The __nearfunc memory attribute allows you to define the memory range where a function will be located. Functions declared __nearfunc can be called from the entire code memory area, but must reside in the first 128 Kbytes of the code memory. The default for the -v0 to -v4 processor options is __nearfunc, and it only affects the size of the function pointers.
Descriptions of extended keywords __regvar The __regvar extended keyword is used for declaring that a global or static variable should be placed permanently in the specified register or registers. The registers R4–R15 can be used for this purpose, provided that they have been locked with the --lock_regs compiler option; see --lock_regs, page 186 for additional information. Also see Preserved registers, page 101.
Extended keywords __task Allows functions to exit without restoring registers. This keyword is typically used for the main function. By default, functions save the contents of used non-scratch registers (permanent registers) on the stack upon entry, and restore them at exit. Functions declared as __task do not save any registers, and therefore require less stack space. Such functions should only be called from assembler routines.
Descriptions of extended keywords __version_1 The __version_1 keyword is available for backward compatibility. It makes a function use the calling convention of the A90 IAR C Compiler instead of the default calling convention, both which are described in Calling convention, page 99. This calling convention is preferred when calling assembler functions from C.
Pragma directives This chapter describes the pragma directives of the AVR IAR C/C++ Compiler. The pragma directives control the behavior of the compiler, for example how it allocates memory, whether it allows extended keywords, and whether it outputs warning messages. The pragma directives are preprocessed, which means that macros are substituted in a pragma directive. The pragma directives are always enabled in the compiler.
Descriptions of pragma directives Pragma directive Description #pragma object_attribute Changes the definition of a variable or a function #pragma optimize Specifies type and level of optimization #pragma pack Specifies the alignment of structures and union members #pragma required Ensures that a symbol which is needed by another symbol is present in the linked output #pragma rtmodel Adds a runtime model attribute to the module #pragma segment Declares a segment name to be used by intrinsic func
Pragma directives #pragma bitfields #pragma bitfields={reversed|default} The #pragma bitfields directive controls the order of bitfield members. By default, the AVR IAR C/C++ Compiler places bitfield members from the least significant bit to the most significant bit in the container type. Use the #pragma bitfields=reversed directive to place the bitfield members from the most significant to the least significant bit.
Descriptions of pragma directives The segment name cannot be a predefined segment, see the chapter Segment reference for more information. The variable myBuffer will not be initialized at startup, and can for this reason not have any initializer. The memory in which the segment resides is optionally specified using the following syntax: #pragma dataseg=__huge MyOtherSeg All variables in MyOtherSeg will be accessed using huge addressing. #pragma diag_default #pragma diag_default=tag,tag,...
Pragma directives #pragma diag_warning #pragma diag_warning=tag,tag,... Changes the severity level to warning for the specified diagnostics. For example: #pragma diag_warning=Pe826 See the chapter Diagnostics for more information about diagnostic messages. #pragma include_alias #pragma include_alias "orig_header" "subst_header" #pragma include_alias The #pragma include_alias directive makes it possible to provide an alias for a header file.
Descriptions of pragma directives #pragma language #pragma language={extended|default} The #pragma language directive is used for turning on the IAR language extensions or for using the language settings specified on the command line: extended Turns on the IAR language extensions and turns off the --strict_ansi command line option. default Uses the settings specified on the command line.
Pragma directives The following keywords can be used with #pragma object_attribute for a function or variable: __root Ensures that a function or data object is included in the linked application, even if it is not referenced. __noreturn Informs the compiler that the function will not return.
Descriptions of pragma directives Note: If you use the #pragma optimize directive to specify an optimization level that is higher than the optimization level you specify using a compiler option, the pragma directive is ignored. Example #pragma optimize=s 9 int small_and_used_often() { ... } #pragma optimize=z 9 int big_and_seldom_used() { ...
Pragma directives #pragma required #pragma required=symbol Use the #pragma required directive to ensure that a symbol which is needed by another symbol is present in the linked output. The symbol can be any statically linked function or variable, and the pragma directive must be placed immediately before a symbol definition.
Descriptions of pragma directives #pragma segment #pragma segment="segment" [memattr] [align] The #pragma segment directive declares a segment name that can be used by the intrinsic functions __segment_begin and __segment_end. All segment declarations for a specific segment must have the same memory type attribute and alignment. The optional memory attribute memattr will be used in the return type of the intrinsic function. The optional parameter align can be specified to align the segment part.
Pragma directives #pragma vector #pragma vector=vector1[, vector2, vector3, ...] The #pragma vector directive specifies the vector(s) of an interrupt function whose declaration follows the pragma directive. Example #pragma vector=0x14 __interrupt void my_handler(void); Part 2.
Descriptions of pragma directives AVR® IAR C/C++ Compiler 226 Reference Guide CAVR-4
The preprocessor This chapter gives a brief overview of the preprocessor, including reference information about the different preprocessor directives, symbols, and other related information. Overview of the preprocessor The preprocessor of the AVR IAR C/C++ Compiler adheres to the ISO/ANSI standard. The compiler also makes the following preprocessor-related features available to you: ● ● ● ● ● Predefined preprocessor symbols.
Predefined symbols SUMMARY OF PREDEFINED SYMBOLS The following table summarizes the predefined symbols: Predefined symbol Identifies __ALIGNOF__() Accesses the alignment of an object __BASE_FILE__ Identifies the name of the file being compiled. If the file is a header file, the name of the file that includes the header file is identified.
The preprocessor * This symbol is required by the ISO/ANSI standard. Note: The predefined symbol __TID__ is available for backward compatibility. We recommend that you use the symbols __ICCAVR__ and __MEMORY_MODEL__ instead. DESCRIPTIONS OF PREDEFINED SYMBOLS The following section gives reference information about each predefined symbol. __ALIGNOF__() The __ALIGNOF__ operator is used to access the alignment of an object.
Predefined symbols __DATE__ Use this symbol to identify when the file was compiled. This symbol expands to the date of compilation, which is returned in the form "Mmm dd yyyy", for example "Jan 30 2002". __derivative__ Use this symbol to identify the used processor variant. Corresponds to the processor variant that you have specified with the --cpu compiler option.
The preprocessor __HAS_ELPM__ This symbol determines whether the instruction ELPM is available or not. When this symbol is defined, the instruction ELPM is available. When this symbol is not defined, the ELPM instruction is not available. __HAS_ENHANCED_CORE__ This symbol determines whether the enhanced core is available or not. When this symbol is defined, the enhanced core is available. When this symbol is not defined, the enhanced core is not available.
Predefined symbols __IAR_SYSTEMS_ICC__ This predefined symbol expands to a number that identifies the IAR compiler platform. The current identifier is 6. Note that the number could be higher in a future version of the product. This symbol can be tested with #ifdef to detect whether the code was compiled by a compiler from IAR Systems. __ICCAVR__ This predefined symbol expands to the number 1 when the code is compiled with the AVR IAR C/C++ Compiler.
The preprocessor _Pragma() The preprocessor operator _Pragma can be used in defines and has the equivalent effect of the #pragma directive. The syntax is: _Pragma("string") where string follows the syntax for the corresponding pragma directive. For example: #if NO_OPTIMIZE #define NOOPT _Pragma("optimize=2") #else #define NOOPT #endif See the chapter Pragma directives. Note: The -e option—enable language extensions—is not required.
Predefined symbols ● The value (m) corresponding to the --memory_model option in use; where the value 1 corresponds to Tiny, the value 2 corresponds to Small, and the value 3 corresponds to Large.
The preprocessor For detailed information about the calling conventions, see Calling convention, page 99. Preprocessor extensions The following section gives reference information about the extensions that are available in addition to the pragma directives and ISO/ANSI directives. #warning message Use this preprocessor directive to produce messages. Typically this is useful for assertions and other trace utilities, similar to the way the ISO/ANSI standard #error directive is used.
Preprocessor extensions AVR® IAR C/C++ Compiler 236 Reference Guide CAVR-4
Intrinsic functions This chapter gives reference information about the intrinsic functions. The intrinsic functions provide direct access to low-level processor operations and can be very useful in, for example, time-critical routines. The intrinsic functions compile into inline code, either as a single instruction or as a short sequence of instructions.
Descriptions of intrinsic functions Intrinsic function Description __segment_end Returns the end address of a segment __sleep Inserts a SLEEP instruction __swap_nibbles Swaps bit 0-3 with bit 4-7 __watchdog_reset Inserts a watchdog reset instruction Table 72: Intrinsic functions summary (Continued) To use intrinsic functions in an application, include the header file intrinsics.h.
Intrinsic functions __fractional_multiply_signed signed int __fracdtional_multiply_signed(signed char, signed char); Generates a FMULS instruction. __fractional_multiply_signed_ signed int __fractional_multiply_signed_with_unsigned(signed with_unsigned char, unsigned char); Generates a FMULSU instruction. __fractional_multiply_unsigned unsigned int __fractional_multiply_unsigned(unsigned char, unsigned char); Generates a FMUL instruction.
Descriptions of intrinsic functions __multiply_unsigned unsigned int __multiply_unsigned(unsigned char, unsigned char); Generates a MUL instruction. __no_operation void __no_operation(void); Generates a NOP instruction. __require void __require(void *); Sets a constant literal as required. One of the prominent features of the IAR XLINK Linker is its ability to strip away anything that is not needed. This is a very good feature because it reduces the resulting code size to a minimum.
Intrinsic functions signed int unsigned long signed long void __far * __reverse( signed int); __reverse(unsigned long); __reverse( signed long); __reverse(void __far *); /* Only on /* and -v6 void __huge * __reverse(void __huge *); /* Only on /* and -v6 void __farflash * __reverse(void __farflash *); /* Only on -v2 through -v6 with > 64k flash void __hugeflash * __reverse(void __hugeflash *); /* Only on -v2 through -v6 with > 64k flash -v4 */ */ -v4 */ */ memory */ memory */ __save_interrupt unsigned ch
Descriptions of intrinsic functions Note: You must have enabled language extensions to use this intrinsic function. __segment_end void * __segment_end(segment); Returns the address of the first byte after the named segment. The named segment must be a string literal that has been declared earlier with the #pragma segment directive. See #pragma segment, page 224. If the segment was declared with a memory attribute memattr, the type of the __segment_end function is pointer to memattr void.
Library functions This chapter gives an introduction to the C and C++ library functions. It also lists the header files used for accessing library definitions. At the end of this chapter, all AVR-specific library functions are described. For detailed reference information about the library functions, see the online help system. Introduction The AVR IAR C/C++ Compiler provides two different libraries: ● ● IAR DLIB Library is a complete ISO/ANSI C and C++ library.
IAR DLIB Library LIBRARY OBJECT FILES Most of the library definitions can be used without modification, that is, directly from the library object files that are supplied with the product. For information about how to choose a runtime library, see Basic settings for project configuration, page 5. The linker will include only those routines that are required—directly or indirectly—by your application.
Library functions ● ● ● ● ● ● Standard C library definitions, for user programs. Embedded C++ library definitions, for user programs. CSTARTUP, the module containing the start-up code. It is described in the chapter The DLIB runtime environment in this guide. Runtime support libraries; for example low-level floating-point routines. Intrinsic functions, allowing low-level use of AVR features. See the chapter Intrinsic functions for more information.
IAR DLIB Library C++ HEADER FILES This section lists the C++ header files.
Library functions Extended Embedded C++ standard template library The following table lists the Extended Embedded C++ standard template library (STL) header files: Header file Description algorithm Defines several common operations on sequences deque A deque sequence container functional Defines several function objects hash_map A map associative container, based on a hash algorithm hash_set A set associative container, based on a hash algorithm iterator Defines common iterators, and operation
IAR CLIB Library Header file Usage clocale Adapting to different cultural conventions cmath Computing common mathematical functions csetjmp Executing non-local goto statements csignal Controlling various exceptional conditions cstdarg Accessing a varying number of arguments cstddef Defining several useful types and macros cstdio Performing input and output cstdlib Performing a variety of operations cstring Manipulating several kinds of strings ctime Converting between various time and
Library functions LIBRARY DEFINITIONS SUMMARY This section lists the header files. Header files may additionally contain target-specific definitions. Header file Description assert.h Assertions ctype.h* Character handling iccbutl.h Low-level routines math.h Mathematics setjmp.h Non-local jumps stdarg.h Variable arguments stdio.h Input/output stdlib.h General utilities string.
AVR–specific library functions SPECIFYING READ AND WRITE FORMATTERS You can override default formatters for the functions printf_P and scanf_P by editing the linker command file. Note that it is not possible to use the IAR Embedded Workbench interface for overriding the default formatter for the AVR-specific library routines.
Library functions puts_P int puts_P(PGM_P __s); Identical to puts except that the string to be written is in flash memory, not in data memory. This function is available in both the CLIB and the DLIB library. scanf_P int scanf_P(PGM_P __format,…); Identical to scanf except that the format string is in flash memory, not in data memory. This function is available in both the CLIB and the DLIB library.
AVR–specific library functions strcpy_P char * strcpy_P(char *s1, PGM_P s2); Identical to strcpy except that the string s2 being copied is in flash memory, not in data memory. This function is available in both the CLIB and the DLIB library. strerror_P PGM_P strerror_P(int errnum); Identical to strerror except that the string returned is in flash memory, not in data memory. This function is available in both the CLIB and the DLIB library.
Library functions strncpy_P char * strncpy_P(char *s1, PGM_P s2, size_t n); Identical to strncpy except that the source string s2 is in flash memory, not in data memory. This function is available in both the CLIB and the DLIB library. Part 2.
AVR–specific library functions AVR® IAR C/C++ Compiler 254 Reference Guide CAVR-4
Implementation-defined behavior This chapter describes how the AVR IAR C/C++ Compiler handles the implementation-defined areas of the C language. ISO 9899:1990, the International Organization for Standardization standard Programming Languages - C (revision and redesign of ANSI X3.159-1989, American National Standard), changed by the ISO Amendment 1:1994, Technical Corrigendum 1, and Technical Corrigendum 2, contains an appendix called Portability Issues.
Descriptions of implementation-defined behavior ENVIRONMENT Arguments to main (5.1.2.2.2.1) The function called at program startup is called main. There is no prototype declared for main, and the only definition supported for main is: int main(void) To change this behavior for the IAR CLIB runtime environment, see Implementation of cstartup, page 90. To change this behavior for the IAR DLIB runtime environment, see Implementation of system startup code, page 81. Interactive devices (5.1.2.
Implementation-defined behavior See Locale, page 71. Bits per character in execution character set (5.2.4.2.1) The number of bits in a character is represented by the manifest constant CHAR_BIT. The standard include file limits.h defines CHAR_BIT as 8. Mapping of characters (6.1.3.4) The mapping of members of the source character set (in character and string literals) to members of the execution character set is made in a one-to-one way.
Descriptions of implementation-defined behavior INTEGERS Range of integer values (6.1.2.5) The representation of integer values are in the two's complement form. The most significant bit holds the sign; 1 for negative, 0 for positive and zero. See Basic data types, page 138, for information about the ranges for the different integer types. Demotion of integers (6.2.1.2) Converting an integer to a shorter signed integer is made by truncation.
Implementation-defined behavior Demoting floating-point values (6.2.1.4) When a floating-point value is converted to a floating-point value of narrower type that cannot exactly represent the value, the value is rounded (up or down) to the nearest suitable value. ARRAYS AND POINTERS size_t (6.3.3.4, 7.1.1) See size_t, page 142, for information about size_t. Conversion from/to pointers (6.3.4) See Casting, page 142, for information about casting of data pointers and function pointers. ptrdiff_t (6.3.6, 7.
Descriptions of implementation-defined behavior Allocation order of bitfields within a unit (6.5.2.1) Bitfields are allocated within an integer from least-significant to most-significant bit. Can bitfields straddle a storage-unit boundary (6.5.2.1) Bitfields cannot straddle a storage-unit boundary for the chosen bitfield integer type. Integer type chosen to represent enumeration types (6.5.2.
Implementation-defined behavior Including bracketed filenames (6.8.2) For file specifications enclosed in angle brackets, the preprocessor does not search directories of the parent files. A parent file is the file that contains the #include directive. Instead, it begins by searching for the file in the directories specified on the compiler command line. Including quoted filenames (6.8.
Descriptions of implementation-defined behavior include_alias inline instantiate language location memory message module_name none no_pch NOTREACHED object_attribute once optimize pack __printf_args public_equ required rtmodel __scanf_args segment system_include type_attribute VARARGS vector warnings For a description of the pragma directives, see the chapter Pragma directives. Default __DATE__ and __TIME__ (6.8.8) The definitions for __TIME__ and __DATE__ are always available.
Implementation-defined behavior Domain errors (7.5.1) HUGE_VAL, the largest representable value in a double floating-point type, will be returned by the mathematic functions on domain errors. Underflow of floating-point values sets errno to ERANGE (7.5.1) The mathematics functions set the integer expression errno to ERANGE (a macro in errno.h) on underflow range errors. fmod() functionality (7.5.6.
Descriptions of implementation-defined behavior %p in printf() (7.9.6.1) The argument to a %p conversion specifier, print pointer, to printf() is treated as having the type 'char *'. The value will be printed as a hexadecimal number, similar to using the %x conversion specifier. %p in scanf() (7.9.6.2) The %p conversion specifier, scan pointer, to scanf() reads a hexadecimal number and converts it into a value with the type 'void *'. Reading ranges in scanf() (7.9.6.
Implementation-defined behavior Message returned by strerror() (7.11.6.2) The messages returned by strerror() depending on the argument are: Argument Message EZERO no error EDOM domain error ERANGE range error <0 || >99 unknown error all others error No.xx Table 80: Message returned by strerror()—IAR CLIB library The time zone (7.12.1) The time zone function is not supported. clock() (7.12.2.1) The clock() function is not supported.
Descriptions of implementation-defined behavior fmod() functionality (7.5.6.4) If the second argument to fmod() is zero, the function returns NaN; errno is set to EDOM. signal() (7.7.1.1) The signal part of the library is not supported. Note: Low-level interface functions exist in the library, but will not perform anything. Use the template source code to implement application-specific signal handling. See Signal and raise, page 73. Terminating newline character (7.9.
Implementation-defined behavior %p in printf() (7.9.6.1) The argument to a %p conversion specifier, print pointer, to printf() is treated as having the type void *. The value will be printed as a hexadecimal number, similar to using the %x conversion specifier. %p in scanf() (7.9.6.2) The %p conversion specifier, scan pointer, to scanf() reads a hexadecimal number and converts it into a value with the type void *. Reading ranges in scanf() (7.9.6.
Descriptions of implementation-defined behavior system() (7.10.4.5) How the command processor works depends on how you have implemented the system function. See Environment interaction, page 73. Message returned by strerror() (7.11.6.
IAR language extensions This chapter describes IAR language extensions to the ISO/ANSI standard for the C programming language. All extensions can also be used for the C++ programming language. In the IAR Embedded Workbench™ IDE, language extensions are enabled by default. See the compiler options -e on page 179 and --strict_ansi on page 196 for information about how to enable and disable language extensions from the command line.
Descriptions of language extensions See the chapter Extended keywords for a complete list of attributes. Placement at an absolute address or in a named segment The operator @ or the directive #pragma location can be used for placing a variable at an absolute address, or placing a variable or function in a named segment. The named segment can either be a predefined segment, or a user-defined segment.
IAR language extensions Inline assembler Inline assembler can be used for inserting assembler instructions in the generated function. The syntax for inline assembler is: asm("MOVW R4,R7"); In strict ISO/ANSI mode, the use of inline assembler is disabled. For more details about inline assembler, see Mixing C and assembler, page 93. C++ style comments C++ style comments are accepted. A C++ style comment starts with the character sequence // and continues to the end of the line.
Descriptions of language extensions For example, the structure str in the following example contains an anonymous union. The members of the union are accessed using the names b and c, for example obj.b. Without anonymous structure types, the union would have to be named—for example u—and the member elements accessed using the syntax obj.u.b. struct str { int a; union { int b; int c; }; }; struct str obj; Bitfields and non-standard types In ISO/ANSI C, a bitfield must be of the type int or unsigned int.
IAR language extensions Example struct str { char a; unsigned long b[]; }; struct str * GetAStr(int size) { return malloc(sizeof(struct str) + sizeof(unsigned long) * size); } void UseStr(struct str * s) { s->b[10] = 0; } The struct will inherit the alignment requirements from all elements, including the alignment of the incomplete array. The array itself will not be included in the size of the struct.
Descriptions of language extensions Empty translation units A translation unit (source file) is allowed to be empty, that is, it does not have to contain any declarations. In strict ISO/ANSI mode, a warning is issued if the translation unit is empty. Example The following source file is only used in a debug build. (In a debug build, the NDEBUG preprocessor flag is undefined.
IAR language extensions Note: ISO/ANSI C allows extra commas in similar situations, for example after the last element of the initializers to an array. The reason is, that it is easy to get the commas wrong if parts of the list are moved using a normal cut-and-paste operation. Example enum { kOne, kTwo, }; /* This is now allowed. */ Missing semicolon at end of struct or union specifier A warning is issued if the semicolon at the end of a struct or union specifier is missing.
Descriptions of language extensions The following piece of code will generate a warning: switch (x) { case 1: ...; break; default: } A good way to convert this into a standard-compliant C program is to place a break; statement after the default: label. Empty declarations An empty declaration (a semicolon by itself) is allowed, but a remark is issued (provided that remarks are enabled). This is useful when preprocessor macros are used that could expand to nothing. Consider the following example.
IAR language extensions Casting pointers to integers in static initializers In an initializer, a pointer constant value may be cast to an integral type if the integral type is large enough to contain it. In the following example, it is assumed that pointers to __near and __huge are 16 and 32 bits, respectively. The first initialization is correct, because it is possible to cast the 16-bit address to a 16-bit unsigned short variable.
Descriptions of language extensions Repeated typedefs Redeclarations of typedef that occur in the same scope are allowed, but a warning is issued. Mixing pointer types Assignment and pointer difference is allowed between pointers to types that are interchangeable but not identical; for example, unsigned char * and char *. This includes pointers to integral types of the same size. A warning is issued.
Diagnostics This chapter describes the format of the diagnostic messages and explains how diagnostic messages are divided into different levels of severity. Message format All diagnostic messages are issued as complete, self-explanatory messages.
Severity levels Error A diagnostic that is produced when the compiler has found a construct which clearly violates the C or C++ language rules, such that code cannot be produced. An error will produce a non-zero exit code. Fatal error A diagnostic that is produced when the compiler has found a condition that not only prevents code generation, but which makes further processing of the source code pointless. After the diagnostic has been issued, compilation terminates.
Index Index A absolute location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 #pragma location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 absolute placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 aggregate initializers, placing in flash memory . . . . . . . . . 184 algorithm (STL header file) . . . . . . . . . . . . . . . . . . . . . . . 247 alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C C and C++ linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 C calling convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 C header files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 call chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 call stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 callee-save registers, stored on stack . . . . . . . . . . . . . . . . . .
Index locating _ _tiny variables . . . . . . . . . . . . . . . . . . . . 165 -z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 --char_is_signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 --cpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 mapping of AVR derivatives . . . . . . . . . . . . . . . . . . . . 6 --cross_call_passes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 --debug . . . . . . . . . . .
const_cast (cast operator) . . . . . . . . . . . . . . . . . . . . . . . . . 110 conventions, typographic . . . . . . . . . . . . . . . . . . . . . . . . . xxii copyright notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii _ _CORE_ _ (predefined symbol) . . . . . . . . . . . . . . . . . . . 229 cores, mapping of processor options . . . . . . . . . . . . . . . . . . . 6 _ _CPU_ _ (predefined symbol) . . . . . . . . . . . . . . . . . . . .
Index classifying as errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 classifying as remarks . . . . . . . . . . . . . . . . . . . . . . . . . 177 classifying as warnings . . . . . . . . . . . . . . . . . . . . . . . . 177 disabling warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 disabling wrapping of . . . . . . . . . . . . . . . . . . . . . . . . . 192 enabling remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 listing all used . . . . . . . . . . .
exception vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 exception (library header file) . . . . . . . . . . . . . . . . . . . . . . 246 experience, programming . . . . . . . . . . . . . . . . . . . . . . . . . xix export keyword, missing from Extended EC++ . . . . . . . . 115 Extended Embedded C++ . . . . . . . . . . . . . . . . . . . . . . . . . 110 enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 standard template library (STL) . . . . . . .
Index hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 floating-point format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126–127 implementation-defined behavior . . . . . . . . . . . . . . . . . 258 special cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 32-bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 64-bits .
C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 EC++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 errno.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 float.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 iccbutl.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 limits.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index interrupt vectors, specifying with pragma directive. . . . . . 225 interrupts disabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 disabling during function execution . . . . . . . . . . . . . . . . 30 INTVEC segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 processor state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 interrupts and EC++ destructors, using . . . . . . . . . . . . . . . 119 intptr_t (integer type) . . . . . . . . .
memcpy_G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 memcpy_P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 printf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 printf_P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 putchar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 puts_G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index malloc (standard library function) . . . . . . . . . . . . . . . . . . . . 25 map (STL header file) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 math.h (library header file) . . . . . . . . . . . . . . . . . 83, 245, 249 _medium_write (library function) . . . . . . . . . . . . . . . . . . . . 88 memcmp_G (library function) . . . . . . . . . . . . . . . . . . . . . 250 memcpy_G (library function) . . . . . . . . . . . . . . . . . . . . . . 250 memcpy_P (library function) . . . . . . . .
new (keyword) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 new (library header file) . . . . . . . . . . . . . . . . . . . . . . . . . . 246 new.h (library header file) . . . . . . . . . . . . . . . . . . . . . . . . . 246 non-initialized variables . . . . . . . . . . . . . . . . . . . . . . . . . . 134 non-scalar parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 non-volatile memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index implementation-defined behavior . . . . . . . . . . . . . . . . . 259 to constructor blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 152 using instead of large non-scalar parameters . . . . . . . . 131 polymorphism, in Embedded C++ . . . . . . . . . . . . . . . . . . 109 porting, of code containing pragma directives . . . . . . . . . . . . . . . . . . . . . . 216 Postlink (utility) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 postlink.htm . . . . . . . . . . . . . .
preprocessor output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 preprocessor symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 defining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 NDEBUG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 preprocessor, extending. . . . . . . . . . . . . . . . . . . . . . . . . . . 187 prerequisites (programming experience) . . . . . . . . . . . . . .
Index routines, time-critical . . . . . . . . . . . . . . . . . . . . . . . . . 93, 237 RSEG (assembler directive) . . . . . . . . . . . . . . . . . . . . . . . . 81 RSTACK (segment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 RSTACK, size of stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 RTMODEL (assembler directive) . . . . . . . . . . . . . . . . . . . . 78 rtmodel (pragma directive) . . . . . . . . . . . . . . . . . . . . . . . . 223 rtti support, missing from STL .
TINY_Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 _ _segment_begin (intrinsic function) . . . . . . . . . . . . . . . . 241 _ _segment_end (intrinsic function) . . . . . . . . . . . . . . . . . 242 SEI (assembler instruction) . . . . . . . . . . . . . . . . . . . . . . . . 238 semaphores, operations on . . . . . . . . . . . . . . . . . . . . . . . . 210 set (STL header file) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 setjmp.h (library header file) . . . .
Index stdio.h (library header file) . . . . . . . . . . . . . . . . . 83, 245, 249 stdlib.h (library header file) . . . . . . . . . . . . . . . . . 83, 245, 249 stdout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70, 193 STL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 strcat_G (library function) . . . . . . . . . . . . . . . . . . . . . . . . 251 strcmp_G (library function) . . . . . . . . . . . . . . . . . . . . . . .
type-safe memory management . . . . . . . . . . . . . . . . . . . . 109 type_attribute (pragma directive) . . . . . . . . . . . . . . . . . . . 224 typographic conventions . . . . . . . . . . . . . . . . . . . . . . . . . . xxii U UBROF messages, excluding from object file . . . . . . . . . 191 uintptr_t (integer type) . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 unions anonymous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 implementation-defined behavior . . . . . .
Index -o (compiler option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 -r (compiler option). . . . . . . . . . . . . . . . . . . . . . . . . . 175, 194 -s (compiler option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 -v (compiler option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 mapping of AVR derivatives . . . . . . . . . . . . . . . . . . . . . . 6 -y (compiler option) . . . . . . . . . . . . . . . . . . . . . 155, 165, 200 -z (compiler option) . .
_ _CORE_ _ (predefined symbol) . . . . . . . . . . . . . . . . . . . 229 _ _cplusplus (predefined symbol) . . . . . . . . . . . . . . . . . . . 229 _ _cpu (runtime model attribute) . . . . . . . . . . . . . . . . . . . . . 79 _ _CPU_ _ (predefined symbol) . . . . . . . . . . . . . . . . . . . . 229 _ _cpu_name (runtime model attribute) . . . . . . . . . . . . . . . 79 _ _DATE_ _ (predefined symbol) . . . . . . . . . . . . . . . . . . . 230 _ _delay_cycles (intrinsic function) . . . . . . . . . . . . . . . .
Index _ _sleep (intrinsic function) . . . . . . . . . . . . . . . . . . . . . . . 242 _ _STDC_ _ (predefined symbol) . . . . . . . . . . . . . . . . . . . 233 _ _STDC_VERSION_ _ (predefined symbol) . . . . . . . . . 233 _ _swap_nibbles (intrinsic function) . . . . . . . . . . . . . . . . . 242 _ _task (extended keyword) . . . . . . . . . . . . . . . . . . . . . . . 213 _ _TID_ _ (predefined symbol) . . . . . . . . . . . . . . . . . . . . . 233 _ _TIME_ _ (predefined symbol) . . . . . . . . . . . . . . . .
