Die Entwicklungsumgebung

Transkript

1 5. für den 8051/80535-Mikrocontroller Programmentwicklung für den Mikrocontroller erfolgt heute mit Softwarewerkzeugen, die den gesamten Entwicklungsprozeß vom Schreiben des Programms über die Übersetzung bis zum Programmtest unter einer gemeinsamen Entwicklungsoberfläche unterstützen. Diese Entwicklungsoberflächen werden meistens als IDE (Integrated Development Environment) bezeichnet. IDE s werden für die 8051-Controllerfamilie von mehreren Firmen angeboten. Im Computertechniklabor der Hochschule Bremen wird die IDE der Firma Keil benutzt, da hier eine leistungsfähige, frei kopierbare Demoversion existiert, die die Anforderungen für die Laborübungen gut erfüllt. Die aktuelle Version kann unter bezogen werden. Diese IDE läuft unter Windows und enthält einen Editor, mit dem der Quelltext des Programms erstellt wird einen leistungsfähigen Macro-Assembler A51 zur Übersetzung von Assemblerprogrammen einen C-Crosscompiler C51 mehrere Hilfsprogramme wie Linker, Object-File-Converter und Library-Manager zur Erstellung ablauffähiger Programme einen leistungsfähigen Debugger zum Programmtest. Dabei kann das Programm sowohl mit einem Simulator als auch in der Zielhardware getestet werden die Benutzungsoberfläche µvision, über die sämtliche Programme bedient werden Die Demoversion ist voll Funktionsfähig, Programme sind aber auf eine Object-Codelänge von weniger als 2 K Byte begrenzt und die Floating-Point-Library ist nicht verfügbar. Außerdem wird nur eine kleine Auswahl von 8051-Derivaten in der Demoversion unterstützt. 5.1.Erstellung von Assemblerprogrammen Die Assemblersyntax ist bereits im vorhergehenden Kapitel beschrieben worden. Hier soll jetzt aufgezeigt werden, wie man das entworfene Programm eingibt das eingegebene Programm übersetzt aufgetretene Syntaxfehler beseitigt Zuerst muß die Entwicklungsumgebung µvision gestartet werden. µvision kann über das entsprechende Icon (sofern vorhanden) oder über das Startmenue Programme unter Windows aufgerufen werden. Es erscheint dann ein Fenster entprechend Abb. 5.1 Größere Programme für Mikrocontroller werden aus mehreren eigenständigen Programmmodulen zusammengesetzt. Ein Programmodul löst in der Regel eine Teilaufgabe innerhalb einer größeren Gesamtaufgabe (Projekt). Die gemeinsame Verwaltung aller Module erfolgt im Rahmen der Projektverwaltung. Wenn auch die im Rahmen des Mikroprozessorlabors zu erstellenden Programme meistens nur aus einem Programmmodul bestehen, muß trotzdem für jede Programmentwicklung ein neues Projekt eröffnet werden. 5-1

2 Abb. 5.1 Bedienungsoberfläche µvision Bei der erstmaligen Eingabe eines Assemblerprogramms muß deshalb zuerst ein neues Projekt erstellt werden. Dies erfolgt unter µvision folgendermaßen: Projekt-Menue öffnen, New Project wählen und den Namen des neuen Projekts unter Dateiname (*.prj) angeben. Da zu dieser Zeit noch keine Quellprogrammdateien vorhanden sind, Save wählen und zum Hauptmenue zurückkehren. Anschließend im File-Menue New wählen, das Quellprogramm eingeben und unter einem von Ihnen gewünschten Namen abspeichern. Dies ist in der Regel ein anderer Name als der Projektname! Als Hinweis darauf, daß es sich um ein Assemblerprogramm handelt, sollte die Datei die Endung A51 haben (z.b. PROG1.A51). Projekt-Menue öffnen, Edit Project wählen. Add Sorce-Files wählen und die eben editierte Datei in die Liste der Source-Files aufnehmen. Darauf achten, daß als Translator A51-Assembler eingestellt ist. Diese Einstellung abspeichern. Ein Projekt muß nur einmal auf dem Rechner erstellt werden. Alle Einstellungen für Assembler, Compiler, Linker, Make und OH51 werden bei Beendigung von µvision gespeichert und stehen bei einem Neustart wieder zur Verfügung. Wurde das Projekt schon in einer früheren Sitzung angelegt, kann das bereits existierende Assemblerprogramm folgendermaßen geöffnet werden: Projekt-Menue öffnen, Open Project wählen. Aus der Liste der existierenden Projekte das gewünschte Projekt mit Doppelklick auswählen. Im File-Menue File Open wählen, unter Dateiname den Default-Wert *.c durch *.a51 ersetzen. Aus der angezeigten Liste die entsprechende Quelldatei (die in der Regel nicht den Namen des Projektes hat) auswählen und weiterbearbeiten. Das Editorfenster ist jetzt geöffnet und das Quellprogramm (Source-Programm) kann editiert werden. Ist das Programm komplett eingegeben bzw. sind alle gewünschten Änderungen durchgeführt, kann es assembliert werden. Dazu das Editor-Fenster mit dem zu übersetzenden Quellprogramm geöffnet lassen und im Projekt-Menue Compile wählen. Das im Editorfenster befindliche Quellprogramm wird übersetzt. Eventuell vorhandene Fehler werden in einem getrennten Fenster mit einem Hinweis auf den festgestellten Fehler angezeigt. Durch Doppelklick auf den angezeigten Fehler wird in das Editorfenster zurückverzweigt und der Cursor in der Nähe 5-2

3 des aufgetretenen Fehlers positioniert. Sobald das Quellprogramm (und alle anderen, u.u. im Projekt vorhandenen Module) fehlerfrei ist, kann es über den Linker/Locator in ein ablauffähiges Programm umgewandelt werden. Dazu im Projekt-Menue Make Build Project auswählen. Es werden der Linker und Locator und u.u. der Object-Hex-Converter gestartet (in Abhängigkeit der unter Optionen vorgenommenen Einstellungen)und ein im Simulator dscope oder im Übungsrechner unter tscope ablauffähiges Programm erzeugt. Sollten beim Make- Prozeß Fehlermeldungen auftreten, müssen die unter Options möglichen Einstellungen für A51 Assembler, BL51 Linker und für Make überprüft werden. Die Standardeinstellungen finden Sie unter Abschnitt Programmtest mit dem Softwaredebugger dscope dscope ist ein Werkzeug zum Test von Programmen, zur Fehlerlokalisierung und Fehlerbehebung, das auf dem PC abläuft. Um das zu realisieren, muß ein 8051-kompatibler Controller vollständig softwaremäßig auf dem PC simuliert werden. Weiterhin muß es eine Schnittstelle zum Benutzer geben, über die der Programmtest auf dem simulierten System ermöglicht wird. Diese Schnittstelle wird über ein weiteres Programm, den Debugger realisiert. Der Simulator selbst ist von außen nicht erreichbar. Er wird über dscope aufgerufen und gesteuert. Dies hat den Vorteil, daß durch Austausch des Simulators mit einer Kommunikationssoftware ein Monitorprogramm auf einem Zielsystem angesprochen werden kann und daß so mit den gleichen Debugbefehlen auch die erstellte Programme auf einem Hardwaresystem getestet werden können. Der Simulator hat die Aufgabe, das Verhalten des Prozessors möglichst weitgehend auf dem PC nachzubilden. Diese Aufgabe läßt sich in mehrere Teilaufgaben untergliedern: Simulation der auf dem Chip vorhandenen Hardware des Prozessors Simulation extern anschließbarer Hardware Simulation des Befehlsvorrates des Prozessors Simulation der Schnittstellen des Prozessors zur Außenwelt Zur Simulation der Prozessorhardware gehört alles das, was "on board" des Chips vorhanden ist. Bei der Prozessorfamilie gehören hierzu: internes RAM internes ROM (Programmspeicher) Register Special-Function-Register Timer/Counter Interruptlogik Analog/Digital-Wandler (z.b. beim 80535) Watchdog (z.b. beim 80535) Die Simulation der externen Hardware muß mindestens das umfassen. externe RAM und das externe ROM Zur Simulation der Prozessorbefehle gehört der gesamte Befehlsvorrat des Prozessors und deren Ausführung. Die Simulation der Schnittstellen des Prozessors umfaßt die Parallelen Ports Seriellen Ports Alle o.a. Funktionselemente sind in dscope in eigenen Fenstern darstellbar. Neben einem Debug- und einem Command-Fenster, die in fast jedem Fall benötigt werden, können weitere Fenster, die die Register und die Peripherie des Mikrocontrollers beschreiben, geöffnet werden. Weiterhin stehen bei Bedarf Fenster bereit, in denen ausgewählte Variablen beobachtet werden können oder die die im Programm benutzten Symbole 5-3

4 darstellen. Die auf dem Bildschirm darzustellenden Fenster werden über den Menue-Punkt View ausgewählt. Abb 5.2 zeigt den Bildschirm von dscope mit mehreren geöffneten Fenstern während einer Debug-Sitzung. Das größte, hier geöffnete Fenster ist das Debug-Fenster. Abb. 5.2 Bildschirm von dscope Folgende Funktionseinheiten können in jeweils eigenen Fenstern von dscope angezeigt werden: Anzeige des internen RAM Anzeige des externen RAM Anzeige des internen ROM Anzeige des externen ROM Anzeige der Register des Prozessors Anzeige der Special-Function-Register Anzeige der aktuell abgearbeiteten Befehle und der als nächsten ausführbaren Befehle Der Benutzer hat für den Programmstart und den Programmtest folgende Steuerungsmöglichkeiten beim Debugger: Einladen des Testprogramms Festlegung von Start- und Stopadressen Festlegung von Unterbrechungsmöglichkeiten 5-4

5 Festlegung der Arbeitsweise des Simulators (Trace, Run, Single Step) Über Menuepunkte oder Buttons in der Werkzeugleiste im Debugfenster können o.a. Punkte ausgewählt werden. Im Folgenden finden Sie eine kurze Anleitung, wie Sie ein unter µvision erstelltes Programm in dscope laden und ausführen können. a. Einstellung des benutzten Prozessors Bevor das zu testende Programm geladen wird, muß der richtige Treiber für den benutzten Mikrocontroller geladen werden. Die Auswahl geschieht über eine Pull-Down-Liste im linken Teil der Toolbar (Werkzeugleiste) unterhalb der Zeile, in der sich die Menue-Punkte befinden. Für den im Labor benutzten Mikrocontroller können die Treiber dll oder 80515a.dll ausgewählt werden. Die Treiber mon51.dll und mon51a.dll sind für die Kommunikation des Debuggers mit externer Hardware (z.b. Übungsrechner) vorgesehen. b. Laden des zu testenden Programms Öffnen Sie das File-Menue und wählen Load Object file. Wählen Sie die zu Ihrem Projekt gehörende Datei aus. Sie hat den Namen Ihres Projekts und nicht den Namen entsprechend Ihrer Quelldatei. Hat Ihre Projektdatei z.b. den Namen myproj.prj, dann hat der zu ladende Objectfile den Namen myproj. c. Programmzähler auf Startadresse setzen Normalerweise wird die Startadresse Ihres Programms durch eine ORG - Anweisung festgelegt, z.b.org 8100H Sie setzen jetzt den Programmzähler des Simulators bzw. die Startadresse im Übungsrechner durch die folgende Anweisung im Kommando-Fenster des Debuggers: $ = Startadresse (in HEX) z.b. $ = 0x8100. Das $-Zeichen wird oft als Symbol für den Stand des Befehlszählers verwendet. d. Öffnen weiterer Fenster Je nachdem, welche Peripherie des Mikrocontrollers, welche Speicher und welche Register Sie während des Programmtests beobachten wollen, können Sie die entsprechenden weiteren Fenster über das Menue View öffnen und an der von Ihnen gewünschten Stelle positionieren. Das Speicherfenster kann zusätzlich über das Kommandofenster konfiguriert werden. Damit können Sie festlegen, welchen Speichertyp des Controllers (direkt oder indirekt adressierbarer Speicher des internen RAM, externer Speicher oder Programmspeicher) und welchen Adressbereich Sie anzeigen wollen. Grundsätzlich gilt folgende Befehlssyntax d s: anfangsadresse,endadresse wobei d der Befehl für die Anzeige eines Speicherbereichs ist. s legt die Art des anzuzeigenden Speichers fest. Es gilt s = d : interner direkt adressierbarer Speicherbereich ( 0.. 7FH) s = i : interner indirekt adressierbarer Speicherbereich (0.. FFH) s = x : externer Datenspeicher ( 0.. FFFFH) s = c : Codespeicher ( 0.. FFFFH) Anfangsadresse und Endadresse müssen hexadezimal in der Form 0xA78C angegeben werden. e. Ausführung des Programms Für die Programmausführung gibt es die folgenden Befehle 5-5

6 GO GOTILCURS StepOut StepInto StepOver Stop Startet das Programm an der augenblicklichen Position des Befehlszählers Startet das Programm an der augenblicklichen Position des Befehlszählers und stoppt es an des Position des Cursors im Debugfenster Ein bereits begonnenes Unterprogramm wird zu Ende geführt. Die Simulation stoppt nach der RET-Anweisung Ausführung eines einzelnen Befehls an der augenblicklichen Position des Befehlszählers Ein Unterprogramm wird komplett ausgeführt, die Simulation stoppt nach der RET-Anweisung Das gerade laufende Programm wird im Simulator angehalten. f. Weitere Hinweise Wenn während des Programmtests Ein- oder Ausgaben über die serielle Schnittstelle erfolgen sollen, muß die serielle Schnittstelle des Mikrocontrollers zuvor durch das zu testende Programm entsprechend initialisiert worden sein. Wird im Fenster der seriellen Schnittstelle SBUF verändert und RI gesetzt, so liest ein entsprechendes Programm nicht diesen Wert, sondern meistens den Wert Null. Der in SBUF eingetragene Wert wird allerdings im Serial I/O Fenster richtig angezeigt. Im Fenster der seriellen Schnittstelle möglichst nur RI und TI verändern. Wenn ein externer Rechner angeschlossen ist, überhaupt nichts verändern, es besteht die Gefahr, daß das System sonst abstürzt. 5-6

7 5.3 Programmtest mit Monitor dscope arbeitet zum einen, wie unter 5.2. beschrieben, als reiner, softwaremäßig realisierter Debugger. Der gesamte Programmtest läuft auf dem PC ab. Diese Art der Programmentwicklung wird vor allem dann genutzt, wenn das zu realisierende Mikrocontrollersystem (das Zielsystem) noch nicht existiert oder bei größeren Projekten nicht in einer ausreichenden Anzahl vorhanden ist. Zum anderen kann dscope auch als Debugger auf hardwaremäßige realisierten Systemen eingesetzt werden, dann ändert dscope seinen Namen in tscope (t steht für target). Hier wird entsprechend Abb. 5.3 der Softwaresimulator des Prozessors durch einen real existierenden Prozessor in der Zielhardware ersetzt. Die Steuerung dieses Prozessors erfolgt über ein sog. Monitorprogramm, das das Laden von Anwendungsprogrammen in das Zielsystem, den Start und das Anhalten des Anwendungsprogramms unter bestimmten Bedingungen und die Überprüfung und Veränderung von Register- und Speicherinhalten ermöglicht. Die Kommunikation zwischen tscope und dem Monitorprogramm erfolgt über eine serielle Schnittstelle. Der Befehlssatz zum debuggen von Programmen in der Zielhardware ist weitgehend identisch mit dem des Softwaredebuggers, sodaß beim Übergang auf das Zielsystem keine neuen Befehle gelernt werden müssen. Es muß lediglich im Auswahlmenue für die CPU-Simulation nicht der Treiber für eine CPU 8z.B DLL) sondern der Treiber für den Target-Monitor (z.b. Mon51.DLL) ausgewählt werden. PC mit Debugger tscope Serielle Schnittstelle 8051-kompatibles System mit Monitorprogramm Abb. 5.3 Programmtest in einem Hardwaresystem 5.4. Test einfacher Beispielprogramme mit Hilfe von dscope Vor Ausführung der Beispiele lesen Sie bitte die Beschreibung zum Assembler in Kapitel 4. Das "Programm" BSP1 hat keine sinnvolle Gesamtfunktion. Vielmehr sind grundlegende Befehle des 8051 aneinandergereiht, um die Wirkungsweise der Befehle zu demonstrieren und den Benutzer mit der Funktion des Simulators vertraut zu machen. Sie sollten das folgende Programm über den in µvision vorhandenen Editor eingeben, mit A51 übersetzen und dann schrittweise ausführen. Dabei sollten Sie vor der Ausführung jeden Befehls überlegen, welche Wirkung seine Ausführung auf den Zustand des Prozessors haben wird. Öffnen Sie dann das entsprechende Fenster in dscope (z.b. wenn sich das Register R1 ändern soll, das Registerfenster, wenn Sie eine Änderung im internen Speicher erwarten, das Speicherfenster). Bevor Sie das Programm eingeben, sollten Sie entsprechend Kap. 5.2 ein Projekt (z.b. TEST1.PRJ) und eine Datei für das Programm (z.b. BSP1.A51) einrichten Aus der Endung.A51 erkennt µvision, daß es sich um ein Assemblerprogramm handelt. ORG 8100H MOV A,#77 MOV R0,A MOV R1,#88 XCH A,R1 MOV 40,A ;legt den Programmzähler auf die Startadresse 8100H fest ;(willkürlich gewählter Wert) ;Konst. in Accu, unmittelbare Adressierung ;Transport Register <--> Register ;Transport Register <--> Register ;Transport interner Speicher <--> Register 5-7

8 ;direkte Adressierung MOV R2,40 ;Transport Register <--> INC 40 ;Inhalt des internen Speichers um 1 erhöhen XCH A,40 ;Registerindirekte Adressierung MOV DPTR,#100 INC DPTR MOVX A,@DPTR MOV P3,R1 MOV P0,@R0 MOV P1,40 SETB 8 MOV C,8 ;Zugriff auf externes RAM, untere 256 Byte ;über DPTR kann der gesamte Speicher- ;bereich adressiert werden ;MOVX nur über Accu, die Anzeige des ext. ;Speicherber. läßt sich mit F8 scrollen! ;Ausgabe über Port CPL C MOV 8,C MOV A,#34 ;Duale Addition ADD A,#39 MOV A,#34 ;Dezimale Addition ADD A,#39 DA A ;Dezimalkorrektur MOV A,#20 MOV B,#5 MUL AB MOV A,#88 ANL A,@R0 SETB P1.1 ORL C,P1.1 ANL C,/P1.1 ;Der bitadressierbare interne Speicherbe- ;reich beginnt ab Adresse 20H. Bit 8 hat ;dann die Adresse 21.0 ;Carry-Flag ist der Boolsche Accumulator, ;steht in Bit 7 des Programm-Status-Wortes ;PSW ;Ergebnis der Multiplikation in A und B ;Logische Funktionen, byteweise ;Logische Funktionen, bitweise END ;signalisiert dem Übersetzer das Ende des zu über- ;setzenden Programms Bevor Sie das Programm übersetzen, müssen Sie dafür sorgen, daß die Einstellungen im Optionsmenue entsprechend Kap. 5.6 vorgenommen worden sind. Sobald die Übersetzung (über "Make Build Project" im Project-Menue) fehlerfrei gelaufen ist, steht eine in den Debugger ladbare Version Ihres Programms (Object-Programm) zur Verfügung). Sie können dann dscope über den zugehörige "Button" in der Werkzeugleiste (ganz links) aufrufen. In dscope muß als erstes der Prozessortyp in dem entsprechenden Menue ausgewählt und dann das Object-Programm geladen werden. Das Object- Programm hat nicht den Namen Ihres Quellprogramms sondern den Namen Ihres Projektes! Hier noch u.u. die Werkzeugleiste abbilden. 5-8

9 Mit dem Programm BSP2 soll der Mechanismus der Unterprogrammaufrufe demonstriert werden. Bei einem Unterprogrammaufruf wird der Programmzähler mit der Startadresse des Unterprogramms geladen und anschließend die im Unterprogramm stehenden Befehle ausgeführt. Nach Beendigung des Unterprogramms soll das aufrufende Programm mit dem Befehl fortgesetzt werden, der auf den Unterprogrammaufruf folgt. Das bedeutet, daß beim Aufruf des Unterprogramms die Adresse des auf diesen Aufruf folgenden Befehls gerettet werden muß um bei der Rückkehr aus dem Unterprogramm wieder zur Verfügung zu stehen. Das Retten dieser Adresse erfolgt beim Unterprogrammaufruf automatisch in einen dem Prozessor zur Verfügung stehenden freien Speicherbereich, den Stack. Verwaltet wird der Stack über den Stackpointer, einem 8-Bit-Register, das beim 8051 jeweils auf den letzten, noch belegten Speicherplatz zeigt. Bei einem Unterprogrammaufruf wird automatisch die 16-Bit-Adresse des auf diesen Aufruf folgenden Befehls in den nächsten beiden freien Speicherplätzen des Stacks abgespeichert und der Stackpointer um 2 erhöht. Bei Rückkehr aus dem Unterprogramm mit dem RET-Befehl werden ebenfalls automatisch die beiden letzten belegten Speicherplätze des Stacks in den Programmzähler geladen und der Stack um 2 dekrementiert. Falls der Stackpointer am Ende des Unterprogramms den gleichen Wert hat wie beim Eintritt in das Unterprogramm, bekommt der Prozessor die richtige Rücksprungadresse. Der Mechanismus des Unterprogrammaufrufs ist in Abb graphisch mit den Werten aus dem BSP2-Programm dargestellt. Unterprogramme sind beliebig schachtelbar, solange der Stackbereich genügend Platz für die Speicherung der Rücksprungadresse bietet. Da der Stack beim 8051 nur im internen RAM liegen kann und das interne RAM recht klein ist, sollte die Schachtelungstiefe in engen Grenzen gehalten werden. 8000H MOV SP,#60H 8003H MOV B,#06H 8006H LCALL 9000H Retten der Adresse 8009H auf den Stack Sprung zum Unterprogramm Startadr. 9000H 9000H PUSH B 9002H MOV A,#0AH 900AH RET 8009H MOV R1,A Holen der Adresse 8009H vom Stack in den Programmzähler Abb Mechanismus des Unterprogrammaufrufs Da das Programm BSP2 im wesentlichen den Mechanismus der Unterprogrammbehandlung demonstrieren soll, werden in den Unterprogrammen selbst keine umfangreichen Operationen ausgeführt. Programm BSP2: ORG 8000H MOV SP,#5FH MOV B,#6 CALL UP1 ;erster freier Speicherplatz im Stack bei 60H ;Aufruf des ersten Unterprogramms 5-9

10 MOV R1,A MOV R2, B L1: LJMP L1 ORG 9000H ;erstes Unterprogramm beginnt bei 9000H UP1: PUSH B ;Beginn Unterprogramm 1 MOV A,#0AH MUL AB CALL UP2 POP B RET ORG 9100H ;zweites Unterprogramm beginnt bei 9100H UP2: MOV P1, B ;Beginn Unterprogramm 2 MOV P2,A RET END Der Aufruf von UP2 ist in Abb. 5.4 aus Gründen der Übersichtlichkeit nicht dargestellt. Wenn Sie das Programm starten und den internen Speicher im Speicherfenster beobachten, ergibt sich im Debug-Fenster folgender Programmablauf: MOV SP,# F006 MOV B,# LCALL 9000 ;Beobachten Sie den Stack- ;pointer SP und den Stack ;ab Adresse 60H 9000 C0F0 PUSH B ;der Programmzähler PC steht ;jetzt auf 9000H! A MOV A,#0A 9004 A4 MUL AB LCALL 9100 ;SP und Stack beobachten! F090 MOV P1,B ;PC steht jetzt auf 9100H 9103 F5A0 MOV P2,A RET ;SP und PC beachten! 9008 D0F0 POP B ;SP beachten! 900A 22 RET ;SP und PC beachten! 8009 F9 MOV R1,A ;jetzt sind wir wieder im Hauptprogramm Verändern Sie anschließend das Programm, indem Sie PUSH B und später POP B weglassen. Warum kommen Sie jetzt nach Beendigung des Unterprogramms UP1 nicht mehr in das Hauptprogramm zurück? 5.5. Fehlersuche mit Hilfe des Debuggers Größere Programme laufen in der Regel nach ihrem Entwurf und der Codierung nicht sofort fehlerfrei. Mögliche Fehlerquellen sind u.a.: Fehlerhafter Algorithmus Fehlerhafte Implementierung eines Algorithmus Codierungsfehler (Auswahl eines nicht geeigneten Befehls) 5-10

11 Fehler, die in Folge zeitlicher Abhängigkeiten verschiedener Prozesse während der Laufzeit auftreten Bis auf die zuletzt genannte Fehlermöglichkeit lassen sich alle anderen Fehler mit Hilfe des Softwaresimulators finden. Da der Simulator auf dem PC abläuft, ist der Mikrocontroller nicht in Echtzeit zu simulieren. Deshalb kann der Simulators auch nicht auf in Echtzeit ablaufende Prozesse angesetzt werden. Der Simulator ist in der Größenordnung um den Faktor 2 bis 10 (abhängig von der Geschwindigkeit des PC) langsamer als der Mikrocontroller selbst (12 MHz Takt am Mikrocontroller vorausgesetzt). Alle anderen Fehler lassen sich mit Hilfe des Simulators finden. Ist das realisierte Programm von mehreren, u.u. in ihrem Zeitverhalten schwer beschreibbaren Eingangssignalen abhängig, wird der Test auf dem Simulator mit manuellem Setzen der Eingabegrößen recht aufwendig. In diesem Fall ist der Test auf einem in Hardware vorhandenen Mikrocontrollersystem meistens einfacher und schneller durchzuführen. Die einfachste Möglichkeit, ein Programm zu testen, ist die Ausführung der Befehle im Einzelschrittmodus. Der Programmzähler wird auf die Anfangsadresse des zu testenden Programmteils gesetzt (z.b. $ = 0x8100) und das Programm wird Befehl für Befehl über den Einzelschritt-Button ausgeführt. Dabei wird die Wirkung der Befehle auf die angegebenen Operanden in den entsprechenden Fenstern des Bildschirms beobachtet und verglichen, ob die erwarteten Ergebnisse erzeugt werden. Auf diese Weise ist ein vorhandener Fehler eindeutig lokalisierbar. Diese Testmöglichkeit ist aber nur in kürzeren Programmen sinnvoll einsetzbar. Tritt ein Fehler erst nach z.b. dem 500. Befehl auf, müßte die Einzelschrittfunktion 500 mal durchgeführt werden. Es besteht deshalb die Möglichkeit, Programmteile, von denen man annimmt, daß sie fehlerfrei sind, automatisch abarbeiten zu lassen und das Programm in der Nähe des als fehlerhaft vermuteten Programmteils anzuhalten. Dies geschieht durch Setzen eines "Breakpoints" durch Doppelklick auf den entsprechenden Befehl im Debug-Fenster des Simulators. Nachdem das Programm dort angehalten hat, wird man zuerst kontrollieren, ob alle wichtigen Speicherplätze die vorausberechneten Werte enthalten, d.h. ob das Programm bis hierhin fehlerfrei gelaufen ist, und dann im Einzelschrittbetrieb weiter testen.. Erwartet das zu testende Programm Eingaben über die auf dem Controller implementierte Peripherie oder soll das Programm über diese Peripherie (z.b. Ports, serielle Schnittstelle) Ausgaben machen, so läßt sich dies über Öffnen der entsprechenden Fenster realisieren. 5-11

12 5.6. Standardeinstellungen für µvision Einstellungen im Optionsmenue von µvision für Assemblerprogrammierung 5-12

13 5-13