Programming techniques in AVR Assembler language

Assembler-Directives

Assembler-Directives control the assembler, they don't create any own code. The leading dot must be in column 1 of the line.

Segment	Directive	Description
Header	.DEVICE	Defines the type of the target processor and the applicable set of instructions (illegal instructions for that type trigger an error message, syntax: .DEVICE AT90S8515)
	.DEF	Defines a synonym for a register (e.g. .DEF MyReg = R16)
	.EQU	Defines a symbol and sets its value (later changes of this value remain possible, syntax: .EQU test = 1234567, internal storage of the value is 4-byte- Integer)
	.SET	Fixes the value of a symbole (later redefinition is not possible)
	.INCLUDE	Includes a file and assembles its content, just like its content would be part of the calling file (typical e.g. including the header file: .INCLUDE "C:\avrtools\appnotes\8515def.inc")
Code	.CSEG	Start of the code segment (all that follows is assembled to the code segment and will go to the program space)
	.DB	Inserts one or more constant bytes in the code segment (could be numbers from 0..255, an ASCII-character like 'c', a string like 'abcde' or a combination like 1,2,3,'abc'. The number of inserted bytes must be even, otherwise an additional zero byte will be inserted by the assembler.)
	.DW	Insert a binary word in the code segment (e.g. produces a table within the code)
	.LISTMAC	Macros will be listed in the .LST-file. (Default is that macros are not listed)
	.MACRO	Beginning of a macro (no code will be produced, call of the macro later produces code, syntax: .MACRO macroname parameters, calling by: macroname parameters)
	.ENDMACRO	End of the macro
EEPROM	.ESEG	Assemble to the EEPROM-segment (the code produced will go to the EEPROM section, the code produces an .EEP-file)
	.DB	Inserts one or more constant bytes in the EEPROM segment (could be numbers from 0..255, an ASCII-character like 'c', a string like 'abcde' or a combination like 1,2,3,'abc'.)
	.DW	Inserts a binary word to the EEPROM segment (the lower byte goes to the next adress, the higher byte follows on the incremented address)
SRAM	.DSEG	Assemble to the data segment (here only BYTE directives and labels are valid, during assembly only the labels are used)
SRAM	.BYTE	Reserves one or more bytes space in the data segment (only used to produce correct labels, does not insert any values!)
Everywhere	.ORG	Defines the address within the respective segment, where the assembler assembles to (e.g. .ORG 0x0000)
	.LIST	Switches the listing to the .LST-file on (the assembled code will be listet in a readable text file .LST)
	.NOLIST	Switches the output to the .LST-file off, suppresses listing.
	.INCLUDE	Inserts the content of another source code file, as if its content would be part of the source file (typical e.g. including the header file: .INCLUDE "C:\avrtools\appnotes\8515def.inc")
	.EXIT	End of the assembler-source code (stops the assembling process)

Advanced Assembler Directives

Advanced Assembler Directives allow

conditional assembly: a code sequence is translated only if a certain condition is met or not, otherwise another code sequence is generated,
output of messages or forced error conditions: these allow signalisation of certain conditions during assembly or force exiting the assembly process on a certain condition.

Please note again, that these directives are only meaningful for the assembler and during the assembly process, the assembled program itself, as loaded into the AVR, does not have any conditions!

The Syntax of these directives look like this:

.IF <Condition>, then code lines, then .ENDIF. Condition is an expression which is either true or false, e.g. a comparision like a<b, a>b or a==b.
.IF <Condition>, then code lines, then .ELSE, then code lines, then .ENDIF. If the condition is met (true), then the first series of code lines is translated, if not the second code sequence behind ELSE is translated.
.IF <Condition 1>, then code lines, then .ELIF <Condition 2>, then code lines, then .ENDIF. If condition 1 is true, the first code sequence is generated, if not the condition 2 will be checked. If this is true, then the second code sequence is generated. If neither condition 1 nor condition 2 are true, no code will be generated.
.IFDEF <Symbol>. Checks if a symbol has been defined. If so, the code is translated and inserted. If not, the following code sequence is not translated. Can be combined with the ELSE and ELIF directive, and must be finished by a ENDIF directive.
.IFNDEF <Symbol>. Produces the opposite: if the symbol is not defined, the code is translated.
.MESSAGE "<text>". Outputs the message text during assembling. Can be used in combination with conditional assembly to signal the result of the comparision or output any other comments.
.ERROR "<text>". Outputs the message text and causes an error condition. Can be used to skip further assembling, if a certain value exceeds a certain limit or is too small.

Assembler expressions

Expressions are needed to calculate within the assembler source code. These expressions are calculated during the assembly process, they don't produce any execuatble code.

Type	Symbol	Description
Calculation	+	Addition
	-	Subtraction or negative number
	*	Multiplication
	/	Integer-Division
Binary	&	Bitwise AND
	\|	Bitwise OR
	^	Bitwise Exclusive-OR
	~	Bitwise NOT
	<<	Shift left
	>>	Shift right
Logical	<	Less than
	>	Greater than
	==	Equal
	<=	Less or equal
	>=	Graeter or equal
	!=	Unequal
	&&	AND
	\|\|	OR
	!	NOT

Shift left

Some hints for Shift-Left (<<): the following code lines are used very often:

  ldi r16,1<<ADSC
  out ADCSRA,r16

In this example, ADSC is a certain bit in Port ADCSRA, both defined somewhere in the header file for this AVR. In that case it starts an AD conversion (in most cases bit 6), if written to the Port ADCSRA. The expression with << causes that a One (binary 0000.0001) is shifted left six times and gets to 0100.0000. This number is written to the port ADCSRA and causes an AD conversion start.

Using this notation has the advantage, that the exact location of the ADSC bit in the ADCSRA port doesn't have to be known exactly. Its location can even change from one header file to another, without changing the source code. Compared to the formulation

  ldi r16,0b01000000
  out 0x06,r16

the transparency is much higher. And not having to count binary zeroes is another advantage.

What if other bits in the same port have to be set to one simultanously, for example the Interrupt Enable bit ADIE (bit 3)? Then just OR these bitwise:

  ldi r16,(1<<ADSC) | (1<<ADIE)
  out ADCSRA,r16

The brackets set the exact calculation priorities.