Version 91 (modified by C Rempel, on Feb 2, 2013 at 3:17:01 AM) (diff)

Adding the git instructions for avr-ada


{{Infobox BSP |BSP_name = AVRTest |Manufacturer = Atmel Corporation |image = |caption = optional image caption |Board_URL = |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) |Video = }}


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. }}= 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? ==

Because gnat has a special tool (to be run on the host, as opposed to the target) distributed with it called gnatmake, it is necessary to also build a "native" (most likely host) experimental version of gnatmake.

~/gcc-testing/build$ ../combined/configure --prefix=~/gcc-testing/install --enable-languages=c,ada --disable-multilib make bootstrap && make install

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: stub.

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 Avr-Ada

~/gcc-testing/avr-ada-code$ ./configure

Manually make the subdirectories of AVR-Ada...

Sending the Result to GCC

Finally, the whole reason for using the experimental branch of gcc! Sending the test results to keep the AVR-GCC port active!

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 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. It appears that the AVR-LibC community uses tools provided by ATMEL.== Building the Toolchain ==

Although the toolchain is provided in precompiled form, registration is required, so insert how to use the shell script here. Atmel Toolchain 3.4.1 Download

# Make the necessary modifications to build AVR-LibC from the AVR-LibC SVN instead of the distribution # 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 update NSIS installer to include up-to-date AVR-RTEMS-Ada support.

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 # : 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