Avr gnu toolchain linux

Introduction

Welcome to the open source software development toolset for the Atmel AVR!

There is not a single tool that provides everything needed to develop software for the AVR. It takes many tools working together. Collectively, the group of tools are called a toolset, or commonly a toolchain, as the tools are chained together to produce the final executable application for the AVR microcontroller.

The following sections provide an overview of all of these tools. You may be used to cross-compilers that provide everything with a GUI front-end, and not know what goes on «underneath the hood». You may be coming from a desktop or server computer background and not used to embedded systems. Or you may be just learning about the most common software development toolchain available on Unix and Linux systems. Hopefully the following overview will be helpful in putting everything in perspective.

FSF and GNU

According to its website, «the Free Software Foundation (FSF), established in 1985, is dedicated to promoting computer users’ rights to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free software, particularly the GNU operating system, used widely in its GNU/Linux variant.» The FSF remains the primary sponsor of the GNU project.

The GNU Project was launched in 1984 to develop a complete Unix-like operating system which is free software: the GNU system. GNU is a recursive acronym for В»GNU’s Not UnixВ«; it is pronounced guh-noo, approximately like canoe.

One of the main projects of the GNU system is the GNU Compiler Collection, or GCC, and its sister project, GNU Binutils. These two open source projects provide a foundation for a software development toolchain. Note that these projects were designed to originally run on Unix-like systems.

GCC stands for GNU Compiler Collection. GCC is highly flexible compiler system. It has different compiler front-ends for different languages. It has many back-ends that generate assembly code for many different processors and host operating systems. All share a common «middle-end», containing the generic parts of the compiler, including a lot of optimizations.

In GCC, a host system is the system (processor/OS) that the compiler runs on. A target system is the system that the compiler compiles code for. And, a build system is the system that the compiler is built (from source code) on. If a compiler has the same system for host and for target, it is known as a native compiler. If a compiler has different systems for host and target, it is known as a cross-compiler. (And if all three, build, host, and target systems are different, it is known as a Canadian cross compiler, but we won’t discuss that here.) When GCC is built to execute on a host system such as FreeBSD, Linux, or Windows, and it is built to generate code for the AVR microcontroller target, then it is a cross compiler, and this version of GCC is commonly known as «AVR GCC». In documentation, or discussion, AVR GCC is used when referring to GCC targeting specifically the AVR, or something that is AVR specific about GCC. The term «GCC» is usually used to refer to something generic about GCC, or about GCC as a whole.

GCC is different from most other compilers. GCC focuses on translating a high-level language to the target assembly only. AVR GCC has three available compilers for the AVR: C language, C++, and Ada. The compiler itself does not assemble or link the final code.

GCC is also known as a «driver» program, in that it knows about, and drives other programs seamlessly to create the final output. The assembler, and the linker are part of another open source project called GNU Binutils. GCC knows how to drive the GNU assembler (gas) to assemble the output of the compiler. GCC knows how to drive the GNU linker (ld) to link all of the object modules into a final executable.

The two projects, GCC and Binutils, are very much interrelated and many of the same volunteers work on both open source projects.

When GCC is built for the AVR target, the actual program names are prefixed with «avr-«. So the actual executable name for AVR GCC is: avr-gcc. The name «avr-gcc» is used in documentation and discussion when referring to the program itself and not just the whole AVR GCC system.

See the GCC Web Site and GCC User Manual for more information about GCC.

GNU Binutils

The name GNU Binutils stands for «Binary Utilities». It contains the GNU assembler (gas), and the GNU linker (ld), but also contains many other utilities that work with binary files that are created as part of the software development toolchain.

Again, when these tools are built for the AVR target, the actual program names are prefixed with «avr-«. For example, the assembler program name, for a native assembler is «as» (even though in documentation the GNU assembler is commonly referred to as «gas»). But when built for an AVR target, it becomes «avr-as». Below is a list of the programs that are included in Binutils:

avr-as The Assembler. avr-ld The Linker. avr-ar Create, modify, and extract from libraries (archives). avr-ranlib Generate index to library (archive) contents. avr-objcopy Copy and translate object files to different formats. avr-objdump Display information from object files including disassembly. avr-size List section sizes and total size. avr-nm List symbols from object files. avr-strings List printable strings from files. avr-strip Discard symbols from files. avr-readelf Display the contents of ELF format files. avr-addr2line Convert addresses to file and line. avr-c++filt Filter to demangle encoded C++ symbols.

avr-libc

GCC and Binutils provides a lot of the tools to develop software, but there is one critical component that they do not provide: a Standard C Library.

There are different open source projects that provide a Standard C Library depending upon your system time, whether for a native compiler (GNU Libc), for some other embedded system (newlib), or for some versions of Linux (uCLibc). The open source AVR toolchain has its own Standard C Library project: avr-libc.

AVR-Libc provides many of the same functions found in a regular Standard C Library and many additional library functions that is specific to an AVR. Some of the Standard C Library functions that are commonly used on a PC environment have limitations or additional issues that a user needs to be aware of when used on an embedded system.

AVR-Libc also contains the most documentation about the whole AVR toolchain.

Building Software

Even though GCC, Binutils, and avr-libc are the core projects that are used to build software for the AVR, there is another piece of software that ties it all together: Make. GNU Make is a program that makes things, and mainly software. Make interprets and executes a Makefile that is written for a project. A Makefile contains dependency rules, showing which output files are dependent upon which input files, and instructions on how to build output files from input files.

Some distributions of the toolchains, and other AVR tools such as MFile, contain a Makefile template written for the AVR toolchain and AVR applications that you can copy and modify for your application.

See the GNU Make User Manual for more information.

AVRDUDE

After creating your software, you’ll want to program your device. You can do this by using the program AVRDUDE which can interface with various hardware devices to program your processor.

AVRDUDE is a very flexible package. All the information about AVR processors and various hardware programmers is stored in a text database. This database can be modified by any user to add new hardware or to add an AVR processor if it is not already listed.

GDB / Insight / DDD

The GNU Debugger (GDB) is a command-line debugger that can be used with the rest of the AVR toolchain. Insight is GDB plus a GUI written in Tcl/Tk. Both GDB and Insight are configured for the AVR and the main executables are prefixed with the target name: avr-gdb, and avr-insight. There is also a «text mode» GUI for GDB: avr-gdbtui. DDD (Data Display Debugger) is another popular GUI front end to GDB, available on Unix and Linux systems.

AVaRICE

AVaRICE is a back-end program to AVR GDB and interfaces to the Atmel JTAG In-Circuit Emulator (ICE), to provide emulation capabilities.

SimulAVR

SimulAVR is an AVR simulator used as a back-end with AVR GDB.

Utilities

There are also other optional utilities available that may be useful to add to your toolset.

SRecord is a collection of powerful tools for manipulating EPROM load files. It reads and writes numerous EPROM file formats, and can perform many different manipulations.

MFile is a simple Makefile generator is meant as an aid to quickly customize a Makefile to use for your AVR application.

Toolchain Distributions (Distros)

All of the various open source projects that comprise the entire toolchain are normally distributed as source code. It is left up to the user to build the tool application from its source code. This can be a very daunting task to any potential user of these tools.

Luckily there are people who help out in this area. Volunteers take the time to build the application from source code on particular host platforms and sometimes packaging the tools for convenient installation by the end user. These packages contain the binary executables of the tools, pre-made and ready to use. These packages are known as «distributions» of the AVR toolchain, or by a more shortened name, «distros».

AVR toolchain distros are available on FreeBSD, Windows, Mac OS X, and certain flavors of Linux.

Open Source

All of these tools, from the original source code in the multitude of projects, to the various distros, are put together by many, many volunteers. All of these projects could always use more help from other people who are willing to volunteer some of their time. There are many different ways to help, for people with varying skill levels, abilities, and available time.

You can help to answer questions in mailing lists such as the avr-gcc-list, or on forums at the AVR Freaks website. This helps many people new to the open source AVR tools.

If you think you found a bug in any of the tools, it is always a big help to submit a good bug report to the proper project. A good bug report always helps other volunteers to analyze the problem and to get it fixed for future versions of the software.

You can also help to fix bugs in various software projects, or to add desirable new features.

Источник

Building and Installing under Linux, FreeBSD, and Others

The default behaviour for most of these tools is to install every thing under the /usr/local directory. In order to keep the AVR tools separate from the base system, it is usually better to install everything into /usr/local/avr . If the /usr/local/avr directory does not exist, you should create it before trying to install anything. You will need root access to install there. If you don’t have root access to the system, you can alternatively install in your home directory, for example, in $HOME/local/avr . Where you install is a completely arbitrary decision, but should be consistent for all the tools.

You specify the installation directory by using the –prefix=dir option with the configure script. It is important to install all the AVR tools in the same directory or some of the tools will not work correctly. To ensure consistency and simplify the discussion, we will use $PREFIX to refer to whatever directory you wish to install in. You can set this as an environment variable if you wish as such (using a Bourne-like shell):

Note Be sure that you have your PATH environment variable set to search the directory you install everything in before you start installing anything. For example, if you use –prefix=$PREFIX , you must have $PREFIX/bin in your exported PATH . As such: Warning If you have CC set to anything other than avr-gcc in your environment, this will cause the configure script to fail. It is best to not have CC set at all. Note It is usually the best to use the latest released version of each of the tools.

Required Tools

Optional Tools

You can develop programs for AVR devices without the following tools. They may or may not be of use for you.

GNU Binutils for the AVR target

The binutils package provides all the low-level utilities needed in building and manipulating object files. Once installed, your environment will have an AVR assembler ( avr-as ), linker ( avr-ld ), and librarian ( avr-ar and avr-ranlib ). In addition, you get tools which extract data from object files ( avr-objcopy ), dissassemble object file information ( avr-objdump ), and strip information from object files ( avr-strip ). Before we can build the C compiler, these tools need to be in place.

Download and unpack the source files:

Note Replace with the version of the package you downloaded. If you obtained a gzip compressed file (.gz), use gunzip instead of bunzip2 .

It is usually a good idea to configure and build binutils in a subdirectory so as not to pollute the source with the compiled files. This is recommended by the binutils developers.

The next step is to configure and build the tools. This is done by supplying arguments to the configure script that enable the AVR-specific options.

If you don’t specify the –prefix option, the tools will get installed in the /usr/local hierarchy (i.e. the binaries will get installed in /usr/local/bin , the info pages get installed in /usr/local/info , etc.) Since these tools are changing frequently, It is preferrable to put them in a location that is easily removed.

When configure is run, it generates a lot of messages while it determines what is available on your operating system. When it finishes, it will have created several Makefile s that are custom tailored to your platform. At this point, you can build the project.

Note BSD users should note that the project’s Makefile uses GNU make syntax. This means FreeBSD users may need to build the tools by using gmake .

If the tools compiled cleanly, you’re ready to install them. If you specified a destination that isn’t owned by your account, you’ll need root access to install them. To install:

You should now have the programs from binutils installed into $PREFIX/bin . Don’t forget to set your PATH environment variable before going to build avr-gcc.

GCC for the AVR target

Warning You must install avr-binutils and make sure your path is set properly before installing avr-gcc.

The steps to build avr-gcc are essentially same as for binutils:

To save your self some download time, you can alternatively download only the gcc-core- .tar.bz2 and gcc-c++- .tar.bz2 parts of the gcc. Also, if you don’t need C++ support, you only need the core part and should only enable the C language support. (Starting with GCC 4.7 releases, these split files are no longer available though.)

Note Early versions of these tools did not support C++. The stdc++ libs are not included with C++ for AVR due to the size limitations of the devices.

AVR LibC

Warning You must install avr-binutils, avr-gcc and make sure your path is set properly before installing avr-libc. Note If you have obtained the latest avr-libc from cvs, you will have to run the bootstrap script before using either of the build methods described below.

To build and install avr-libc:

Optionally, generation of debug information can be requested with:

where DEBUG_INFO can be one of stabs , dwarf-2 , or dwarf-4 .

The default is to not generate any debug information, which is suitable for binary distributions of avr-libc, where the user does not have the source code installed the debug information would refer to.

AVRDUDE

Note It has been ported to windows (via MinGW or cygwin), Linux and Solaris. Other Unix systems should be trivial to port to.

avrdude is part of the FreeBSD ports system. To install it, simply do the following:

Note Installation into the default location usually requires root permissions. However, running the program only requires access permissions to the appropriate ppi(4) device.

Building and installing on other systems should use the configure system, as such:

GDB for the AVR target

GDB also uses the configure system, so to build and install:

Note If you are planning on using avr-gdb , you will probably want to install either simulavr or avarice since avr-gdb needs one of these to run as a a remote target backend.

SimulAVR

SimulAVR also uses the configure system, so to build and install:

Note You might want to have already installed avr-binutils, avr-gcc and avr-libc if you want to have the test programs built in the simulavr source.

AVaRICE

Note These install notes are not applicable to avarice-1.5 or older. You probably don’t want to use anything that old anyways since there have been many improvements and bug fixes since the 1.5 release.

AVaRICE also uses the configure system, so to build and install:

Note AVaRICE uses the BFD library for accessing various binary file formats. You may need to tell the configure script where to find the lib and headers for the link to work. This is usually done by invoking the configure script like this (Replace with the path to the bfd.h file on your system. Replace
with the path to libbfd.a on your system.):

Building and Installing under Windows

Building and installing the toolchain under Windows requires more effort because all of the tools required for building, and the programs themselves, are mainly designed for running under a POSIX environment such as Unix and Linux. Windows does not natively provide such an environment.

There are two projects available that provide such an environment, Cygwin and MinGW. There are advantages and disadvantages to both. Cygwin provides a very complete POSIX environment that allows one to build many Linux based tools from source with very little or no source modifications. However, POSIX functionality is provided in the form of a DLL that is linked to the application. This DLL has to be redistributed with your application and there are issues if the Cygwin DLL already exists on the installation system and different versions of the DLL. On the other hand, MinGW can compile code as native Win32 applications. However, this means that programs designed for Unix and Linux (i.e. that use POSIX functionality) will not compile as MinGW does not provide that POSIX layer for you. Therefore most programs that compile on both types of host systems, usually must provide some sort of abstraction layer to allow an application to be built cross-platform.

MinGW does provide somewhat of a POSIX environment, called MSYS, that allows you to build Unix and Linux applications as they woud normally do, with a configure step and a make step. Cygwin also provides such an environment. This means that building the AVR toolchain is very similar to how it is built in Linux, described above. The main differences are in what the PATH environment variable gets set to, pathname differences, and the tools that are required to build the projects under Windows. We’ll take a look at the tools next.

Tools Required for Building the Toolchain for Windows

These are the tools that are currently used to build an AVR tool chain. This list may change, either the version of the tools, or the tools themselves, as improvements are made.

• MinGW
  Download the MinGW Automated Installer, 20100909 (or later) http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/mingw-get-inst-20100909/mingw-get-inst-20100909.exe/download
  • Run mingw-get-inst-20100909.exe
  • In the installation wizard, keep the default values and press the «Next» button for all installer pages except for the pages explicitly listed below.

In the installer page «Repository Catalogues», select the «Download latest repository catalogues» radio button, and press the «Next» button

• In the installer page «License Agreement», select the «I accept the agreement» radio button, and press the «Next» button
• In the installer page «Select Components», be sure to select these items:
  • C compiler (default checked)
  • C++ compiler
  • Ada compiler
  • MinGW Developer Toolkit (which includes «MSYS Basic System»).
• Install.

• Install everything, all users, UNIX line endings. This will take a long time. A fat internet pipe is highly recommended. It is also recommended that you download all to a directory first, and then install from that directory to your machine.

Note GMP, MPFR, and MPC are required to build GCC. GMP is a prequisite for building MPFR. Build GMP first. MPFR is a prerequisite for building MPC. Build MPFR second.

• Build GMP for MinGW
  • Latest Version
  • http://gmplib.org/
  • Build script:
  • GMP headers will be installed under /usr/local/include and library installed under /usr/local/lib.
• Build MPFR for MinGW
  • Latest Version
  • http://www.mpfr.org/
  • Build script:
  • MPFR headers will be installed under /usr/local/include and library installed under /usr/local/lib.
• Build MPC for MinGW
  • Latest Version
  • http://www.multiprecision.org/
  • Build script:
  • MPFR headers will be installed under /usr/local/include and library installed under /usr/local/lib.

Note Doxygen is required to build AVR-LibC documentation.

• Install Doxygen
  • Version 1.7.2
  • http://www.stack.nl/

    dimitri/doxygen/

  • Download and install.

NetPBM is required to build graphics in the AVR-LibC documentation.

• Install NetPBM
  • Version 10.27.0
  • From the GNUWin32 project: http://gnuwin32.sourceforge.net/packages.html
  • Download and install.

fig2dev is required to build graphics in the AVR-LibC documentation.

• Install fig2dev
  • Version 3.2 patchlevel 5c
  • From WinFig 4.62: http://www.schmidt-web-berlin.de/winfig/
  • Download the zip file version of WinFig
  • Unzip the download file and install fig2dev.exe in a location of your choice, somewhere in the PATH.
  • You may have to unzip and install related DLL files for fig2dev. In the version above, you have to install QtCore4.dll and QtGui4.dll.

MikTeX is required to build various documentation.

• Install MiKTeX
  • Version 2.9
  • http://miktex.org/
  • Download and install.

Ghostscript is required to build various documentation.

• Install Ghostscript
  • Version 9.00
  • http://www.ghostscript.com
  • Download and install.
  • In the \bin subdirectory of the installaion, copy gswin32c.exe to gs.exe.
• Set the TEMP and TMP environment variables to c:\temp or to the short filename version. This helps to avoid NTVDM errors during building.

Building the Toolchain for Windows

All directories in the PATH enviornment variable should be specified using their short filename (8.3) version. This will also help to avoid NTVDM errors during building. These short filenames can be specific to each machine.

Build the tools below in MinGW/MSYS.

• Binutils
  • Open source code pacakge and patch as necessary.
  • Configure and build in a directory outside of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /usr/bin
    • /bin
    • /mingw/bin
    • c:/cygwin/bin
    • /bin
  • Configure
  • Make
  • Manually change documentation location.
• GCC
  • Open source code pacakge and patch as necessary.
  • Configure and build in a directory outside of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /usr/bin
    • /bin
    • /mingw/bin
    • c:/cygwin/bin
    • /bin
  • Configure
  • Make
• avr-libc
  • Open source code package.
  • Configure and build at the top of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /mingw/bin
    • /bin
    • /bin
    • c:/cygwin/bin
  • Configure
  • Make
  • Manually change location of man page documentation.
  • Move the examples to the top level of the install tree.
  • Convert line endings in examples to Windows line endings.
  • Convert line endings in header files to Windows line endings.
• AVRDUDE
  • Open source code package.
  • Configure and build at the top of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /usr/bin
    • /bin
    • /mingw/bin
    • c:/cygwin/bin
    • /bin
  • Set location of LibUSB headers and libraries
  • Configure
  • Make
  • Convert line endings in avrdude config file to Windows line endings.
  • Delete backup copy of avrdude config file in install directory if exists.
• Insight/GDB
  • Open source code pacakge and patch as necessary.
  • Configure and build in a directory outside of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /usr/bin
    • /bin
    • /mingw/bin
    • c:/cygwin/bin
    • /bin
  • Configure
  • Make
• SRecord
  • Open source code package.
  • Configure and build at the top of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /usr/bin
    • /bin
    • /mingw/bin
    • c:/cygwin/bin
    • /bin
  • Configure
  • Make

Build the tools below in Cygwin.

• AVaRICE
  • Open source code package.
  • Configure and build in a directory outside of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /usr/bin
    • /bin
    • /bin
  • Set location of LibUSB headers and libraries
  • Configure
  • Make
• SimulAVR
  • Open source code package.
  • Configure and build in a directory outside of the source code tree.
  • Set PATH, in order:
    • /usr/local/bin
    • /usr/bin
    • /bin
    • /bin
  • Configure
  • Make

Automatically generated by Doxygen 1.8.7 on Tue Aug 12 2014.

Источник