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 = R15You 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 13and 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 stopperNow, 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:
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.
Page created on 24 April 2007 and
Page equipped with GoogleBuster technology