Path: Home => english => Assembler intro => tools

Tools for AVR assembly programing

This page provides informations about the necessary tools that are used to program AVRs with the STK200 board. Programming with the STK500 is very different and shown in more detail in the Studio section.
The older software for the STK200 is not supported any more. Four programs are necessary for this. These tools are:

the editor,
the assembler program,
the chip programing interface, and
the simulator.

The necessary software tools are ©ATMEL and available on the webpage of ATMEL for download. The screenshots here are © ATMEL. It should be mentioned that there are different versions of the software and some of the screenshots are subject to change with the used version. Some windows or menues look different in different versions. The basic functions are mainly unchanged. Refer to the programer's handbook, this page just provides an overview for the beginner's first steps and is not written for the assembly programing expert.

To the top of this page

The editor

Assembler programs are written with a editor. The editor just has to be able to create and edit ASCII text files. So, basically, any simple editor does it. I recommend the use of a more advanced editor, either WAVRASM©ATMEL or the editor written by Tan Silliksaar (screenshot see below).

An assembly program written with WAVRASM© goes like this. Just install WAVRASM© and start the program:

Now we type in our directives and assembly commands in the WAVRASM editor window, together with some comments (starting with ;). That should look like this:

Now store the program text, named to something.asm into a dedicated directory, using the file menue. The assembly program is complete now.

If you like editing a little more in a sophisticated manner you can use the excellent editor written by Tan Silliksaar. This editor tools is designed for AVRs and available for free from Tan's webpage. In this editor our program looks like this:

The editor recognizes commands automatically and uses different colors (syntax highlighting) to signal user constants and typing errors in those commands (in black). Storing the code in an .asm file provides nearly the same text file.

To the top of this page

The assembler

Now we have to translate this code to a machine-oriented form well understood by the AVR chip. Doing this is called assembling, which means collecting the right command words. If you use WAVRASM© just click assemble on the menue. The result is shown here:

The assembler reports the complete translation with no errors. If errors occur these are notified. Assembling resulted in one word of code which resulted from the command we used. Assembling our single asm-text file now has produced four other files (not all apply here).

The first of these four new files, TEST.EEP, holds the content that should be written to the EEPROM of the AVR. This is not very interesting in our case, because we didn't program any content for the EEPROM. The assembler has therefore deleted this file when he completed the assembly run.
The second file, TEST.HEX, is more relevant because this file holds the commands later programmed into the AVR chip. This file looks like this:

The hex numbers are are written in a special ASCII form, together with adress informations and a checksum for each line. This form is called Intel-hex-format, and it is very old. The form is well understood by the programing software.

The third file, TEST.OBJ, will be introduced later, this file is needed to simulate an AVR. Its format is hexadecimal and defined by ATMEL. Using a hex-editor its content looks like this:

Attention: This file format is not compatible with the programer software, don't use this file to program the AVR (a very common error when starting).

The fourth file, TEST.LST, is a text file. Display its content with a simple editor. The following results:

The program with all its adresses, comands and error messages are displayed in a readable form. You will need that file in some cases to debug errors.

To the top of this page

Programming the chips

To program our hex code to the AVR ATMEL has written the ISP software package. We start the ISP software and load the hex file that we just generated (applying menue item LOAD PROGRAM). That looks like this:

Applying menue item PROGRAM will burn our code in the chip's program store. There are a number of preconditions necessary for this step (the correct parallel port has to be selected, the programming adapter must be connected, the chip must be on board the adapter, the power supply must be on, etc.).
ATMEL has recently removed the reliable and fast ISP-Software from its webpage. Besides the ATMEL-ISP and the programming boards other programming boards or adapters could be used, together with the appropriate programming software. Some of these alternatives are available on the internet.

To the top of this page

Simulation in the studio

In some cases self-written assembly code, even assembled without errors, does not exactly do what it should do when burned into the chip. Testing the software on the chip could be complicated, esp. if you have a minimum hardware and no opportunity to display interim results or debugging signals. In these cases the studio from ATMEL provides ideal opportunities for debugging. Testing the software or parts of it is possible, the program could be tested step-by-step displaying results.

The studio is started and looks like this:

First we open a file (menue item FILE OPEN). We demonstrate this using the tutorial file test1.asm, because there are some more commands and action that in our single-command program above. Open the file TEST1.OBJ that results by assembling TEST1.asm. You are asked which options you like to use (if not, you can change these using the menue item SIMULATOR OPTIONS). The following options will be selected:

In the device selection section we select the desired chip type. The correct frequency should be selected if you like to simulate correct timings.

In order to view the content of some registers and what the processor's status is we select VIEW PROCESSOR and REGISTERS. The display should now look like this:

The processor window displays all values like the command counter, the flags and the timing information (here: 1 MHz clock). The stop watch can be used to measure the necessary time for going through routines etc.

Now we start the program execution. We use the single step opportunity (TRACE INTO or F11). Using GO would result in continous exection and not much would be seen due to the high speed of simulation. After the first executed step the processor window should look like this:

The program counter is at step 1, the cycle counter at 2 (RJMP needed two cycles). At 1 MHz clock two microseconds have been wasted, the flags and pointer registers are not changed. The source text window displays a pointer on the next command that will be executed.

Pressing F11 again executes the next command, register mp (=R16) will be set to 0xFF. Now the register window should highlite this change:

Register R16's new value is displayed in red letters. We can change the value of a register at any time to test what happens then.

Now step 3 is executed, output to the direction register of Port B. To display this we open a new I/O view window and select Port B. The display should look like this:

The Data Direction Register in the I/O-view window of Port B now shows the new value. The values could be changed manually, if desired, pin by pin.

The next two steps are simulated using F11. They are not displayed here. Setting the output ports to one with the command LDI mp,0xFF and OUT PORTB,mp results in the following picture in the I/O view:

Now the output port bits are all one, the I/O view shows this.

That is our short trip through the simulator software world. The simulator is capable to much more, so it should be applied extensively in cases of design errors. Visit the different menue items, there is much more than showed here.

To the top of this page

©2002 by http://www.avr-asm-tutorial.net