Path: Home =>
AVR-english =>
Beginner => Structure
Structure of AVR-assembler-programs
This page shows the basic structure of an assembler program. These structures are typical for
AT90Sxxxx assembler. This text discusses comments,
header informations, code at program start and the
general structure of programs.
The most helpful things in assembler programs are comments. If you need to understand
older code that you wrote, sometimes years after, you will be happy about having some or
more hints what is going on in that line. If you like to keep your ideas secret, and to
hide them aginst yourself and others: don't use comments.
A comment starts with a semicolon. All that follows behind on the same line will be ignored
by the compiler. If you need to write a comment over multiple lines, start each line with a
semicolon. So each assembler program should start like that:
;
; Click.asm, Program to switch a relais on and off each two seconds
; Written by G.Schmidt, last change: 7.10.2001
;
Put comments around all parts of the program, be it a complete subroutine or a table.
Within the comment mention the special nature of the routine, pre-conditions necessary to
call or run the routine. Also mention the results of the subroutine in case you later will
have to find errors or extend the routine later.
Single line comments are defined by adding a semicolon behind the command on the line. Like
this:
LDI R16,0x0A ; Here something is loaded
MOV R17,R16 ; and copied somewhere else
To the top of that page
Purpose and function of the program, the author, version information and other comments
on top of the program should be followed by the processor type that the program is written
for, and by relevant constants and by a list with the register names.
The processor type is especially important. Programs do not run on other chip types without
changes. The commands are not completely understood by all types, each type has typical
amounts of EEPROM and internal SRAM. All these special features are included in a header file
that is named xxxxdef.inc, with xxxx being the chip type, e.g. 2313, 2323, or 8515. These files
are available by ATMEL. It is good style to
include this file at the beginning of each program. This is done like that:
.NOLIST ; Don't list the following in the list file
.INCLUDE "C:\avrtools\appnotes\8515def.inc" ; Import of the file
.LIST ; Switch list on again
The path, where this file can be found, is only necessary if you didn't copy that file to
the folder where your assembler program is located. Of course you have to change this path to
fit to your place where these files are located.
During assembling listing of the results is switched on by default. This might result in very
long list files (*.lst) if you include the header file. NOLIST turns off this listing for a
while, LIST turns it on again.
Let's have a short look at the header file. First these files define the processor type:
.DEVICE AT90S8515 ; The target device type
This results in error messages, if you use code sequences that are not defined for this type of
processor. You don't need to define this within your program as this is already defined within
the header file.
The header file defines the registers XH, XL, YH, YL, ZH and ZL. These are needed if you use
the 16-bit-pointers X, Y or Z to access the higher or lower byte of the pointer separately.
The port's locations are also defined in the header file, so PORTB translates to hex 18.
The port's names are defined with the same names that are used in the data sheets for the
respective processor type. This also applies to single bits in the ports. Read access to port B,
bit 3, can be done using its bit name PINB3, as defined in the data sheet.
In other words: if you forget to include the header file you will run into a lot of error
messages during assembly. The resulting error messages are in many cases not very much related
to the missing header file. This is due to a serious bug (or is it a MS-style-feature?) in
ATMEL's assemblers: a missing label or constant
is not reported as such, but it is assumed to be zero. You can easily imagine that the resulting
code does strange things with your AVR in action.
Others things that should be on top of your programs are the register definitions you work with,
e.g.:
.DEF mpr = R16 ; Define a new name for register R16
This has the advantage of having a complete list of registers, and to see which registers are
still available and unused. Renaming registers avoids conflicts in the use of these registers
and the names are easier to remember.
Furtheron we define the constants on top of the source file, especially those that have a
relevant role in different parts of the program. Such a constant would, e.g., be the Xtal
frequency that the program is adjusted for, if you use the serial interface on board. With
.EQU fq = 4000000 ; XTal frequency definition
at the beginning of the source code you immediately see for which clock you wrote the program.
Very much easier than searching for this information within 1482 lines of source code.
To the top of that page
After you have done the header, the program code should start. At the beginning of the code the
reset- and interrupt-vectors (their function see in the JUMP
section) are placed. As these require relative jumps, we should place the respective interrupt
service routines right behind. There is some space left then for other subroutines, before we
place the main program.
The main program always starts with setting registers to default values, initialisation of the
stack pointer and of the hardware components used. The following code is specfic for the program.
To the top of that page
The described standardized structure is included in a
standard form for the 8515 that is also included in the source code section. Used it to start
with your own 8515 programs, or to create similiar forms for other types.
To the top of that page
©2002 by http://www.avr-asm-tutorial.net