BSP Infobox

BSP_name AVRTest
Manufacturer Atmel Corporation
image -
caption optional image caption
Architecture Atmel AVR
CPU_model ATmega128
Monitor NONE
Simulator Simulavr
NVMEM ATmega64x - 64kb flash ATmega32x - 32kb
Serial standard ICSP pinouts (10-pin or 6-pin connector)


AVRTest is a test suite which is part of the Simulavr simulator. The version of avr-libc being used on RTEMS is: 1.6.8

Describe the board here. Include links to manuals, brochures, etc.

Board Setup

If there are special jumper or ROM monitor settings, describe them.

Downloading and Executing

Describe the download procedure.


How do you debug code on this board? What gdb setup? BDM, stub, etc?

Test Reports

{{Test Report |Version = CVS head |Date = DATE |User = User:WhoTestedThis? |Report = reports that something happened. }}


Status: Challenged. The unpatched gcc-4.8 --target=avr-rtems4.11 does not build on Ubuntu 12.10. However, the gcc-4.8 --target=avr does, and is being explored.

Updating Status: In (slow) progress. ETA: 3-5 months. On April 5th, avr-ada made some changes to their source code, so these directions will have to be updated. As RTEMS is gearing up for Continuous Integration (CI), and GSoC students are gaining interest in other projects CR was dabbling in, this port is getting higher on the priority list.

Rationale: All targets we claim work, should be made to be in working order.

Outstanding Issues: Ubuntu does not have a gnat-4.7 package (gnat-4.7 must already be installed to install, and so the package maintainer became frustrated). Manually installing one has not really been figured out all the way (because of the circular dependency on itself). Not sure how to test "hello, world!" in Ada on AVR-Test.

Work-arounds: For gnat-4.7, use gcc-snapshot. Late February, a String application was added giving hope for a "Hello, World!".

Everything below is out-dated, and probably doesn't work: Caveat Emptor!= Porting Notes =

Once this process is figured out, it looks like AVR-Ada tools/build/ might be a good script to add a .diff to, as it automatically downloads, patches, and builds a toolset.

(If we update) probably will have four long-term users: # GCC development community: want gnu-toolset development svn/cvs instructions (for correcting problems before release) # AVR-Libc development community: want latest Atmel toolset version and svn/cvs version of AVR-Libc instructions # AVR-RTEMS developers: want latest (or not so latest) release tar ball instructions (for tailoring configurations) # End Users: want packages (for developing Real-time AVR-Ada applications) <!-- Looks like AVR gcc could be compiled using --with-avrlibc option, and no need to worry about patching gcc, yeah! -->


The purpose of this version of the port is to find bugs in upcoming versions of gcc, (as opposed to producing software for customers, or developing for RTEMS directly). The GCC development community wants each architecture, to include AVR, to submit test results to gcc-testresults@… every 4 months, so running the AVR gcc-testing is a must for a well-maintained port. The time it took to run WinAVR's AVRTest with a simulator was ~1 hour, so running gcc testing on this port appears feasible from a time standpoint.

Downloading the Source

~/gcc-testing$ git clone git:// avr-ada-code

TODO: # Time GCC-Testing Takes: on a 2010 x86_64 laptop it takes ~5 hours to build native gnat, install, and test the SVN/CVS version of the toolset. # Identify a way to only build WinAVR/AVTTest targets (as opposed to ALL AVR targets, when building gcc-testing)== Installing Experimental Version of GnatMake? ==

Some Linux distributions, such as Fedora, package the testing/experimental version of gnat like any other version of gnat, while others do not, such as Ubuntu/Debian?. Although initially I built Gnatmake from source, a simpler approach is to install the experimental version of gcc for your distribution.== = Installing on Debian ===

sudo apt-get install gcc-snapshot # gnatmake ships with gcc-snapshot

To use on Debian/Ubuntu? please remember to use

export PATH=/usr/lib/gcc-snapshot/bin/:$PATH

Patching the GCC Testing Toolchain for AVR-RTEMS

Note: stub. There are several patch sets that need to be applied to make this toolset work... two of which are: the avr-ada patches, and the RTEMS patches. I'll start with discussing how to apply the avr-ada patches...

The AVR-Ada patches are not designed to work on the testing branch, and so will need to be manually upstreamed... my current attempt will be to only patch GCC, as opposed to binutils... (hopefully, most of the necessary binutils patches can be upstreamed over time... :)

To manually upstream AVR-Ada patches, use the combined/gcc/ada directory, (so re-checking out the sources won't be necessary if anything goes wrong)...

~$ cd ~/gcc-testing/combined/gcc/ada

Carefully, apply each of the

~/gcc-testing/combined/gcc/ada$ cat ../../../avr-ada-code/patches/gcc/4.7.2/73-gcc-4.7-ada-gnat1_print_path.patch | patch -p1 --dry-run

The shell will prompt for the correct file

can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: --------------------------

gcc/ada/gnat1drv.adb.orig 2011-12-21 14:34:12.000000000 +0100

|+++ gcc/ada/gnat1drv.adb 2012-01-22 12:42:07.015625000 +0100 -------------------------- File to patch: gnat1drv.adb patching file gnat1drv.adb Hunk #1 succeeded at 833 (offset 56 lines).

If the patch succeeded run

~$ cat ../../../avr-ada-code/patches/gcc/4.7.2/73-gcc-4.7-ada-gnat1_print_path.patch | patch -p1

Otherwise, manually open both files and search for where the patch should go...

To manually upstream RTEMS patches, use the combined directory, (so re-checking out the sources won't be necessary if anything goes wrong)...

~$ cd ~/gcc-testing/combined

Apply the GCC patches... on 20 January 2013 it appears the RTEMS binutils patches have already been applied to the source tree...

~/gcc-testing/combined$ cat ../gcc-4.7.2-rtems4.11-20121026.diff | patch -p1 --dry-run ~/gcc-testing/combined$ cat ../gcc-4.7.2-rtems4.11-20121026.diff | patch -p1

Hopefully, we can use AVR-LibC instead of Newlib for the AVR-RTEMS port...

Apply the GDB patches

~/gcc-testing/combined$ cat ../gdb-7.5.1-rtems4.11-20121130.diff | patch -p1 --dry-run ~/gcc-testing/combined$ cat ../gdb-7.5.1-rtems4.11-20121130.diff | patch -p1

Building the GCC Testing Toolchain for AVR-RTEMS

Note: This complicated procedure should probably be reworked into using a modified and enhanced version of, so the gcc-test is simpler to reproduce.

This configuration worked for the experimental branch of the GCC 4.8.0 toolset on 14 January 2013 was:

~/gcc-testing/build-avr-gcc$ ../combined/configure \ --target=avr \ --program-prefix=avr- \ --disable-shared \ --disable-nls \ --disable-libssp \ --with-system-zlib \ --disable-libada \ --enable-languages=ada,c,c++ \ --enable-cpp \ --with-dwarf2 \ --enable-version-specific-runtime-libs \ --disable-sim \ --prefix=/home/joel/gcc-testing/install

To build without errors, use the gcc-testing version of the native gcc, and make the source code.

~/gcc-testing/build-avr-gcc$ export PATH=~/gcc-testing/install/bin:$PATH:~/gcc-testing/install/bin ~/gcc-testing/build-avr-gcc$ make && make install

One of the simulators for this build is AVR-Test, but it may be worth exploring simulAVR in the future.

Building AVR-LibC Using GCC-Testing Toolchain

Check-out the testing branch of AVR-LibC

~/gcc-testing$ svn co svn:// avr-libc ~/gcc-testing$ cd avr-libc ~/gcc-testing/avr-libc$ mv avr-libc/* .

Build AVR-LibC testing branch.

The AVR-LibC testing branch requires a call to bootstrap to build the configure script.

cd ~/gcc-testing/avr-libc ~/gcc-testing/avr-libc$ ./bootstrap

Running configure: # --prefix : the place to install the gcc-testing version of AVR-Libc # --build : the machine used to build AVR-Libc # --host : this is the target, interestingly many open-source projects are now using the word "host" to determine if it's cross-compiled # CFLAGS='-mmcu=atmega128' : only build the atmega128 targets

~/gcc-testing/avr-libc$ ./configure \

--prefix=/home/stanr/Desktop/gcc-testing/install \ --build=./config.guess \ --host=avr \ CFLAGS='-mmcu=atmega128'

Making AVR-LibC # Tell bash to use the testing version of avr-gcc # Tell make to keep building past errors

~/gcc-testing/avr-libc$ export PATH=~/gcc-testing/install/bin/:$PATH:~/gcc-testing/install/bin/ ~/gcc-testing/avr-libc$ make && make install

Building AVRTest (Simulator) using GCC Testing Toolchain

Loosely based on an email sent on 12 September 2009 directions were posted for how to build the AVR-Test simulator for gcc-testing, but adding a baseboard instead of just using one baseboard.

~/gcc-testing$ svn co ~/gcc-testing$ cd avrtest ~/gcc-testing/avrtest$ make clean-exit all AVRGCC=~/gcc-testing/install/bin/avr-gcc ~/gcc-testing/avrtest$ sudo cp dejagnuboards/atmega128-sim.exp /usr/share/dejagnu/baseboards/.

for additional directions on AVR-Test see: Next, customize the /usr/share/dejagnu/baseboards/atmega128-sim.exp

set_board_info cflags " -DSIGNAL_SUPPRESS -mmcu=atmega128 -I/home/georg/gnu/install/gcc-4.7/avr/include" ... set_board_info ldflags "/home/georg/source/avrtest/exit-atmega128.o -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=heap_end=0x80ffff ..

Change back to the build directory and run gcc-tests, the Ada tests will fail until AVR-Ada is installed, so pass the --keep-going (-k) flag to make

~/gcc-testing/avrtest$ cd ~/gcc-testing/build-avr-gcc ~/gcc-testing/build-avr-gcc$ make -k check RUNTESTFLAGS="--target_board=atmega128-sim" avr.exp > test.log

The AVR-GCC tester will probably want to open a second terminal to build avr-gnat while avr-gcc is being tested...

Building AVR-Gnat using GCC Testing Toolchain

Note: stub. Tell bash to use the testing version of avr-gcc

~/gcc-testing/avr-ada-code$ export PATH=~/gcc-testing/install/bin/:$PATH:~/gcc-testing/install/bin/

Update the rts to the most recent version

~/gcc-testing/avr-ada-code$ cp -r gcc-4.7-rts/ gcc-4.8-rts ~/gcc-testing/avr-ada-code$ ... insert code to replace 4.7 with 4.8 in each file within gcc-4.8-rts

Configure and build Avr-Ada runtime system

~/gcc-testing/avr-ada-code$ ./configure ~/gcc-testing/avr-ada-code$ make build_rts ~/gcc-testing/avr-ada-code$ make install_rts ~/gcc-testing/avr-ada-code$ make build_libs ~/gcc-testing/avr-ada-code$ make install_libs

Making a Hello World Application

General Idea(s): # use the script found in avr-ada-code/tools/mk_ada_app (needs to be explained)

Sending the Result to GCC

Finally, the whole reason for using the experimental branch of gcc! Sending the AVR-GCC test results to gcc so the bugs will get fixed!

You can preview what you'll be sending by using the command

~/gcc-testing/build$ ../gcc/contrib/test_summary | more

Then, you can send the results one of two ways:

Method 1: Using Mailx and the command line:

srcdir/contrib/test_summary -p your_commentary.txt \

-m gcc-testresults@… |sh


Method 2: # Open your email # TO: gcc-testresults@… # Use as examples for the subject line # Attach test.log # Copy the configuration information for gcc # click send


Insert good reason to upstream patches here: for the good of the open-source community, to reduce the divergence of the AVR toolchain from the rest of the Gnu Toolchain, etc.

Next steps for this build would be:

  • to submit patches to the bugzilla at Sourceware to lower the learning curve for getting AVR-Ada up-and-running...
  • to enhance the build system for the AVR so it can be made with make instead of make -k, so compiler problems that are really problems can be identified

AVR-LibC/AVR-Ada Development Branch

Note: stub. The purpose of this distribution would be to ease the synchronization efforts of the AVR-RTEMS development community, the AVR-LibC development community (and possibly the AVR-Ada community), so in the longer term, end users of such systems would be able to have up-to-date versions of each that work well together.


  • add lines to ~/.bashrc to make the tools accessible for later use.
  • devise a patch for to: use the development branch of AVR-LibC, (optionally) install WinAVR, other tools, explictly state dependency on gprbuild, change host configuration file avr.cgpr to host/avr_host.gpr

It appears that the AVR-LibC community uses tools provided by ATMEL. While AVR-Ada uses a different toolchain.== Building the AVR-Ada Toolchain ==

Although both toolchains are provided in precompiled form, RTEMS provides patches for the source code of the toolchains, so it is important to be able to patch each tool set and build from the RTEMS patched source.== = Getting Gnat-4.7 on Fedora ===

If using Fedora install gnat-4.7 in the standard way.== = Getting Gnat 4.7 on Ubuntu ===

If using Ubuntu, because Gnat-4.7 was not packaged for Ubuntu-12.10 is was necessary to use gcc-snapshot_20111010 to get gnat-4.7 (please note gcc-snapshot is for bug-reporting only --NOT packagable binaries!). Then export the gcc-snapshot binries to the PATH.

export PATH=$PATH:/usr/lib/gcc-snapshot/bin/

Please note: next time you run the update-manager, it will try to update gcc-snapshot. If you plan to rebuild AVR-Ada, uncheck the gcc-snapshot box before you update, or you will install gnat-4.8, which will not build avr-ada-1.2.1...

= Using the AVR-Ada Build Script =

Avr-Ada ships with a build script, which downloads and builds the AVR-Ada toolchain. Start by making a directory for the toolchain.

~/$ mkdir AVR_ADA && cd AVR_ADA # make a directory for building the AVR Ada toolset

Then download and extract the AVR-Ada package

~/AVR_ADA$ wget\ Dist/avr-ada-1.2.1.tar.bz2 # get the source ~/AVR_ADA$ tar -xf avr-ada-1.2.1.tar.bz2

Make a working copy of the build script in the directory,

~/AVR_ADA$ cp avr-ada-1.2.1/tools/build/ .

Set download_files=yes to have the script download the source code, set build_avrada=yes to build Ada support for the AVR

~/AVR_ADA$ sed 's/download_files="no"/download_files="yes"/' -i ~/AVR_ADA$ sed 's/build_avrada="no"/build_avrada="yes"/' -i

Installing the toolchain in user space reduces the number of errors caused by permissions problems. To change the install directory to user space do

~/AVR_ADA$ sed s/
/AVR-ADA/ -i

It appears, on Ubuntu at least, that it's necessary to make a slight modification to get AVR-Ada to build. The change is to change which configuration file gprbuild uses for configuration. Because the changes are necessary for each build I added a line to


+ sed s/config\=avr\.cgpr/config\=avr
/avr\_host\.gpr/ -i avr/avr_lib/Makefile

display "configure AVR-Ada ... (log in $AVR_BUILD/step12_avrada_conf.log)"

Note: need to add code to get to remove threading support in avr-ada-code/avr/avr_lib/Makefile and remove call to gprbuild in avr-ada-code/avr/Makefile

  • To run the code ~/AVR_ADA$ bash

= Simulator Demo =

First export the new toolset to the PATH

~/AVR_ADA/avr_472_gnat/share/doc/avr-libc-1.8.0/examples/demo$ export PATH=~/AVR_ADA/avr_472_gnat/bin/:$PATH

Edit the Makefile to use the ATMega128

# Make the necessary modifications to build AVR-LibC from the AVR-LibC SVN instead of AVR-Ada # Simulator Demo # Sending test results to AVR-LibC

Gnat / AVR-Ada

# Add building the SVN version of AVR-Gnat # Simulator Demo # Sending test results to AVR-Ada


# Add building RTEMS # Simulator Demo # Sending test results to RTEMS

End Users

How to use package builders, such as: Mock and pbuilder to make packages. For Windows, probably package for MSYS to include up-to-date AVR-RTEMS-Ada support. Another idea would be the rtems-source-builder

Include how to submit packages...

Limited Resources

Limited memory could be an issue


# : Theoretical / hypothetical customer requirements / goals of AVR-RTEMS port # : avr-libc subset of Standard-C Library # : possible use-case? # RTEMSAda : How to build RTEMS with Ada support # : How to add a package to AVR-Ada # : up-to-date patches for avr toolchain # : avr gcc-testresults configuration # : simulator file for gcc-testresults # : how to set up the avr simulator # : how to meet Ada on AVR requirement # : Build script for AVR toolset, potentially useful starting point to think about writing an RTEMS AVR toolset script # : Installing the toolset # : Using SimulAVR # : Recommendation to use AVRTest if only running gcc-testing # : Tutorial written in German, describes how to get the tools to work together to run SimulAVR # TinyRTEMS : Description of RTEMS for 8/16-bit micro-controllers, as well as compiler/linker flags and BSP support info # : patches for tinyRTEMS (8-bit RTEMS) # : how-to-package for Debian

Last modified on Nov 8, 2018 at 12:02:17 AM Last modified on Nov 8, 2018, 12:02:17 AM