\hypertarget{porting_iar_porting_intro}{}\doxysubsection{Introduction}\label{porting_iar_porting_intro}
C language was designed to be a portable language. There two main types of porting activities\+: porting an application to a different platform (OS and/or processor), and porting to a different compiler. Porting to a different compiler can be exacerbated when the application is an embedded system. For example, the C language Standard, strangely, does not specify a standard for declaring and defining Interrupt Service Routines (I\+S\+Rs). Different compilers have different ways of defining registers, some of which use non-\/standard language constructs.

This chapter describes some methods and pointers on porting an A\+VR application built with the I\+AR compiler to the G\+NU toolchain (A\+VR G\+CC). Note that this may not be an exhaustive list.\hypertarget{porting_iar_porting_register}{}\doxysubsection{Registers}\label{porting_iar_porting_register}
IO header files contain identifiers for all the register names and bit names for a particular processor. I\+AR has individual header files for each processor and they must be included when registers are being used in the code. For example\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{preprocessor}{\#include <iom169.h>} }
\end{DoxyCode}


\begin{DoxyNote}{Note}
I\+AR does not always use the same register names or bit names that are used in the A\+VR datasheet.
\end{DoxyNote}
A\+VR G\+CC also has individual IO header files for each processor. However, the actual processor type is specified as a command line flag to the compiler. (Using the {\ttfamily -\/mmcu={\itshape processor}} flag.) This is usually done in the Makefile. This allows you to specify only a single header file for any processor type\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{preprocessor}{\#include <\mbox{\hyperlink{io_8h}{avr/io.h}}>} }
\end{DoxyCode}


\begin{DoxyNote}{Note}
The forward slash in the $<$\mbox{\hyperlink{io_8h}{avr/io.\+h}}$>$ file name that is used to separate subdirectories can be used on Windows distributions of the toolchain and is the recommended method of including this file.
\end{DoxyNote}
The compiler knows the processor type and through the single header file above, it can pull in and include the correct individual IO header file. This has the advantage that you only have to specify one generic header file, and you can easily port your application to another processor type without having to change every file to include the new IO header file.

The A\+VR toolchain tries to adhere to the exact names of the registers and names of the bits found in the A\+VR datasheet. There may be some descrepencies between the register names found in the I\+AR IO header files and the A\+VR G\+CC IO header files.\hypertarget{porting_iar_porting_isr}{}\doxysubsection{Interrupt Service Routines (\+I\+S\+Rs)}\label{porting_iar_porting_isr}
As mentioned above, the C language Standard, strangely, does not specify a standard way of declaring and defining an I\+SR. Hence, every compiler seems to have their own special way of doing so.

I\+AR declares an I\+SR like so\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{preprocessor}{\#pragma vector=TIMER0\_OVF\_vect}}
\DoxyCodeLine{\_\_interrupt \textcolor{keywordtype}{void} MotorPWMBottom()}
\DoxyCodeLine{\{}
\DoxyCodeLine{    \textcolor{comment}{// code}}
\DoxyCodeLine{\}}
\end{DoxyCode}


In A\+VR G\+CC, you declare an I\+SR like so\+: 
\begin{DoxyCode}{0}
\DoxyCodeLine{\mbox{\hyperlink{group__avr__interrupts_gad28590624d422cdf30d626e0a506255f}{ISR}}(PCINT1\_vect)}
\DoxyCodeLine{\{ }
\DoxyCodeLine{    \textcolor{comment}{//code}}
\DoxyCodeLine{\}}
\end{DoxyCode}


A\+VR G\+CC uses the {\ttfamily I\+SR} macro to define an I\+SR. This macro requries the header file\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{preprocessor}{\#include <\mbox{\hyperlink{interrupt_8h}{avr/interrupt.h}}>}}
\end{DoxyCode}


The names of the various interrupt vectors are found in the individual processor IO header files that you must include with {\ttfamily $<$\mbox{\hyperlink{io_8h}{avr/io.\+h}}$>$}.

\begin{DoxyNote}{Note}
The names of the interrupt vectors in A\+VR G\+CC has been changed to match the names of the vectors in I\+AR. This significantly helps in porting applications from I\+AR to A\+VR G\+CC.
\end{DoxyNote}
\hypertarget{porting_iar_porting_intrinsic}{}\doxysubsection{Intrinsic Routines}\label{porting_iar_porting_intrinsic}
I\+AR has a number of intrinsic routine such as

{\ttfamily \+\_\+\+\_\+enable\+\_\+interrupts()} {\ttfamily \+\_\+\+\_\+disable\+\_\+interrupts()} {\ttfamily \+\_\+\+\_\+watchdog\+\_\+reset()} 

These intrinsic functions compile to specific A\+VR opcodes (S\+EI, C\+LI, W\+DR).

There are equivalent macros that are used in A\+VR G\+CC, however they are not located in a single include file.

A\+VR G\+CC has {\ttfamily \mbox{\hyperlink{group__avr__interrupts_gaad5ebd34cb344c26ac87594f79b06b73}{sei()}}} for {\ttfamily \+\_\+\+\_\+enable\+\_\+interrupts()}, and {\ttfamily \mbox{\hyperlink{group__avr__interrupts_ga68c330e94fe121eba993e5a5973c3162}{cli()}}} for {\ttfamily \+\_\+\+\_\+disable\+\_\+interrupts()}. Both of these macros are located in {\ttfamily $<$\mbox{\hyperlink{interrupt_8h}{avr/interrupt.\+h}}$>$}.

A\+VR G\+CC has the macro {\ttfamily \mbox{\hyperlink{group__avr__watchdog_ga9e52c54d10b6a6a7ce04aaaa4abea51f}{wdt\+\_\+reset()}}} in place of {\ttfamily \+\_\+\+\_\+watchdog\+\_\+reset()}. However, there is a whole Watchdog Timer A\+PI available in A\+VR G\+CC that can be found in {\ttfamily $<$\mbox{\hyperlink{wdt_8h}{avr/wdt.\+h}}$>$}.\hypertarget{porting_iar_porting_flash}{}\doxysubsection{Flash Variables}\label{porting_iar_porting_flash}
The C language was not designed for Harvard architecture processors with separate memory spaces. This means that there are various non-\/standard ways to define a variable whose data resides in the Program Memory (Flash).

I\+AR uses a non-\/standard keyword to declare a variable in Program Memory\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\_\_flash \textcolor{keywordtype}{int} mydata[] = .... }
\end{DoxyCode}


A\+VR G\+CC uses Variable Attributes to achieve the same effect\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{keywordtype}{int} mydata[] \mbox{\hyperlink{power_8h_a577a0eebac2a6c2d105e61d9c8f04140}{\_\_attribute\_\_}}((progmem)) }
\end{DoxyCode}


\begin{DoxyNote}{Note}
See the G\+CC User Manual for more information about Variable Attributes.
\end{DoxyNote}
avr-\/libc provides a convenience macro for the Variable Attribute\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{preprocessor}{\#include <\mbox{\hyperlink{pgmspace_8h}{avr/pgmspace.h}}>}}
\DoxyCodeLine{.}
\DoxyCodeLine{.}
\DoxyCodeLine{.}
\DoxyCodeLine{int mydata[] \mbox{\hyperlink{group__avr__pgmspace_ga75acaba9e781937468d0911423bc0c35}{PROGMEM}} = ....}
\end{DoxyCode}


\begin{DoxyNote}{Note}
The P\+R\+O\+G\+M\+EM macro expands to the Variable Attribute of {\ttfamily progmem}. This macro requires that you include {\ttfamily $<$\mbox{\hyperlink{pgmspace_8h}{avr/pgmspace.\+h}}$>$}. This is the canonical method for defining a variable in Program Space.
\end{DoxyNote}
To read back flash data, use the {\ttfamily pgm\+\_\+read\+\_\+$\ast$}() macros defined in {\ttfamily $<$\mbox{\hyperlink{pgmspace_8h}{avr/pgmspace.\+h}}$>$}. All Program Memory handling macros are defined there.

There is also a way to create a method to define variables in Program Memory that is common between the two compilers (I\+AR and A\+VR G\+CC). Create a header file that has these definitions\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{preprocessor}{\#if defined(\_\_ICCAVR\_\_) // IAR C Compiler}}
\DoxyCodeLine{\textcolor{preprocessor}{\#define FLASH\_DECLARE(x) \_\_flash x}}
\DoxyCodeLine{\textcolor{preprocessor}{\#endif}}
\DoxyCodeLine{\textcolor{preprocessor}{\#if defined(\_\_GNUC\_\_) // GNU Compiler}}
\DoxyCodeLine{\textcolor{preprocessor}{\#define FLASH\_DECLARE(x) x \_\_attribute\_\_((\_\_progmem\_\_))}}
\DoxyCodeLine{\textcolor{preprocessor}{\#endif }}
\end{DoxyCode}


This code snippet checks for the I\+AR compiler or for the G\+CC compiler and defines a macro {\ttfamily F\+L\+A\+S\+H\+\_\+\+D\+E\+C\+L\+A\+R\+E(x)} that will declare a variable in Program Memory using the appropriate method based on the compiler that is being used. Then you would used it like so\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{FLASH\_DECLARE(\textcolor{keywordtype}{int} mydata[] = ...); }
\end{DoxyCode}
\hypertarget{porting_iar_porting_non_returning_main}{}\doxysubsection{Non-\/\+Returning main()}\label{porting_iar_porting_non_returning_main}
To declare main() to be a non-\/returning function in I\+AR, it is done like this\+: 
\begin{DoxyCode}{0}
\DoxyCodeLine{\_\_C\_task \textcolor{keywordtype}{void} main(\textcolor{keywordtype}{void})}
\DoxyCodeLine{\{}
\DoxyCodeLine{    \textcolor{comment}{// code}}
\DoxyCodeLine{\}}
\end{DoxyCode}


To do the equivalent in A\+VR G\+CC, do this\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{keywordtype}{void} main(\textcolor{keywordtype}{void}) \mbox{\hyperlink{power_8h_a577a0eebac2a6c2d105e61d9c8f04140}{\_\_attribute\_\_}}((noreturn));}
\DoxyCodeLine{    }
\DoxyCodeLine{\textcolor{keywordtype}{void} main(\textcolor{keywordtype}{void})}
\DoxyCodeLine{\{}
\DoxyCodeLine{    \textcolor{comment}{//...}}
\DoxyCodeLine{\}}
\end{DoxyCode}


\begin{DoxyNote}{Note}
See the G\+CC User Manual for more information on Function Attributes.
\end{DoxyNote}
In A\+VR G\+CC, a prototype for main() is required so you can declare the function attribute to specify that the main() function is of type \char`\"{}noreturn\char`\"{}. Then, define main() as normal. Note that the return type for main() is now {\ttfamily void}.\hypertarget{porting_iar_porting_locking}{}\doxysubsection{Locking Registers}\label{porting_iar_porting_locking}
The I\+AR compiler allows a user to lock general registers from r15 and down by using compiler options and this keyword syntax\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\_\_regvar \_\_no\_init \textcolor{keyword}{volatile} \textcolor{keywordtype}{unsigned} \textcolor{keywordtype}{int} filteredTimeSinceCommutation @14;}
\end{DoxyCode}


This line locks r14 for use only when explicitly referenced in your code thorugh the var name \char`\"{}filtered\+Time\+Since\+Commutation\char`\"{}. This means that the compiler cannot dispose of it at its own will.

To do this in A\+VR G\+CC, do this\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{\textcolor{keyword}{register} \textcolor{keywordtype}{unsigned} \textcolor{keywordtype}{char} counter \textcolor{keyword}{asm}(\textcolor{stringliteral}{"r3"});}
\end{DoxyCode}


Typically, it should be possible to use r2 through r15 that way.

\begin{DoxyNote}{Note}
Do not reserve r0 or r1 as these are used internally by the compiler for a temporary register and for a zero value.

Locking registers is not recommended in A\+VR G\+CC as it removes this register from the control of the compiler, which may make code generation worse. Use at your own risk. 
\end{DoxyNote}
