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

Werkzeuge für die AVR-Assembler-Programmierung

In diesem Abschnitt werden die Werkzeuge vorgestellt, die zum Assembler-Programmieren nötig sind. Dabei werden zunächst Werkzeuge besprochen, die jeden Arbeitsschritt separat erledigen, damit die zugrunde liegenden Schritte einzeln nachvollzogen werden können. Erst danach wird eine integrierte Werkzeugumgebung vorgestellt.

Für die Programmierung werden vier Teilschritte und Werkzeuge benötigt. Im einzelnen handelt es sich um
  1. den Editor,
  2. den Assembler,
  3. das Programmier-Interface, und
  4. den Simulator.
Die dargestellten Fenster sind alle © ATMEL. Es wird darauf hingewiesen, dass die Bilder mit Software erstellt wurden, die heute nicht mehr verfügbar und sinnvoll anwendbar ist. Sie wird hier nur verwendet, um die Teilschritte klarzumachen.

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 zeigen hier ein etwas veraltetes Gerät, den WAVRASM von ATMEL.

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

Screenshot WAVRASM mit Eingabe Im Editor 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 der Assembler-Quellcode.

Screenshot Syntax-Highlighting Manche Editoren erkennen Instruktionen und Symbole und färben diese Worte entsprechend ein, so dass man Tippfehler schnell erkennt und ausbessern kann (Syntax-Highlighting genannt). In einem solchen Editor sieht unser Programm so aus:

Auch wenn die im Editor eingegebenen Worte noch ein wenig kryptisch aussehen, sie sind von Menschen lesbar und für den Mikroprozessor noch völlig unbrauchbar.

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 "Zusammenbauen", "Auftürmen" oder auch "zusammenschrauben" bedeutet. Das erledigt ein Programm, das auch so heißt: Assembler. Derer gibt es sehr viele. Für AVR heißen die zum Beispiel "AvrAssembler" oder "AvrAssembler2" (von ATMEL, Bestandteil der Studio-Entwicklungsumgebung), "TAvrAsm" (Tom's AVR Assembler) oder mein eigener "GAvrAsm" (Gerd's AVR Assembler). Welchen man nimmt, ist weitgehend egal, jeder hat da so seine Stärken, Schwächen und Besonderheiten.

Nach dem Assemblieren Beim WAVRASM klickt man dazu einfach auf den Menuepunkt mit der Aufschrift "Assemble". Das Ergebnis ist in diesem Bild 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 einfachen 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 wollten. Hat er gemerkt und die Datei auch gleich wieder gelöscht.

Hex-Form des Programmes 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 die nebenstehenden 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.

Object-Format 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 wie abgebildet aus. Merke: Diese Datei wird vom Programmiergerät nicht verstanden!

List-Datei Die vierte Datei, TEST.LST, können wir uns mit einem Editor anschauen. Sie enthält das Nebenstehende. Wir sehen das Programm mit allen Adressen (hier: "000000"), Maschinenbefehlen (hier: "cfff") und Fehlermeldungen (hier: keine) des Assemblers. Die List-Datei braucht man selten, aber gelegentlich.



Zum Seitenanfang

Das Programmieren des Chips

Nun muss der in der Hex-Datei abgelegte Inhalt dem AVR-Chip beigebracht werden. Das erledigt Brenner-Software. Üblich sind die Brenn-Tools im Studio von ATMEL, das vielseitige Pony-Prog 2000 und andere mehr (konsultiere die Lieblings-Suchmaschine).

ISP Fenster Das Brennen wird hier am Beispiel des ISP gezeigt. Das gibt es nicht mehr, arbeitet aber sehr viel anschaulicher als moderne Software, weil es einen Blick in das Flash-Memory des AVR ermöglicht. Zu sehen im Flash-Speicher ist sein Inhalt nach dem Löschen: lauter Einsen!
Wir starten das Programm ISP, erzeugen ein neues Projekt und laden die gerade erzeugte Hex-Datei mit LOAD PROGRAM. Das sieht dann wie im Bild aus. Wenn wir nun mit dem Menue Program den Chip programmieren, dann legt dieser gleich los. Beim Brennen gibt eine Reihe von weiteren Voraussetzungen (richtige Schnittstelle auswählen, Adapter an Schnittstelle angeschlossen, Chip auf dem Programmierboard vorhanden, Stromversorgung auf dem Board eingeschaltet, ...), ohne die das natürlich nicht geht.



Zum Seitenanfang

Das Simulieren im Studio

In einigen Fällen hat selbst geschriebener Code nicht bloß Tippfehler, sondern hartnäckige logische Fehler. Die Software macht einfach nicht das, was sie soll, wenn der Chip damit gebrannt wird. Tests auf dem Chip selbst können kompliziert sein, speziell wenn die Hardware aus einem Minimum besteht und keine Möglichkeit besteht, Zwischenergebnisse auszugeben oder wenigstens Hardware-Signale zur Fehlersuche zu benutzen. In diesen Fällen hat das Studio-Software-Paket von ATMEL einen Simulator, der für die Entwanzung ideale Möglichkeiten bietet. Das Programm kann Schritt für Schritt abgearbeitet werden, die Zwischenergebnisse in Prozessorregistern sind überwachbar, etc.

Die folgenden Bilder sind der Version 4 entnommen, die ältere Version 3 sieht anders aus, macht aber in etwa dasselbe. Die Studio Software enthält alles, was man zur Entwicklung, zur Fehlersuche, zur Simulation, zum Brennen der Programme und an Hilfen braucht. Nach der Installation und dem Start des Riesenpakets (z. Zt. ca. 100 MB) sieht das erste Bild wie folgt aus:

Studio leer Der erste Dialog fragt, ob wir ein neues oder bereits bestehendes Projekt öffnen wollen. Im Falle einer Erstinstallation ist "New Project" die korrekte Antwort. Der Knopf "Next>>" bringt uns zum Einstellungsdialog für das neue Projekt:

Studio Projekt Hier wird die Plattform "Simulator" ausgewählt.

Studio Device Ferner wird hier der Prozessor-Zieltyp (hier: ATmega8) ausgewählt und der Dialog mit "Finish" abgeschlossen. Das öffnet ein ziemlich großes Fenster mit ziemlich vielen Bestandteilen:

Studio Editor
Alle Fenster sind in Größe und Lage verschiebbar.

Für den Nachvollzug der nächsten Schritte im Studio ist es notwendig, das im Editorfenster sichtbare Programm abzutippen (zu den Bestandteilen des Programmes später mehr) und mit "Build" und "Build" zu übersetzen. Das bringt die Ausgabe im unteren Build-Fenster zu folgender Ausgabe:

Studio Build Dieses Fenster teilt uns mit, dass das Programm fehlerfrei übersetzt wurde und wieviel Code dabei erzeugt wurde (14 Worte, 0,2% des verfügbaren Speicherraums.

Nun wechseln wir in das Menü "Debug", was unsere Fensterlandschaft ein wenig verändert:

Studio Debug Im linken Editor-Fenster taucht nun ein gelber Pfeil auf, der auf die erste ausführbare Instruktion des Programmes zeigt. Mit "View", "Toolbars" und "Processor" bringt man das Prozessorfenster rechts zur Anzeige. Es bringt uns Informationen über die aktuelle Ausführungsadresse, die Anzahl der verarbeiteten Instruktionen, die verstrichene Zeit und nach dem Klicken auf das kleine "+" neben "Registers" den Inhalt der Register.

Mit "Debug" und "Step into" oder der Taste F11 wird nun ein Einzelschritt vorgenommen.

Debug Schritt 1 Der Programmzähler hat sich nun verändert, er steht auf "0x000001". Der Schrittzähler hat einen Zyklus gezählt und im Register R16 steht nun hexadezimal "0xFF" oder dezimal 255. LDI lädt also einen Hexadezimalwert in ein Register.

Nach einem weiteren Schritt mit F11 und Aufklappen von PORTB im Hardware-Fenster "I/O-View" ist die Wirkung der gerade abgearbeiteten Instruktion "out PORTB,rmp" zu sehen:

Debug Out Das Richtungs-Port-Register Data Direction PortB (DDRB) hat nun 0xFF und in der Bitanzeige unten acht schwarze Kästchen.

Mit zwei weiteren Einzelschritten (F11) hat dann der Ausgabeport PORTB den Hexadezimalwert "0x55".

Debug Port=55

Zwei weitere Schritte klappen die vier schwarzen und die vier weißen Kästchen um.

Debug Port=AA Erstaunlicherweise ist nun der Port PINB dem vorhergehenden Bitmuster gefolgt. Aber dazu dann später im Abschnitt über Ports.

Soweit dieser kleine Ausflug in die Welt des Simulators. Er kann noch viel mehr, deshalb sollte dieses Werkzeug oft und insbesondere 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-2009 by http://www.avr-asm-tutorial.net