Choose a programming language for the AVR

At first I wanted to start programming for AVR with the native gcc compiler. But I could not find it on the net. Which is no surprise since it is not available as such. It is part of the (AVR) binutils. And you need to compile this package to be able to extract the C compiler from it.
That was too difficult to me. So I looked a bit further and started to get ashamed... Such a small processor and then reverting to such a big language. So I determined assembler would be just for me. After all, I have been using 80x86 assembler as my main programming language until 1997. So why not go back to a good habit and revive my knowledge of assembler, through this tiny CPU.

Available languages

Apart from assembler, there are C, C++ and Ada compilers for the AVR. Possibly Pascal as well, but I'm not sure. There IS a Pascal compiler, for TOS and at a price!
Still, why settle with less than a gcc compiler for AVR if it is available. And it is. You just cannot find it in a tgz file, somewhere on the web. Which is no wonder, since it is part of the binutils for AVR. You need to compile these binutils for AVR and then you end up with the gcc C compiler. Then you need to have the libc libraries and when programming you nee to know which to '#include'.

This is all very difficult for me. I don't want to bring down a stable running system. I don't mind doing compilations with 'make' or directly with 'gcc'. But I was reluctant to possibly damage the binutils tree which keeps my Pentium system active.
And, if you are familiar with my C++ Crusade, you must be aware that C is not my language of choice. To put it mildly. So C is a bad Choice for me. Better look for something else then.

Assemblers: gavrasm and tavrasm

I am a follower of the penguin. I don't want to use software written for TOS (The Other System). So the official AVR assembler was ruled out. After some websearching for tutorials and examples, I found gavrasm and tavrasm. Both are 'avr asm' programs. The former was written by Gewrd and the latter by Tom. Which explains the first letters of both assemblers.
Both tavrasm and gavrasm closely follow the syntax and possibillities of the official AVR assembler. Both have their own peculiarities. The gavrasm is still actively supported and the maker has a bilingual tutorial in AVR ASM programming. Also, gavrasm is written in FreePascal and it comes with full sources. So a port to Mocka may be a future project. If time permits.
So I chose for gavrasm. It came in a precompiled form. The assembler has everything inside. So no need for seperate DEFinition files to declare constants like registernames and portnumbers. This can be a drawback with new chips, but I prefer to call it an advantage.

A bit of a disappointment

The gavrasm is a superset of the official AVR assembler. I am working myself through the manual for the Windows version (there is no other) by Atmel. I haven't read it all yet, but being spoiled by programming languages like Modula-2, this assembler is a bit of a disappointment.
When I compare the AVR assembler to my Speedware TASMB assembler (for the 8086 CPU) I must confess that TASMB was more modern than the AVR (which is 20 years younger). I particularly dislike that I, the programmer, have to specify the TYPE of the statement which is coming up. Two examples:

	.EQU	cr	= 13
	.DEF	count	= R15
   
You might wonder: What's so disturbing about this? In that case, you probably have never programmed a language with strong typing. What we have to do here is:

Text Purpose
.EQU Hello assembler, this line contains the assignment of a constant to a label
cr the new symbol name is defined
= assignment operator
13 the expression yielding the constant to be assigned to the label

The assemblers that I grew up with would write the EQU line as follows:

		cr	EQU 13
   
and that's it. The assembler (which originally was written to make MY life, as a programmer, easier) scans the line, finds the 'EQU' and then 'knows' that the preceding name was a label and the following text must lead to a constant number or string. Here is an example of how TASMB expected the input files:
name	"cond"

escp	equ	27
bel	equ	7
stopper	equ	0FFh

	mov	si, offset lptdata

again	mov	ah, 5
	mov	dl, [si]
	cmp	dl, stopper
	jz	exit

	int	21h
	inc	si
	jmp	again

exit	mov	ah, 4Ch
	xor	al, al
	int	21h

lptdata:

	db	escp, 'B', 03h, escp, 'R', 05h, escp, 'N', 04h
	db	escp, 'M', 08h, bel

	db	escp, 'D', 08h, 10h, 18h, 20h, 28h, 30h, 38h, 40h
	db	 48h, 50h, 58h, 60h, 68h, 70h, 78h, 80h, 0, bel

	db	stopper
   
Now, that is a whole other source. You just write down what you think the program needs to know. And the rest is for the assembler. In EVERY assembler, the structure of a line is as follows:
  1. label or nothing
  2. instruction or pseudo operation
  3. operands (if any)
  4. a comment, preceeded by a semicolon, if any
So why should I, the programmer, bother for a special fifth element, telling the assembler to expect an upcoming constant declaration. OK, it's all not such a big deal, but it violates the rule that the assembler is here to help ME and not vice versa.

Here is another source, this time written with the superior A86 assembler:

name     LoadDisk2

  DATA segment

buffer   db    512 dup (?)

         EVEN
handle   dw    ?

  CODE segment

         jmp   main

filename db    'Bootsex.sav', 0

main:    mov   ah, 0
         mov   dl, 00
         int   013              ; reset diskdrives
         
         mov   dx, 0000
         mov   cx, 0001
         mov   bx, offset buffer
         mov   ax, 02 BY 1
         int   013              ; fetch sectors

         mov   dx, offset filename
         mov   cx, 0
         mov   ah, 03C
         int   021              ; create file

         mov   [handle], ax

         mov   dx, offset buffer
         mov   cx, 512
         mov   bx, [handle]
         mov   ah, 040
         int   021              ; fill file

         mov   bx, [handle]
         mov   ah, 03E
         int   021              ; close file

         mov   ax, 04C00
         int   021
   
This is source for a mature assembler. No silly kindergarten style dot commands. The dot command is there to make life easy on the MAKER of the assembler and puts the burden in the hand of the USER of the assembler. In most cases, that is the person who just paid a considerabe amount of money for an apparently immature piece of software.
Back to the A86 source. After the declaration of the name, it starts with the 'DATA segment'. In it, 512 bytes are claimed, but not filled since this is RAM so you will have to fill it anyway. At the end, one word is defined as well. Then the real source starts after the words 'CODE segment'.
This is my kind of assembler. A86 did a real good job for DOS (and probably Windows). Pitty it isn't available for Linux or other processors.

Page created on 24 April 2007 and

Page equipped with FroogleBuster technology