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
- den Editor,
- den Assembler,
- das Programmier-Interface, und
- 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.
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.
Der WAVRASM sieht nach der Installation und nach dem Start eines neuen Projektes etwa so aus:
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.
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
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.
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.
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.
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!
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
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).
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
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:
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:
Hier wird die Plattform "Simulator" ausgewählt.
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:
- links oben das Fenster mit der Projektverwaltung, in dem Ein- und Ausgabedateien verwaltet
werden können,
- in der Mitte oben ist das Editorfenster zu sehen, das den Inhalt der Datei
"test1.asm" anzeigt und in das der Quelltext eingegeben werden kann,
- rechts oben die Hardware-Ansicht des Zielprozessors (dazu später mehr),
- links unten das "Build"-Fensters, in dem Diagnose-Ausgaben erscheinen, und
- rechts unten ein weiteres Feld, in dem diverse Werte beim Entwanzen angezeigt werden.
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:
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:
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.
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:
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".
Zwei weitere Schritte klappen die vier schwarzen und die vier weißen Kästchen um.
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