You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
563 lines
31 KiB
HTML
563 lines
31 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
|
|
<title>avr-libc: Using the GNU tools</title>
|
|
<link href="dox.css" rel="stylesheet" type="text/css">
|
|
</head>
|
|
<body>
|
|
<center>
|
|
<table width="80%">
|
|
<tr>
|
|
<td align="left"><a href="http://www.nongnu.org/avr-libc/">AVR Libc Home Page</a></td>
|
|
<td align="center" colspan=4><img src="avrs.png" alt="AVRs" align="middle" border="0"></td>
|
|
<td align="right"><a href="https://savannah.nongnu.org/projects/avr-libc/">AVR Libc Development Pages</a></td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" width="13%"><a href="index.html">Main Page</a></td>
|
|
<td align="center" width="13%"><a href="pages.html">User Manual</a></td>
|
|
<td align="center" width="13%"><a href="modules.html">Library Reference</a></td>
|
|
<td align="center" width="13%"><a href="FAQ.html">FAQ</a></td>
|
|
<td align="center" width="13%"><a href="globals.html">Alphabetical Index</a></td>
|
|
<td align="center" width="13%"><a href="group__demos.html">Example Projects</a></td>
|
|
</tr>
|
|
</table>
|
|
</center>
|
|
<hr width="80%">
|
|
<!-- Generated by Doxygen 1.5.6 -->
|
|
<div class="contents">
|
|
<h1><a class="anchor" name="using_tools">Using the GNU tools </a></h1>This is a short summary of the AVR-specific aspects of using the GNU tools. Normally, the generic documentation of these tools is fairly large and maintained in <code>texinfo</code> files. Command-line options are explained in detail in the manual page.<h2><a class="anchor" name="using_avr_gcc">
|
|
Options for the C compiler avr-gcc</a></h2>
|
|
<h3><a class="anchor" name="using_avr_gcc_mach_opt">
|
|
Machine-specific options for the AVR</a></h3>
|
|
The following machine-specific options are recognized by the C compiler frontend. In addition to the preprocessor macros indicated in the tables below, the preprocessor will define the macros __AVR and __AVR__ (to the value 1) when compiling for an AVR target. The macro AVR will be defined as well when using the standard levels gnu89 (default) and gnu99 but not with c89 and c99.<p>
|
|
<ul>
|
|
<li><code>-mmcu=</code><em>architecture</em> </li></ul>
|
|
<p>
|
|
Compile code for <em>architecture</em>. Currently known architectures are <p>
|
|
<table border="1" cellspacing="3" cellpadding="3">
|
|
<tr>
|
|
<td>Architecture </td><td>Macros </td><td>Description </td></tr>
|
|
<tr>
|
|
<td>avr1 </td><td>__AVR_ARCH__=1<br>
|
|
__AVR_ASM_ONLY__<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>Simple CPU core, only assembler support </td></tr>
|
|
<tr>
|
|
<td>avr2 </td><td>__AVR_ARCH__=2<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Classic" CPU core, up to 8 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr25 [1] </td><td>__AVR_ARCH__=25<br>
|
|
__AVR_HAVE_MOVW__ [1]<br>
|
|
__AVR_HAVE_LPMX__ [1]<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Classic" CPU core with 'MOVW' and 'LPM Rx, Z[+]' instruction, up to 8 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr3 </td><td>__AVR_ARCH__=3<br>
|
|
__AVR_MEGA__ [5]<br>
|
|
__AVR_HAVE_JMP_CALL__ [4]<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Classic" CPU core, 16 KB to 64 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr31 </td><td>__AVR_ARCH__=31<br>
|
|
__AVR_MEGA__<br>
|
|
__AVR_HAVE_RAMPZ__[4]<br>
|
|
__AVR_HAVE_ELPM__[4]<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Classic" CPU core, 128 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr35 [3] </td><td>__AVR_ARCH__=35<br>
|
|
__AVR_MEGA__ [5]<br>
|
|
__AVR_HAVE_JMP_CALL__ [4]<br>
|
|
__AVR_HAVE_MOVW__ [1]<br>
|
|
__AVR_HAVE_LPMX__ [1]<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Classic" CPU core with 'MOVW' and 'LPM Rx, Z[+]' instruction, 16 KB to 64 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr4 </td><td>__AVR_ARCH__=4<br>
|
|
__AVR_ENHANCED__ [5]<br>
|
|
__AVR_HAVE_MOVW__ [1]<br>
|
|
__AVR_HAVE_LPMX__ [1]<br>
|
|
__AVR_HAVE_MUL__ [1]<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Enhanced" CPU core, up to 8 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr5 </td><td>__AVR_ARCH__=5<br>
|
|
__AVR_MEGA__ [5]<br>
|
|
__AVR_ENHANCED__ [5]<br>
|
|
__AVR_HAVE_JMP_CALL__ [4]<br>
|
|
__AVR_HAVE_MOVW__ [1]<br>
|
|
__AVR_HAVE_LPMX__ [1]<br>
|
|
__AVR_HAVE_MUL__ [1]<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Enhanced" CPU core, 16 KB to 64 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr51 </td><td>__AVR_ARCH__=51<br>
|
|
__AVR_MEGA__<br>
|
|
__AVR_ENHANCED__<br>
|
|
__AVR_HAVE_MOVW__ [1]<br>
|
|
__AVR_HAVE_LPMX__ [1]<br>
|
|
__AVR_HAVE_MUL__ [1]<br>
|
|
__AVR_HAVE_RAMPZ__[4]<br>
|
|
__AVR_HAVE_ELPM__[4]<br>
|
|
__AVR_HAVE_ELPMX__[4]<br>
|
|
__AVR_2_BYTE_PC__ [2] </td><td>"Enhanced" CPU core, 128 KB of ROM </td></tr>
|
|
<tr>
|
|
<td>avr6 [2] </td><td>__AVR_ARCH__=6<br>
|
|
__AVR_MEGA__ [5]<br>
|
|
__AVR_ENHANCED__ [5]<br>
|
|
__AVR_HAVE_JMP_CALL__ [4]<br>
|
|
__AVR_HAVE_MOVW__ [1]<br>
|
|
__AVR_HAVE_LPMX__ [1]<br>
|
|
__AVR_HAVE_MUL__ [1]<br>
|
|
__AVR_HAVE_RAMPZ__[4]<br>
|
|
__AVR_HAVE_ELPM__[4]<br>
|
|
__AVR_HAVE_ELPMX__[4]<br>
|
|
__AVR_3_BYTE_PC__ [2] </td><td>"Enhanced" CPU core, 256 KB of ROM </td></tr>
|
|
</table>
|
|
<p>
|
|
[1] New in GCC 4.2<br>
|
|
[2] Unofficial patch for GCC 4.1<br>
|
|
[3] New in GCC 4.2.3<br>
|
|
[4] New in GCC 4.3<br>
|
|
[5] Obsolete. <p>
|
|
By default, code is generated for the avr2 architecture. <p>
|
|
Note that when only using <code>-mmcu=</code><em>architecture</em> but no <code>-mmcu=</code><em>MCU type</em>, including the file <code><<a class="el" href="io_8h.html">avr/io.h</a>></code> cannot work since it cannot decide which device's definitions to select. <p>
|
|
<ul>
|
|
<li><code>-mmcu=</code><em>MCU type</em> </li></ul>
|
|
<p>
|
|
The following MCU types are currently understood by avr-gcc. The table matches them against the corresponding avr-gcc architecture name, and shows the preprocessor symbol declared by the <code>-mmcu</code> option. <p>
|
|
<table border="1" cellspacing="3" cellpadding="3">
|
|
<tr>
|
|
<td>Architecture</td><td>MCU name</td><td>Macro </td></tr>
|
|
<tr>
|
|
<td>avr1</td><td>at90s1200</td><td>__AVR_AT90S1200__ </td></tr>
|
|
<tr>
|
|
<td>avr1</td><td>attiny11</td><td>__AVR_ATtiny11__ </td></tr>
|
|
<tr>
|
|
<td>avr1</td><td>attiny12</td><td>__AVR_ATtiny12__ </td></tr>
|
|
<tr>
|
|
<td>avr1</td><td>attiny15</td><td>__AVR_ATtiny15__ </td></tr>
|
|
<tr>
|
|
<td>avr1</td><td>attiny28</td><td>__AVR_ATtiny28__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s2313</td><td>__AVR_AT90S2313__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s2323</td><td>__AVR_AT90S2323__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s2333</td><td>__AVR_AT90S2333__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s2343</td><td>__AVR_AT90S2343__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>attiny22</td><td>__AVR_ATtiny22__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>attiny26</td><td>__AVR_ATtiny26__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s4414</td><td>__AVR_AT90S4414__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s4433</td><td>__AVR_AT90S4433__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s4434</td><td>__AVR_AT90S4434__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s8515</td><td>__AVR_AT90S8515__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90c8534</td><td>__AVR_AT90C8534__ </td></tr>
|
|
<tr>
|
|
<td>avr2</td><td>at90s8535</td><td>__AVR_AT90S8535__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>at86rf401</td><td>__AVR_AT86RF401__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny13</td><td>__AVR_ATtiny13__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny13a</td><td>__AVR_ATtiny13A__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny2313</td><td>__AVR_ATtiny2313__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny24</td><td>__AVR_ATtiny24__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny25</td><td>__AVR_ATtiny25__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny261</td><td>__AVR_ATtiny261__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny43u</td><td>__AVR_ATtiny43U__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny44</td><td>__AVR_ATtiny44__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny45</td><td>__AVR_ATtiny45__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny461</td><td>__AVR_ATtiny461__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny48</td><td>__AVR_ATtiny48__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny84</td><td>__AVR_ATtiny84__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny85</td><td>__AVR_ATtiny85__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny861</td><td>__AVR_ATtiny861__ </td></tr>
|
|
<tr>
|
|
<td>avr2/avr25 [1]</td><td>attiny88</td><td>__AVR_ATtiny88__ </td></tr>
|
|
<tr>
|
|
<td>avr3</td><td>atmega603</td><td>__AVR_ATmega603__ </td></tr>
|
|
<tr>
|
|
<td>avr3</td><td>at43usb355</td><td>__AVR_AT43USB355__ </td></tr>
|
|
<tr>
|
|
<td>avr3/avr31 [3]</td><td>atmega103</td><td>__AVR_ATmega103__ </td></tr>
|
|
<tr>
|
|
<td>avr3/avr31 [3]</td><td>at43usb320</td><td>__AVR_AT43USB320__ </td></tr>
|
|
<tr>
|
|
<td>avr3/avr35 [2]</td><td>at90usb82</td><td>__AVR_AT90USB82__ </td></tr>
|
|
<tr>
|
|
<td>avr3/avr35 [2]</td><td>at90usb162</td><td>__AVR_AT90USB162__ </td></tr>
|
|
<tr>
|
|
<td>avr3/avr35 [2]</td><td>attiny167</td><td>__AVR_ATtiny167__ </td></tr>
|
|
<tr>
|
|
<td>avr3</td><td>at76c711</td><td>__AVR_AT76C711__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega48</td><td>__AVR_ATmega48__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega48p</td><td>__AVR_ATmega48P__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega8</td><td>__AVR_ATmega8__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega8515</td><td>__AVR_ATmega8515__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega8535</td><td>__AVR_ATmega8535__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega88</td><td>__AVR_ATmega88__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega88p</td><td>__AVR_ATmega88P__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>atmega8hva</td><td>__AVR_ATmega8HVA__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>at90pwm1</td><td>__AVR_AT90PWM1__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>at90pwm2</td><td>__AVR_AT90PWM2__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>at90pwm2b</td><td>__AVR_AT90PWM2B__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>at90pwm3</td><td>__AVR_AT90PWM3__ </td></tr>
|
|
<tr>
|
|
<td>avr4</td><td>at90pwm3b</td><td>__AVR_AT90PWM3B__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>at90pwm216</td><td>__AVR_AT90PWM216__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>at90pwm316</td><td>__AVR_AT90PWM316__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>at90can32</td><td>__AVR_AT90CAN32__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>at90can64</td><td>__AVR_AT90CAN64__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>at90usb646</td><td>__AVR_AT90USB646__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>at90usb647</td><td>__AVR_AT90USB647__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega16</td><td>__AVR_ATmega16__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega161</td><td>__AVR_ATmega161__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega162</td><td>__AVR_ATmega162__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega163</td><td>__AVR_ATmega163__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega164p</td><td>__AVR_ATmega164P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega165</td><td>__AVR_ATmega165__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega165p</td><td>__AVR_ATmega165P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega168</td><td>__AVR_ATmega168__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega168p</td><td>__AVR_ATmega168P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega169</td><td>__AVR_ATmega169__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega169p</td><td>__AVR_ATmega169P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega16hva</td><td>__AVR_ATmega16HVA__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega32</td><td>__AVR_ATmega32__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega323</td><td>__AVR_ATmega323__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega324p</td><td>__AVR_ATmega324P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega325</td><td>__AVR_ATmega325__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega325p</td><td>__AVR_ATmega325P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega3250</td><td>__AVR_ATmega3250__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega3250p</td><td>__AVR_ATmega3250P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega328p</td><td>__AVR_ATmega328P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega329</td><td>__AVR_ATmega329__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega329p</td><td>__AVR_ATmega329P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega3290</td><td>__AVR_ATmega3290__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega3290p</td><td>__AVR_ATmega3290P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega32c1</td><td>__AVR_ATMEGA32C1__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega32hvb</td><td>__AVR_ATmega32HVB__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega32m1</td><td>__AVR_ATMEGA32M1__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega32u4</td><td>__AVR_ATMEGA32U4__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega32u6</td><td>__AVR_ATMEGA32U6__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega406</td><td>__AVR_ATmega406__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega64</td><td>__AVR_ATmega64__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega640</td><td>__AVR_ATmega640__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega644</td><td>__AVR_ATmega644__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega644p</td><td>__AVR_ATmega644P__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega645</td><td>__AVR_ATmega645__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega6450</td><td>__AVR_ATmega6450__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega649</td><td>__AVR_ATmega649__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>atmega6490</td><td>__AVR_ATmega6490__ </td></tr>
|
|
<tr>
|
|
<td>avr5</td><td>at94k</td><td>__AVR_AT94K__ </td></tr>
|
|
<tr>
|
|
<td>avr5/avr51 [3]</td><td>atmega128</td><td>__AVR_ATmega128__ </td></tr>
|
|
<tr>
|
|
<td>avr5/avr51 [3]</td><td>atmega1280</td><td>__AVR_ATmega1280__ </td></tr>
|
|
<tr>
|
|
<td>avr5/avr51 [3]</td><td>atmega1281</td><td>__AVR_ATmega1281__ </td></tr>
|
|
<tr>
|
|
<td>avr5/avr51 [3]</td><td>atmega1284p</td><td>__AVR_ATmega1284P__ </td></tr>
|
|
<tr>
|
|
<td>avr5/avr51 [3]</td><td>at90can128</td><td>__AVR_AT90CAN128__ </td></tr>
|
|
<tr>
|
|
<td>avr5/avr51 [3]</td><td>at90usb1286</td><td>__AVR_AT90USB1286__ </td></tr>
|
|
<tr>
|
|
<td>avr5/avr51 [3]</td><td>at90usb1287</td><td>__AVR_AT90USB1287__ </td></tr>
|
|
<tr>
|
|
<td>avr6</td><td>atmega2560</td><td>__AVR_ATmega2560__ </td></tr>
|
|
<tr>
|
|
<td>avr6</td><td>atmega2561</td><td>__AVR_ATmega2561__ </td></tr>
|
|
<tr>
|
|
<td>avrxmega4</td><td>atxmega64a3</td><td>__AVR_ATxmega64A3__ </td></tr>
|
|
<tr>
|
|
<td>avrxmega5</td><td>atxmega64a1</td><td>__AVR_ATxmega64A1__ </td></tr>
|
|
<tr>
|
|
<td>avrxmega6</td><td>atxmega128a3</td><td>__AVR_ATxmega128A3__ </td></tr>
|
|
<tr>
|
|
<td>avrxmega6</td><td>atxmega256a3</td><td>__AVR_ATxmega256A3__ </td></tr>
|
|
<tr>
|
|
<td>avrxmega6</td><td>atxmega256a3b</td><td>__AVR_ATxmega256A3B__ </td></tr>
|
|
<tr>
|
|
<td>avrxmega7</td><td>atxmega128a1</td><td>__AVR_ATxmega128A1__<p>
|
|
</td></tr>
|
|
</table>
|
|
<p>
|
|
[1] 'avr25' architecture is new in GCC 4.2<br>
|
|
[2] 'avr35' architecture is new in GCC 4.2.3 <p>
|
|
<ul>
|
|
<li><code>-morder1</code> </li><li><code>-morder2</code> </li></ul>
|
|
<p>
|
|
Change the order of register assignment. The default is <p>
|
|
r24, r25, r18, r19, r20, r21, r22, r23, r30, r31, r26, r27, r28, r29, r17, r16, r15, r14, r13, r12, r11, r10, r9, r8, r7, r6, r5, r4, r3, r2, r0, r1 <p>
|
|
Order 1 uses <p>
|
|
r18, r19, r20, r21, r22, r23, r24, r25, r30, r31, r26, r27, r28, r29, r17, r16, r15, r14, r13, r12, r11, r10, r9, r8, r7, r6, r5, r4, r3, r2, r0, r1 <p>
|
|
Order 2 uses <p>
|
|
r25, r24, r23, r22, r21, r20, r19, r18, r30, r31, r26, r27, r28, r29, r17, r16, r15, r14, r13, r12, r11, r10, r9, r8, r7, r6, r5, r4, r3, r2, r1, r0 <p>
|
|
<ul>
|
|
<li><code>-mint8</code> </li></ul>
|
|
<p>
|
|
Assume <code>int</code> to be an 8-bit integer. Note that this is not really supported by <code>avr-libc</code>, so it should normally not be used. The default is to use 16-bit integers. <p>
|
|
<ul>
|
|
<li><code>-mno-interrupts</code> </li></ul>
|
|
<p>
|
|
Generates code that changes the stack pointer without disabling interrupts. Normally, the state of the status register <code>SREG</code> is saved in a temporary register, interrupts are disabled while changing the stack pointer, and <code>SREG</code> is restored. <p>
|
|
Specifying this option will define the preprocessor macro <code>__NO_INTERRUPTS__</code> to the value 1. <p>
|
|
<ul>
|
|
<li><code>-mcall-prologues</code> </li></ul>
|
|
<p>
|
|
Use subroutines for function prologue/epilogue. For complex functions that use many registers (that needs to be saved/restored on function entry/exit), this saves some space at the cost of a slightly increased execution time. <p>
|
|
<ul>
|
|
<li><code>-mtiny-stack</code> </li></ul>
|
|
<p>
|
|
Change only the low 8 bits of the stack pointer. <p>
|
|
<ul>
|
|
<li><code>-mno-tablejump</code> </li></ul>
|
|
<p>
|
|
Do not generate tablejump instructions. By default, jump tables can be used to optimize <code>switch</code> statements. When turned off, sequences of compare statements are used instead. Jump tables are usually faster to execute on average, but in particular for <code>switch</code> statements where most of the jumps would go to the default label, they might waste a bit of flash memory. <p>
|
|
<ul>
|
|
<li><code>-mshort-calls</code> </li></ul>
|
|
<p>
|
|
Use <code>rjmp/rcall</code> (limited range) on >8K devices. On <code>avr2</code> and <code>avr4</code> architectures (less than 8 KB or flash memory), this is always the case. On <code>avr3</code> and <code>avr5</code> architectures, calls and jumps to targets outside the current function will by default use <code>jmp/call</code> instructions that can cover the entire address range, but that require more flash ROM and execution time. <p>
|
|
<ul>
|
|
<li><code>-mrtl</code> </li></ul>
|
|
<p>
|
|
Dump the internal compilation result called "RTL" into comments in the generated assembler code. Used for debugging avr-gcc. <p>
|
|
<ul>
|
|
<li><code>-msize</code> </li></ul>
|
|
<p>
|
|
Dump the address, size, and relative cost of each statement into comments in the generated assembler code. Used for debugging avr-gcc. <p>
|
|
<ul>
|
|
<li><code>-mdeb</code> </li></ul>
|
|
<p>
|
|
Generate lots of debugging information to <code>stderr</code>. <h3><a class="anchor" name="using_sel_gcc_opts">
|
|
Selected general compiler options</a></h3>
|
|
The following general gcc options might be of some interest to AVR users.<p>
|
|
<ul>
|
|
<li><code>-O</code><em>n</em> </li></ul>
|
|
<p>
|
|
<a class="anchor" name="gcc_optO"></a> Optimization level <em>n</em>. Increasing <em>n</em> is meant to optimize more, an optimization level of 0 means no optimization at all, which is the default if no <code>-O</code> option is present. The special option <code>-Os</code> is meant to turn on all <code>-O2</code> optimizations that are not expected to increase code size. <p>
|
|
Note that at <code>-O3</code>, gcc attempts to inline all "simple" functions. For the AVR target, this will normally constitute a large pessimization due to the code increasement. The only other optimization turned on with <code>-O3</code> is <code>-frename-registers</code>, which could rather be enabled manually instead. <p>
|
|
A simple <code>-O</code> option is equivalent to <code>-O1</code>. <p>
|
|
Note also that turning off all optimizations will prevent some warnings from being issued since the generation of those warnings depends on code analysis steps that are only performed when optimizing (unreachable code, unused variables). <p>
|
|
See also the <a class="el" href="FAQ.html#faq_gdboptimize">appropriate FAQ entry</a> for issues regarding debugging optimized code. <p>
|
|
<ul>
|
|
<li><code>-Wa,</code><em>assembler-options</em></li><li><code>-Wl,</code><em>linker-options</em> </li></ul>
|
|
<p>
|
|
<a class="anchor" name="gcc_minusW"></a> Pass the listed options to the assembler, or linker, respectively. <p>
|
|
<ul>
|
|
<li><code>-g</code> </li></ul>
|
|
<p>
|
|
Generate debugging information that can be used by avr-gdb. <p>
|
|
<ul>
|
|
<li><code>-ffreestanding</code> </li></ul>
|
|
<p>
|
|
Assume a "freestanding" environment as per the C standard. This turns off automatic builtin functions (though they can still be reached by prepending <code>__builtin_</code> to the actual function name). It also makes the compiler not complain when <code>main()</code> is declared with a <code>void</code> return type which makes some sense in a microcontroller environment where the application cannot meaningfully provide a return value to its environment (in most cases, <code>main()</code> won't even return anyway). However, this also turns off all optimizations normally done by the compiler which assume that functions known by a certain name behave as described by the standard. E. g., applying the function <a class="el" href="group__avr__string.html#g7fd4936b86eb6b87e98587044c562715" title="Calculate the length of a string.">strlen()</a> to a literal string will normally cause the compiler to immediately replace that call by the actual length of the string, while with <code>-ffreestanding</code>, it will always call <a class="el" href="group__avr__string.html#g7fd4936b86eb6b87e98587044c562715" title="Calculate the length of a string.">strlen()</a> at run-time. <p>
|
|
<ul>
|
|
<li><code>-funsigned-char</code> </li></ul>
|
|
<p>
|
|
Make any unqualfied <code>char</code> type an unsigned char. Without this option, they default to a signed char. <p>
|
|
<ul>
|
|
<li><code>-funsigned-bitfields</code> </li></ul>
|
|
<p>
|
|
Make any unqualified bitfield type unsigned. By default, they are signed. <p>
|
|
<ul>
|
|
<li><code>-fshort-enums</code> </li></ul>
|
|
<p>
|
|
Allocate to an <code>enum</code> type only as many bytes as it needs for the declared range of possible values. Specifically, the enum type will be equivalent to the smallest integer type which has enough room. <p>
|
|
<ul>
|
|
<li><code>-fpack-struct</code> </li></ul>
|
|
<p>
|
|
Pack all structure members together without holes. <h2><a class="anchor" name="using_avr_as">
|
|
Options for the assembler avr-as</a></h2>
|
|
<h3><a class="anchor" name="using_avr_as_mach_opts">
|
|
Machine-specific assembler options</a></h3>
|
|
<ul>
|
|
<li><code>-mmcu=</code><em>architecture</em></li><li><code>-mmcu=</code><em>MCU name</em> </li></ul>
|
|
<p>
|
|
avr-as understands the same <code>-mmcu=</code> options as <a class="el" href="using_tools.html#using_avr_gcc">avr-gcc</a>. By default, avr2 is assumed, but this can be altered by using the appropriate <code></code>.arch pseudo-instruction inside the assembler source file. <p>
|
|
<ul>
|
|
<li><code>-mall-opcodes</code> </li></ul>
|
|
<p>
|
|
Turns off opcode checking for the actual MCU type, and allows any possible AVR opcode to be assembled. <p>
|
|
<ul>
|
|
<li><code>-mno-skip-bug</code> </li></ul>
|
|
<p>
|
|
Don't emit a warning when trying to skip a 2-word instruction with a <code>CPSE/SBIC/SBIS/SBRC/SBRS</code> instruction. Early AVR devices suffered from a hardware bug where these instructions could not be properly skipped. <p>
|
|
<ul>
|
|
<li><code>-mno-wrap</code> </li></ul>
|
|
<p>
|
|
For <code>RJMP/RCALL</code> instructions, don't allow the target address to wrap around for devices that have more than 8 KB of memory. <p>
|
|
<ul>
|
|
<li><code>--gstabs</code> </li></ul>
|
|
<p>
|
|
Generate <code></code>.stabs debugging symbols for assembler source lines. This enables avr-gdb to trace through assembler source files. This option <em>must not</em> be used when assembling sources that have been generated by the C compiler; these files already contain the appropriate line number information from the C source files. <p>
|
|
<ul>
|
|
<li><code>-a[cdhlmns=</code><em>file</em><code>]</code> </li></ul>
|
|
<p>
|
|
Turn on the assembler listing. The sub-options are: <p>
|
|
<ul>
|
|
<li>
|
|
<code>c</code> omit false conditionals </li>
|
|
<li>
|
|
<code>d</code> omit debugging directives </li>
|
|
<li>
|
|
<code>h</code> include high-level source </li>
|
|
<li>
|
|
<code>l</code> include assembly </li>
|
|
<li>
|
|
<code>m</code> include macro expansions </li>
|
|
<li>
|
|
<code>n</code> omit forms processing </li>
|
|
<li>
|
|
<code>s</code> include symbols </li>
|
|
<li>
|
|
<code>=</code><em>file</em> set the name of the listing file </li>
|
|
</ul>
|
|
<p>
|
|
The various sub-options can be combined into a single <code>-a</code> option list; <em>=file</em> must be the last one in that case. <h3><a class="anchor" name="using_avr_example">
|
|
Examples for assembler options passed through the C compiler</a></h3>
|
|
Remember that assembler options can be passed from the C compiler frontend using <code>-Wa</code> (see <a class="el" href="using_tools.html#gcc_minusW">above</a>), so in order to include the C source code into the assembler listing in file <code>foo.lst</code>, when compiling <code>foo.c</code>, the following compiler command-line can be used:<p>
|
|
<div class="fragment"><pre class="fragment">
|
|
$ avr-gcc -c -O foo.c -o foo.o -Wa,-ahls=foo.lst
|
|
</pre></div><p>
|
|
In order to pass an assembler file through the C preprocessor first, and have the assembler generate line number debugging information for it, the following command can be used:<p>
|
|
<div class="fragment"><pre class="fragment">
|
|
$ avr-gcc -c -x assembler-with-cpp -o foo.o foo.S -Wa,--gstabs
|
|
</pre></div><p>
|
|
Note that on Unix systems that have case-distinguishing file systems, specifying a file name with the suffix <code></code>.S (upper-case letter S) will make the compiler automatically assume <code>-x assembler-with-cpp</code>, while using <code></code>.s would pass the file directly to the assembler (no preprocessing done).<h2><a class="anchor" name="using_avr_ld">
|
|
Controlling the linker avr-ld</a></h2>
|
|
<h3><a class="anchor" name="using_sel_ld_opts">
|
|
Selected linker options</a></h3>
|
|
While there are no machine-specific options for avr-ld, a number of the standard options might be of interest to AVR users.<p>
|
|
<ul>
|
|
<li><code>-l</code><em>name</em> </li></ul>
|
|
<p>
|
|
Locate the archive library named <code>lib</code><em>name</em><code>.a</code>, and use it to resolve currently unresolved symbols from it. The library is searched along a path that consists of builtin pathname entries that have been specified at compile time (e. g. <code>/usr/local/avr/lib</code> on Unix systems), possibly extended by pathname entries as specified by <code>-L</code> options (that must precede the <code>-l</code> options on the command-line). <p>
|
|
<ul>
|
|
<li><code>-L</code><em>path</em> </li></ul>
|
|
<p>
|
|
Additional location to look for archive libraries requested by <code>-l</code> options. <p>
|
|
<ul>
|
|
<li><code>--defsym </code><em>symbol=expr</em> </li></ul>
|
|
<p>
|
|
Define a global symbol <em>symbol</em> using <em>expr</em> as the value. <p>
|
|
<ul>
|
|
<li><code>-M</code> </li></ul>
|
|
<p>
|
|
Print a linker map to <code>stdout</code>. <p>
|
|
<ul>
|
|
<li><code>-Map </code><em>mapfile</em> </li></ul>
|
|
<p>
|
|
Print a linker map to <em>mapfile</em>. <p>
|
|
<ul>
|
|
<li><code>--cref</code> </li></ul>
|
|
<p>
|
|
Output a cross reference table to the map file (in case <code>-Map</code> is also present), or to <code>stdout</code>. <p>
|
|
<ul>
|
|
<li><code>--section-start </code><em>sectionname=org</em> </li></ul>
|
|
<p>
|
|
Start section <em>sectionname</em> at absolute address <em>org</em>. <p>
|
|
<ul>
|
|
<li><code>-Tbss </code><em>org</em></li><li><code>-Tdata </code><em>org</em></li><li><code>-Ttext </code><em>org</em> </li></ul>
|
|
<p>
|
|
Start the <code>bss</code>, <code>data</code>, or <code>text</code> section at <em>org</em>, respectively. <p>
|
|
<ul>
|
|
<li><code>-T </code><em>scriptfile</em> </li></ul>
|
|
<p>
|
|
Use <em>scriptfile</em> as the linker script, replacing the default linker script. Default linker scripts are stored in a system-specific location (e. g. under <code>/usr/local/avr/lib/ldscripts</code> on Unix systems), and consist of the AVR architecture name (avr2 through avr5) with the suffix <code></code>.x appended. They describe how the various <a class="el" href="mem_sections.html">memory sections</a> will be linked together. <h3><a class="anchor" name="using_pass_ld_opts">
|
|
Passing linker options from the C compiler</a></h3>
|
|
By default, all unknown non-option arguments on the avr-gcc command-line (i. e., all filename arguments that don't have a suffix that is handled by avr-gcc) are passed straight to the linker. Thus, all files ending in <code></code>.o (object files) and <code></code>.a (object libraries) are provided to the linker.<p>
|
|
System libraries are usually not passed by their explicit filename but rather using the <code>-l</code> option which uses an abbreviated form of the archive filename (see above). avr-libc ships two system libraries, <code>libc.a</code>, and <code>libm.a</code>. While the standard library <code>libc.a</code> will always be searched for unresolved references when the linker is started using the C compiler frontend (i. e., there's always at least one implied <code>-lc</code> option), the mathematics library <code>libm.a</code> needs to be explicitly requested using <code>-lm</code>. See also the <a class="el" href="FAQ.html#faq_libm">entry in the FAQ</a> explaining this.<p>
|
|
Conventionally, Makefiles use the <code>make</code> macro <code>LDLIBS</code> to keep track of <code>-l</code> (and possibly <code>-L</code>) options that should only be appended to the C compiler command-line when linking the final binary. In contrast, the macro <code>LDFLAGS</code> is used to store other command-line options to the C compiler that should be passed as options during the linking stage. The difference is that options are placed early on the command-line, while libraries are put at the end since they are to be used to resolve global symbols that are still unresolved at this point.<p>
|
|
Specific linker flags can be passed from the C compiler command-line using the <code>-Wl</code> compiler option, see <a class="el" href="using_tools.html#gcc_minusW">above</a>. This option requires that there be no spaces in the appended linker option, while some of the linker options above (like <code>-Map</code> or <code>--defsym</code>) would require a space. In these situations, the space can be replaced by an equal sign as well. For example, the following command-line can be used to compile <code>foo.c</code> into an executable, and also produce a link map that contains a cross-reference list in the file <code>foo.map:</code> <p>
|
|
<div class="fragment"><pre class="fragment">
|
|
$ avr-gcc -O -o foo.out -Wl,-Map=foo.map -Wl,--cref foo.c
|
|
</pre></div><p>
|
|
Alternatively, a comma as a placeholder will be replaced by a space before passing the option to the linker. So for a device with external SRAM, the following command-line would cause the linker to place the data segment at address 0x2000 in the SRAM:<p>
|
|
<div class="fragment"><pre class="fragment">
|
|
$ avr-gcc -mmcu=atmega128 -o foo.out -Wl,-Tdata,0x802000
|
|
</pre></div><p>
|
|
See the explanation of the <a class="el" href="mem_sections.html#sec_dot_data">data section</a> for why 0x800000 needs to be added to the actual value. Note that the stack will still remain in internal RAM, through the symbol <code>__stack</code> that is provided by the run-time startup code. This is probably a good idea anyway (since internal RAM access is faster), and even required for some early devices that had hardware bugs preventing them from using a stack in external RAM. Note also that the heap for <code><a class="el" href="group__avr__stdlib.html#g4996af830ebe744d9678e5251dfd3ebd">malloc()</a></code> will still be placed after all the variables in the data section, so in this situation, no stack/heap collision can occur.<p>
|
|
In order to relocate the stack from its default location at the top of interns RAM, the value of the symbol <code>__stack</code> can be changed on the linker command-line. As the linker is typically called from the compiler frontend, this can be achieved using a compiler option like<p>
|
|
<div class="fragment"><pre class="fragment">-Wl,--defsym=__stack=0x8003ff
|
|
</pre></div><p>
|
|
The above will make the code use stack space from RAM address 0x3ff downwards. The amount of stack space available then depends on the bottom address of internal RAM for a particular device. It is the responsibility of the application to ensure the stack does not grow out of bounds, as well as to arrange for the stack to not collide with variable allocations made by the compiler (sections .data and .bss). </div>
|
|
|
|
<hr width="80%">
|
|
<p><center>Automatically generated by Doxygen 1.5.6 on 4 Dec 2008.</center></p>
|
|
|
|
</body>
|
|
</html>
|