|
|
|
|
| Atmel AVR microcontrollers |
| Installation Instructions for the GNU Toolchain for AVR Microcontrollers |
| Very Outdated GNU Toolchain for AVR Microcontrollers |
This is an outdated (but working!) distribution of the gnutools for avr microcontrollers. I don't find the time to compile the latest versions of the tools. But have a try compiling them for yourself. Here is what Marek Michalkiewicz (maintainer of the glibc for avr microcontrollers) wrote me on the topic:
> [...]
You really need the latest and greatest CVS source tree of gcc and
binutils. These old patches for gcc-2.95.2 are no longer supported.
Snapshots might work, though I don't test them (I always use CVS -
that's where all the development happens).
> [...]
> is avr-libc-20000730 the latest verison of libc? is
> http://www1.itnet.pl/amelektr/avr/libc/ the place to get it?
No patches are necessary anymore, AVR support has been in the official
CVS for a few months now. I'm releasing avr-libc-20001118 right now :).
Yes, this is the place to get the latest libc.
> [...] are there major drawbacks using older versions of avr-libc?
You don't get the latest avr-gcc improvements (support for the enhanced
core, many optimizations and some bug fixes too). We really need more
people testing the CVS version (soon to become GCC 3.0), so that as many
bugs as possible are found before the release.
[...]
Marek
Download the avr-gnutools-olli-0.2.tgz tarball (7,957,538 bytes).
In the older distribution avr-gnutools-olli-0.1.tgz (7,401,551 bytes), the GNU CC driver program tried to include a library libgcc-mega when linking the (elf) binary. Apparently that library was some relic from long ago and no longer exists. If you have already downloaded the avr-gnutools-olli-0.1 dirtibution, you need not download the complete updated distribution. Instead you can do one of the following: Either provide your own Makefile rule to link binaries using libgcc instead of libgcc-mega. Or change the second occurrence of "-lgcc-mega" in /usr/local/avr-gnutools/lib/gcc-lib/avr/2.95.2/specs to "-lgcc".
The versions of the tools you will find in the distribution
tarball are:
binutils version 2.10.1. This version supports the AVR platform
straight away (configure with "--target=avr"). Download the
original sources at
http://sources.redhat.com/binutils/ or one of its
mirrors.
gcc is gcc-core-2.95.2 with the patch
gcc-core-2.95.2-avr-patch-1.1 applied. Original souces of gcc
can be found on
http://gcc.gnu.org/ or one of its mirrors.
glibc version avr-libc-20000514. Original sources are found
at
http://www1.itnet.pl/amelektr/avr/libc/.
uisp version uisp-20001014. Original sources are found
at
http://www1.itnet.pl/amelektr/avr/uisp/.
You will probably need to be root on your machine. Untar the
tarball in /usr/local, i.e. type
cd /usr/local tar xvfz avr-gnutools-olli-[DIST_VERSION].tgz After untaring the tarball you will have a new directory
avr-gnutools. Add
/usr/local/avr-gnutools/bin to your environment
variable PATH, e.g if you use bash as
your shell do: export
PATH=$PATH:/usr/local/avr-gnutools/bin.
Hardware-wise you will probably need a starterkit, such as the stk200 or stk300 to download your apps to the device. If you have such a kit, connect the cable to the parallel port of the Linux machine and stuff it into the programming interface on the development board end.
make upload. The app starts as soon as the
upload is complete. For details on how to make an AVR binary
refer to the Makefile.
| Memory Organization |
In principle, memory in a microcontroller environment is organized the same way as is in UNIX. However, there are some differences in program generation (i.e. compilation), transfer to the system, and exectution. First letīs look at the memory layout of a UNIX process: The address space of a (UNIX-)process has four logical memory segments: text, data, stack and heap.
These segments end up in different locations in memory: In a PC environment the text and data segments are physically stored on disk and typically `mapped' into RAM at execution time. The heap and stack segments are created dynamically by the OS at program load-time or as part of dynamic linking.
In a microcontroller environment, text and data segments are
loaded into ROM (e.g. the FLASH ROM on the Atmel AVR) when the
mcu is programmed. Microcontrollers execute programs directly
from ROM. (Therefore there is no relocation step.) However,
since program data (such as variables) cannot reside in
read-only memory, the data segment needs to be copied to
RAM.
The start-up code takes care of coping the data segment to
RAM. It also sets up stack segment and performs other
initializations. The start-up code is the first code executed
when the mcu is switched on. The start-up code has to be linked
to the executable. Typically, the compiler takes care of that
automatically. (The start-up code is typically located in a file
called crt0.o. When linking an executable manually
(as opposed to letting a compiler do it automatically) it has to
be the first object on the command line.) Once the start-up code
has finished setting up the execution environment for the
program, it calls the main() function.
Microcontrollers have a Harvard architecture, i.e. they use separate buses for accessing program instructions (in ROM) and data (in RAM). To operate on strings, they need to be stored in RAM. Therefore strings are not located in the text segment but in the data segment.
Since there is typically no dynamic memory allocation in micorcontroller environments, there is no heap.
| Resources |
|