Pfad: Home => AVR-deutsch => Programmiertechniken => Werkzeuge

Werkzeuge für die AVR-Assembler-Programmierung

In diesem Abschnitt werden die Werkzeuge vorgestellt, die zum Assembler-Programmieren mit dem STK200 nötig sind. Die Programmierung mit dem STK500 und dem Studio ist anders und hier genauer beschrieben.
Für die Programmierung mit dem STK200 werden vier Teilprogramme benötigt. Diese Teile werden von ATMEL nicht mehr supported. Im einzelnen handelt es sich um

den Editor,
den Assembler,
das Programmier-Interface, und
den Simulator.

Die nötigen Software-Werkzeuge gibt es bei auf der Webseite von ATMEL, die auch das Copyright für diese freie Software besitzen. Die dargestellten Fenster sind alle © ATMEL. Es wird darauf hingewiesen, dass es unterschiedliche Versionen der Software mit unterschiedlichem Aussehen und unterschiedlicher Bedienung gibt. Diese Darstellung ist kein Handbuch, sie soll lediglich mit einigen wenigen Möglichkeiten vertraut machen, die Anfängern helfen können, die ersten Schritte zu machen.

Zum Seitenanfang

Der Editor

Assemblerprogramme schreibt man mit einem Editor. Der braucht im Prinzip nicht mehr können als ASCII-Zeichen zu schreiben und zu speichern. Im Prinzip täte es ein sehr einfaches Schreibgerät. Wir empfehlen hier aber die etwas fortgeschrittenere Version eines solchen Schreibgerätes, entweder den WAVRASM von ATMEL oder den von Tan Silliksaar (siehe unten).

Der WAVRASM sieht nach der Installation und nach dem Start eines neuen Projektes etwa so aus:

Im WAVRASM schreiben wir einfach die Assemblerbefehle und Befehlszeilen drauf los, gespickt mit Kommentaren (,die alle mit einem Semikolon beginnen). Das sollte dann etwa so aussehen:

Nun wird das Assembler-Programm mit dem File-Menue in irgendein Verzeichnis, am besten in ein eigens dazu errichtetes, abgespeichert. Fertig ist das Assembler-Programm.

Wer es etwas schöner haben möchte, verwendet den Editor von Tan Silliksaar. Den gibt es auch kostenlos im Internet.

In diesem Editor sieht unser Programm so aus:

Der Editor erkennt automatisch Befehlsworte und färbt sie buntig ein (Syntax-Highlighting genannt). Schreibfehler werden sofort in trauer-schwarz eingefärbt und sind schnell erkennbar. Auch hier hilft das Abspeichern gegen den frühen Verlust von Quellcode.

Zum Seitenanfang

Der Assembler

Nun muss das ganze Programm von der Textform in die Maschinen-sprachliche Form gebracht werden. Den Vorgang heisst man Assemblieren, was in etwa Auftürmen oder zusammenschrauben bedeutet.

Beim WAVRASM klickt man dazu einfach auf den Menuepunkt mit der Aufschrift Assemble. Das Ergebnis ist im nächsten Bld zu sehen:

Der Assembler geruht uns damit mitzuteilen, dass er das Programm übersetzt hat. Andernfalls würfe er mit dem Schlagwort Error um sich. Immerhin ein Wort Code ist dabei erzeugt worden. Und er hat aus unserer Textdatei gleich vier neue Dateien erzeugt.

In der ersten der vier neuen Dateien, TEST.EEP, befindet sich der Inhalt, der in das EEPROM geschrieben werden soll. Er ist hier ziemlich uninteressant, weil wir nichts ins EEPROM programmieren wollen. Hat er gemerkt und die Datei gleich wieder gelöscht.
Die zweite Datei, TEST.HEX, ist schon wichtiger, weil hier die Befehlsworte untergebracht sind. Diese Datei brauchen wir zum Programmieren des Prozessors.

Sie enthält folgende Hieroglyphen:

Die hexadezimalen Zahlen sind als ASCII-Zeichen aufgelöst und werden mit Adressangaben und Prüfsummen zusammen abgelegt. Dieses Format heisst Intel-Hex-Format und ist uralt. Jedenfalls versteht diesen Salat jede Programmier-Software recht gut.

Die dritte Datei, TEST.OBJ, kriegen wir später, sie wird zum Simulieren gebraucht.

Ihr Format ist hexadezimal und von ATMEL speziell zu diesem Zweck definiert. Sie sieht im Hex-Editor folgendermassen aus:

Merke: Diese Datei wird vom Programmiergerät nicht verstanden! Versentliche Verwendung zum Programmieren in einen Chip endet mit Fehlermeldungen oder damit, dass der Chip nicht tut was er soll!

Die vierte Datei, TEST.LST, können wir uns mit einem Editor anschauen. Sie enthält folgendes:

Wir sehen das Programm mit allen Adressen, Maschinenbefehlen und Fehlermeldungen des Assemblers. Braucht man selten, aber gelegentlich.

Zum Seitenanfang

Das Programmieren des Chips

Dazu hat ATMEL den ISP gemacht. Wir starten das Programm ISP, erzeugen ein neues Projekt und laden die gerade erzeugte Hex-Datei mit LOAD PROGRAM.

Das sieht dann so aus:

Wenn wir nun mit dem Menue Program den Chip programmieren, dann legt dieser gleich los. Es gibt eine Reihe von weiteren Voraussetzungen (richtige Parallel-Schnittstelle auswählen, Adapter an Schnittstelle angeschlossen, Chip auf dem Programmierboard vorhanden, Stromversorgung auf dem Board eingeschaltet, ...), ohne die das natürlich nicht geht.
Inzwischen hat ATMEL aus mir unverständlichen Gründen die ISP-Software von der Internetseite genommen. Selbstverständlich gibt es auch Soft- und Hardware, die alternative Möglichkeiten der Chip-Programmierung zur Verfügung stellt. Das Internet gibt hier weitere erschöpfende Auskunft.

Zum Seitenanfang

Das Simulieren im Studio

Es kommt oft vor, dass eine geschriebene Software nicht auf Anhieb das tut, was sie soll. Das Ausprobieren im Chip selber kann schwierig sein, besonders wenn man aufgrund minimaler Hardware wenig Möglichkeiten hat, sich Zwischenergebnisse ausgeben zu lassen. Dafür ist das Studio von ATMEL ideal. Mit seiner Hilfe kann das Programm auf dem Trockenen getestet werden und Schritt für Schritt beobachtet werden.

Das Studio wird gestartet und sieht so aus:

Als erstes öffnen wir eine Datei (Menue File Open). Wir verwenden hier die Tutorial-Datei test1.asm, weil sie etwas mehr Befehle enthält als unser einfaches Testprogramm. Wir öffnen die Datei TEST1.OBJ. Dabei werden wir vermutlich gefragt, welche Options wir dazu verwenden wollen (wenn nicht: im Options-Menue Simulator-Options auswählen).

Die stellen wir so ein:

Bei der Device-Auswahl werden die richtigen Parameter voreingestellt, wir müssen nur die Taktfrequenz unseren Zwecken anpassen.

Damit wir beim Simulieren etwas sehen, öffnen wir mit dem View-Menue die beiden Zusatzfenster View Processor und View Registers. In diesen beiden Fenstern wird der Zustand des Prozessors und der Register angezeigt.

Die Anzeige sollte jetzt etwa so aussehen.

Im Prozessorfenster sind alle Werte abgebildet, die mit der Programmsteuerung, den Flags und den Ausführungszeiten zu tun haben (hier: 1 MHz ist eingestellt). Mit der Stopuhr lassen sich Ausführungszeiten des Programmes oder einzelner Routinen messen.

Jetzt starten wir das Programm. Aber nicht etwa mit GO, weil dann die Befehle nur so durchrattern und wir nichts sehen würden. Wir starten im Einzelschritt mit Trace Into oder F11. Damit wird der erste Befehlsschritt ausgeführt.

Nun sieht der Prozessor etwa so aus:

Der Programmzähler steht jetzt bei 1, der Zykluszähler bei 2 (der RJMP braucht zwei Zyklen). Bei einem MHz Takt sind 2 Mikrosekunden vergangen und an den Flags und Pointerregistern ist dabei nichts passiert. Im Quelltextfenster ist der Zeiger auf den nächsten Befehl gesetzt.

Erneutes Drücken von F11 führt den zweiten Schritt aus, das Register mp (=R16) wird mit 0xFF geladen.

Jetzt wird unser Register-Fenster interessant:

Das Register R16 zeigt, in rot gehalten, den neuen Wert an. Wir können übrigens Herrgott spielen und einfach Registerinhalte im Registerfenster willkürlich ändern, wenn wir mit dem Wert im Simulator nicht einverstanden sind.

Jetzt kommt Schritt 3, die Ausgabe an das PortB-Richtungsregister. Damit wir was sehen nach der Ausführung mit F11, öffnen wir mit View einen neuen I/O-view und dort den Port B.

Die Anzeige sieht jetzt so aus:

Im Data Direction Register des I/O-View-Fensters wird der neue Wert des Richtungsregisters mit kleinen Häkchen angezeigt. Auch die Ein- und Ausgabe-Pins können wir hier manipulieren und bei Bedarf einen Pin ändern.

Die beiden nächsten Schritte führen wir mit F11 aus. Sie sind hier nicht abgebildet.

Das Setzen der Ausgabe-Pins auf Eins mit LDI mp,0xFF und OUT PORTB,mp ergibt in einem neuen I/O-View dann folgendes Bild:

Nun sind auch die ausgabeseitigen Port-Bits alle Eins geworden, der I/O-View des Ports zeigt dies an.

Soweit dieser kleine Ausflug in die Welt des Simulators. Er kann noch viel mehr, deshalb sollte dieses Werkzeug bei allen hartnäckigen Fällen von Fehlern verwendet werden. Klicken Sie sich mal durch seine Menues, es gibt viel zu entdecken.

Zum Seitenanfang

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