Werkzeuge für Embedded-System-Debugging - All

SYSTEMS ENGINEERING
Entwicklungssysteme
Werkzeuge für
Embedded-System-Debugging
Ein Software-Simulator ist unabhängig von der Hardware, die entwickelt
wird. Dagegen ersetzt ein In-CircuitEmulator nahtlos den Zielprozessor
für maximale Kontrolle über die
Hardware. In Bezug auf Kosten und
Leistung liegen die anderen Werkzeuge zwischen diesen beiden Konzepten. Die Vorteile eines Werkzeugs
bei der Verkürzung des Produktentwicklungszyklus werden um so grösser, je besser das Werkzeug in die Hardware des Endprodukts integriert ist.
In-Circuit-Emulation
In-Circuit-Emulatoren (ICE) können
Code in Echtzeit ausführen, Peripheriefunktionen komplett nachbilden
und Breakpoints überwachen. HighEnd-Emulatoren bieten darüber hinaus Echtzeit-Trace-Buffer, manche
von ihnen können die Befehlsausführung mit Zeitmarken für ein CodeProfiling versehen. Emulatoren kann
man an Stelle des Embedded-Prozessors in das Zielsystem einsetzen.
Manchmal implementiert man ICEs
mit einem speziellen ASIC oder FPGA,
Simulation
der die Codeausführung und Peripherieelemente des Coreprozessors
Für viele Embedded-Prozessoren
nachbildet. Mit diesem Konzept kann
gibt es Software-Instruktionssimulaein Emulator zwar mehrere Prozestoren. Einige von ihnen beschränken
sorfamilien abdecken, möglicherweisich ausschließlich auf die Simulation
se treten dabei aber Verhaltensunder Befehlsausführung. Die meisten
terschiede zwischen dem eigentlibieten Breakpoints, wodurch man
chen Bauteil und dem Emulator auf.
den Code schnell bis zur AbarbeiManche Hersteller verknüpften das
tung einer definierten Instruktion
Verhalten von emulierten und echausführen kann. Mit Trace-Funktioten Mikroprozessoren durch die Entnen kann die Abfolge der ausgewicklung spezieller "Bond-out"führten Befehle dargestellt werden.
Emulationsbauteile. Diese SpezialBei allen Simulatoren kann der
bauteile arbeiten mit der gleichen
JOHN ANDREWS, JOHN DAY
Anwender auf die internen Register
Schaltungstechnologie wie der Zieldes Prozessors lesend und schreiprozessor und eröffnen dem Emulabend zugreifen, und die simulierte
tor den Zugriff auf interne DatenreDie branchenüblichen Werkzeuge für die EntwickProgrammausführung steuern. Wähgister, Programmspeicher und Perilung von Embedded-Systemen reichen von reinen
rend die Simulation von Befehlen
pherieelemente. Dazu eliminiert man
Softwaremonitoren und Simulatoren bis zu
sinnvoll für die Entwicklung von Alden internen Programmspeicher des
gorithmen ist, erfordern embedded
spezialisierter Hardware für die In-Circuit-Emulation. Prozessors und stellt diesen Speicher
Systeme auf Grund ihres Aufbaus
über Emulations-RAM bereit. Die
Hauptzweck all dieser Werkzeuge ist die BereitstelZugriff auf Peripherieelemente wie
Mikrocontroller-Firmware wird in
lung eines Fenster auf die Betriebsabläufe der
I/O-Ports, Timer, AD-Wandler, Pulsden Emulations-RAM heruntergelaweiten-Modulatoren usw.
den; während der Ausführung dieser
Software im Inneren des Embedded-Prozessors.
Bei leistungsfähigeren Simulatoren
Instruktionen nutzt der "Bond-out"wie z. B. MPLAB-SIM sind viele PeriProzessor die gleichen Datenregister
pheriefunktionen wie I/O-Pins, Interrupts, Sta- damit die preisgünstigste Entwicklungsumge- und Peripherieelemente wie der Zielprozessor.
tus- und Steuerregister implementiert. Mit die- bung.
Dazu stellt man die I/O-Anschlüsse der "Bondsen Peripherie-Simulatoren lassen sich das Ti- Implementationen der Peripherieelemente out"-Schaltung auf den Sockel bereit, der an
ming und grundlegende Peripherieoperatio- erleichtern das Debuggen peripherer Interak- Stelle des zu emulierenden Zielprozessors in
nen verifizieren. Sie bieten eine Reihe von Sti- tionen und sind effektiver als Simulatoren, die das zu entwickelnde System eingesetzt wird.
mulus-Eingängen; diese reichen von Druckta- nur den Befehlssatz abarbeiten. Die Simulation Emulatorsysteme ermöglichen die direkteste
sten, die mit I/Os verbunden sind, über aller denkbaren externen Betriebszustände ist Verbindung zwischen dem Host mit der BedieI/O-Stimulusdateien mit logischen Vektoren, aber sehr schwierig; viele Echtzeitsysteme las- nerschnittstelle und dem zu entwickelnden
regulären Takteingängen und der Wertein- sen sich per Simulation nur schwer debuggen. System. Der "Bond-out"-Chip bietet einen digabe in interne Register bis zur Simulation der Zudem arbeiten Simulatoren typisch mit rekten Zugriff auf I/O-Pins und PeripherieeleAD-Wandlungsdaten oder eines seriellen Geschwindigkeiten, die um den Faktor 100 bis mente. Der Emulations-RAM ermöglicht ein
Kommunikationseingangs. Viele embedded 1000 unter der des Embedded-Prozessors lie- schnelles Herunterladen des revidierten Codes
Systeme lassen sich sehr effektiv mit geeigne- gen (solange man Timeout-Delays bei der auf Knopfdruck. Moderne Emulatoren, wie
ten peripheren Stimulusdaten debuggen. Si- Simulation eliminiert).
der neue MPLAB-ICE 2000, bieten weitere
mulatoren sind oftmals gratis erhältlich und
Debugging-Hilfsmittel, wie z. B. bedingte Bre- ©
elektronik industrie 12 – 1999
http://www.elektronik-industrie.de
63
SYSTEMS ENGINEERING
Entwicklungssysteme
akpoints auf mehreren Ebenen und eine Tracefunktion für Instruktionen mit Datums- und
Zeitmarken. Mit dem MPLAB-ICE 2000 TraceAnalyzer kann man sogar ein System debuggen, ohne den Prozessor anzuhalten.
Wie bei allen anderen Geräten, erhält man
auch bei Entwicklungswerkzeugen das, wofür
man bezahlt. Komplex aufgebaute Trace-Buffer, Hochgeschwindigkeits-Emulations-RAM
und spezielle "Bond-out"-Chips machen den
Emulator teurer als weniger leistungsfähige
Entwicklungswerkzeuge. Manche Emulatoren
können sogar die maximale Taktgeschwindigkeit von Prozessoren oder die Betriebspannung einschränken. Die Verkabelung mit dem
zu entwickelnden System kann umständlich
sein und möglicherweise sogar Hf-Störungen
verursachen. Bei mechanisch sehr kompakt
aufgebauten Systemen ist es oftmals schwierig, den Emulatortastkopf an Stelle des Zielprozessors anzuschließen.
Anschluß an die Hardware und
Emulation
Der große Leistungs- und Preisunterschied
zwischen dem kompletten Austausch des Zielprozessors durch die Emulation und der Interpretation von Informationen aus einem Softwaresimulator bietet viel Raum für Zwischenlösungen. Der Simulator liefert die grundlegende,
für ein Cross-Development von embedded
Hardware erforderliche Benutzerschnittstelle:
Breakpoints, Einzelschrittbetrieb, Überwachung
von Variablen usw. Die wichtigste Einschränkung eines Simulators ist seine vollständige
Trennung von der eigentlichen Ziel-Hardware.
"Burn and Learn" FirmwareDebugging
Wer simuliert, wird seine Run-Time FirmwareEntwicklung meist im "Burn and Learn" Verfahren erledigen. Dazu brennt man zunächst
ein Chip auf einem Programmer, setzt dies in
die Ziel-Hardware ein, und beobachtet, wie
das System abstürzt. Nach eingehender Analyse und Überprüfung der Symptome per
Simulation verändert man den Quellcode,
stellt das ausführbare Programm um und
brennt einen weiteren Chip. Dieser "Burn and
Learn"-Zyklus läuft mehrmals ab. Ohne Zugriff
auf internen Prozessor-RAM, Breakpoints, Programmzähler und schnelle Downloads zum
Programmspeicher kann dieses Debugverfahren ineffizient, langsam und mühsam sein. Für
die Ausgabe wichtiger Debuginformationen
kann man Routinen erstellen, mit denen sich
die Daten über einen seriellen Port zur Anzeige
auf einen Terminal ausgeben lassen. Zur Anzeige des Programmablaufs kann man I/O-Pins
hin- und herschalten. Liefert das Zielsystem während seines Betriebs weitere Symptome, so
kann man am Quellcode natürlich Verände-
64
Bild 1: Aufbau einer In-Circuit-Emulation
rungen vornehmen. Sonst aber ist es ziemlich
frustrierend, wenn man beim Debuggen mit
der "Burn and Learn" Methode raten muß,
wieso sich das System jetzt genau so verhält.
In-Circuit Simulatoren
Simuliert man Code, bei dem Verzweigungen
abhängig vom Zustand eines Eingangspins
oder einer anderen Hardwarebedingung sind,
dann muß der Simulator diesen Zustand aus
der realen Ziel-Hardware erkennen. Meist liefert man diese Information in Form von Simulator-Stimulusdaten. Könnte der Simulator diesen Stimulus direkt von der Ziel-Hardware
abfragen, so würde man sich einen Schritt
weit von einer reinen Softwarelösung entfernen und bereits näher an ein Hardware-Debugging herankommen. Das SIMICE Entwicklungswerkzeug für die 8-bit PIC16C5X Mikrocontrollerfamilie tut genau das: Es integriert
die Funktionen des MPLAB-SIM-Simulators mit
einem Kommunikationsmodul, das als Zielpro-
Die wesentlichen Merkmale von MPLAB-ICD
In-Circuit Run-Time debugging
Codeausführung in Echtzeit
Einzelschrittbetrieb
Ein Hardware-Breakpoint
Lese- und Schreibzugriff auf den Datenspeicher
3,0V bis 5,5V
32kHz bis 20MHz
PIC16F87X Bauteilprogrammierung über ICSP
Entwicklungs- und Evaluationskit für PIC16F87X
Kommunikation mit PC über serielle Schnittstelle mit bis zu 57600 Baud
Nutzt die integrierte MPLAB Entwicklungsumgebung:
Grafische Bedienerschnittstelle
Editor
Assembler
Linker
Simulator
Projekt-Managing-Werkzeuge
Symbolisches Source-Level-Debugging
Schnittstelle zu High-Level-Sprachen
Symbolisches Watch-Window
Einzelschritt-Ausführung des Quellcodes und Breakpoint-Funktion
Schnittstelle zum ICD und zu anderen Hardware-Tools
Emulatoren
Bauteile-Programmer
http://www.elektronik-industrie.de
elektronik industrie 12 – 1999
SYSTEMS ENGINEERING
Entwicklungssysteme
zessor arbeitet. Dieses Modul liefert Stimulussignale für die Simulation direkt von den digitalen Eingangspins des Zielprozessors und
ermöglicht dem Simulator, binäre Werte an
den Ausgangspins einzustellen. Diese Kompromißlösung verknüpft den Simulator etwas
enger mit der Hardware und überwindet das
Kostenproblem eines Emulators. Steht ein gut
entwickelter Softwaresimulator bereit, dann
kann dieser noch mehr Nutzen bieten, wenn
man ihn um ein Werkzeug zur Aufnahme von
Stimulussignalen ergänzt, das mit der ZielHardware kommuniziert. Dies löst allerdings
noch immer nicht alle Probleme. Ein solches
Werkzeug läuft noch immer auf der Geschwindigkeit des Simulators und kann daher
Ausgangspins nicht schnell genug einstellen
und löschen, um zeitkritische Funktionen, wie
ein Software-UART, zu implementieren. Dieses
Werkzeug unterstützt außerdem keine der
komplexeren Peripheriefunktionen von höher
integrierten 8-bit Mikrocontrollern aus der
Microchip Mittelklasse-Produktfamilie, wie
AD-Wandlung und Pulsweitenmodulation.
Diese Einschränkungen können ernsthafte
Ausfälle beim Debuggen der meisten embedded Systeme verursachen.
elektronik industrie 12 – 1999
Run-Time-Monitore
Der Kommunikationskanal zwischen dem
Host-Entwicklungssystem und der zu entwikkelnden Ziel-Hardware ist eine lebenswichtige
Funktion bei In-Circuit-Simulatoren. Wenn ein
solcher Kanal bereit steht, dann kann man die
Ausführung des Zielcodes als nächsten logischen Schritt aus dem Simulator des Hostsystems auslagern und ihn auf der ursprünglichen Ziel-Hardware ablaufen lassen. Eine solche Abarbeitung des Codes über Multiplexing
und die Übermittlung von Debugging-Informationen mit einem Cross-Development-Host
bezeichnet man als Run-Time Monitor.
Für die Kommunikationsfunktion benötigt ein
solches Werkzeug meist etwas ähnliches wie
z.B. ein UART in der Ziel-Hardware. Der Host
kann nun Befehle an den Zielprozessor ausgeben, damit dieser Funktionen wie das Einstellen oder Lesen von Speicherinhalten ausführen
kann. Dies ermöglicht auch ein gewisses Maß
an Kontrolle über die Codeausführung. Software-Breakpoints lassen sich implementieren,
indem man Befehle dort einfügt, wo die Codeausführung auf den Monitor verzweigen und
dem Anwender des Bedienerschnittstellen-Hosts
Anforderungen für Run-Time
Ressourcen
Neben den I/O-Pins der Schnittstelle belegt
der ICD eine Reihe weiterer Prozessor-Ressourcen. Weil der Debugger-Kernel im
Zielprozessor liegt und abläuft, belegt er
einen kleinen Teil der dort verfügbaren
Ressourcen:
e
e
e
e
ca. 256 Worte des
Testprogrammspeichers
ca. 10 Byte des allgemeinen RAM
ein Level des HardwareSubroutinen-Stacks
zwei Universal-I/O-Pins
In Bezug auf die Prozessorbandbreite gilt
das gleiche wie für einen Run-Time Monitor.
Steuermöglichkeiten und Daten liefern soll. Auch
hier gilt: wenn das Hostsystem-Simulationswerkzeug die Bedienerschnittstelle bereitstellen kann, dann läßt sich bestehende Technolo©
gie mit größerem Funktionsumfang nutzen.
http://www.elektronik-industrie.de
65
SYSTEMS ENGINEERING
Entwicklungssysteme
Software-Breakpoints kann man während des
Kompilierens einbauen. Andere Funktionen,
wie die Verknüpfung (hooking) mit einem
periodischen Timerinterrupt zum Kopieren
wichtiger Daten vom Ziel zum Host, lassen sich
ebenfalls bei der Erstellung einer ausführbaren
Datei einbinden. Da man bei dieser Technik
während der Programmausführung keine
Daten in den Programmspeicher schreiben
muß, kann man dieses Verfahren auch im
"Burn and Learn" Debugging mit einmalprogrammierbaren Bauteilen nutzen. Erstaunlicherweise rechnet man die für das UV-Löschen
von Bausteinen mit Fenster benötigte Wartezeit nicht in die "Crash, Erase and Burn”Zykluszeit ein. Müssen Änderungen schnell
ausgeführt werden und stehen nur wenige
Bauteile bereit, dann kann der Löschvorgang
mit Abstand am meisten Zeit beanspruchen.
Monitore findet man daher meist in Systemen
mit RAM oder Flash-Programmspeichern, die
sich schnell und ohne UV-Löschzyklus beschreiben lassen.
Die für eine Übertragung von Debugging-
ein reines Software-Werkzeug ist, das auf dem
Zielprozessor ausgeführt wird, bietet das
Werkzeug nur begrenzte Kontrollmöglichkeiten für die Programmausführung. Ergänzt
man die Hardware des Zielprozessors um nur
einige wenige Support-Funktionen, so wird
der Software-Monitor zu einem System, das
alle Grundfunktionen eines Emulators bietet.
In-Circuit-Debugger
Sobald man den Zielprozessor um Hardwarefunktionen auf dem Chip erweitert, leistet das System mehr als ein Software-Monitor. Entwicklungswerkzeuge mit besonderen
Chipfunktionen für Code-Debugging und serielle Kommunikation zwischen Host und Target
nennt man "Debugger". Früher boten Systeme mit externem RAM-Programmspeicher
diese Funktion. Seitdem es reprogrammierbare
Flash-Programmspeicher gibt, wurden In-Circuit-Debugger-Werkzeuge für Single-Chip
Embedded-Mikrocontroller machbar. Bei In-
Bild 2: Hardwarekonfiguration MPLAB-ICD
Daten zum Host oder zum Herunterladen
einer neuen ausführbaren Datei, d. h. des
eigentlichen Monitor-Codes, nötigen Routinen belegen im Zielbauteil einen gewissen
Bereich des Programmspeichers. Zudem benötigen sie auch einiges an Datenspeicher und
beanspruchen neben dem UART oder anderen
Kommunikationsbauteilen einen Teil der Bandbreite des Zielprozessors. Glücklicherweise
fällt der Großteil dieses Overheads dann an,
wenn kein Zielcode ausgeführt wird. Das
Hochladen von Datenwerten in ein Beobachtungsfenster nach Ausführung eines Software-Breakpoints, oder das Herunterladen
einer neuen Zielcode-Version erfolgen jeweils,
wenn kein Zielcode ausgeführt wird.
Im Vergleich zu einer Simulation, die getrennt
von der Ziel-Hardware abläuft, sind die Funktionen eines Run-Time-Monitors ein großer
Fortschritt. Weil der Run-Time-Monitor aber
66
Circuit-Debuggern kann sich der EmbeddedProzessor selbst emulieren.
Beispiel für die Implementation eines
In-Circuit Debuggers
Der MPLAB-ICD (In-Circuit-Debugger) ist ein
leistungsfähiges und kostengünstiges RunTime Entwicklungswerkzeug (Bild 2). Dieses
Werkzeug beruht auf den PIC16F877 8-bit
Flash-Mikrocontrollern; es läßt sich für Entwicklungsarbeiten bei dieser Bauteilfamilie
und anderen Microchip Mikrocontrollern aus
der PIC16CXX Familie verwenden. Zusammen
mit dem In-Circuit Serial Programming (ICSP)Protokoll ermöglicht diese Funktion eine
kosteneffektive In-Circuit Flash-Programmierung und das Debuggen über die graphische
Bedienerschnittstelle der integrierten MPLAB-
http://www.elektronik-industrie.de
Entwicklungsumgebung. Das Werkzeug erlaubt das Bearbeiten von Quellcode mit Variablenüberwachung, Einzelschritt-Codeausführung und Breakpointdefinitionen. Mit Programmausführung bei voller Geschwindigkeit
kann man die Hardware in Echtzeit überprüfen.
Der MPLAB-ICD dient auch als Programmer für
die PIC16F87X Familie mit Flash-Speicher.
Der modular aufgebaute In-Circuit-Debugger
besteht aus drei Grundkomponenten: dem
ICD-Modul, dem ICD-Header und dem DemoBoard. Die MPLAB-Softwareumgebung ist
über die serielle Schnittstelle mit dem ICDModul verbunden. Unter Kontrolle von MPLAB
kann das Modul über das ICSP-Protokoll das
PIC16F87X-Ziel programmieren oder Befehle
an das Bauteil ausgeben. Dieses Protokoll wird
über ein ca. 20 cm langes sechspoliges Kabel
mit Modularsteckern und -buchsen übertragen. Für einen direkten Anschluß an das ICDModul läßt sich eine Modularbuchse in die
Zielleiterplatte integrieren, oder man nutzt
den ICD-Header zum Anschluß an einen DIPSockel. Der ICD-Header enthält ein PIC16
F877-Ziel, eine Modularbuchse zum Anschluß
an das ICD-Modul sowie DIP-Stecker mit 40
und 28 Pins zum Einstecken in die Zielleiterplatte. Der Anwender kann das ICD in seine
eigene, spezielle Hardware einstecken oder
das mitgelieferte Demo-Board verwenden.
Dieses Board enthält DIP-Sockel mit 40 und 28
Pins zur Aufnahme eines Bauteils oder des
ICD-Headers. Zusätzlich enthält die Baugruppe
LEDs, DIP-Schalter, ein analoges Potentiometer
und einen Bereich zum Aufbau eigener Schaltungen. Auch wenn noch keine eigene Hardware bereitsteht, ist eine sofortige Microchip
Mikrocontroller-Prototypenentwicklung und
eine Evaluation des MPLAB-ICD mit dem mitgelieferten Board möglich. Das komplette
MPLAB-ICD
Hardware-Entwicklungssystem
mit der gratis enthaltenen MPLAB Host-Software ist ein komfortables, preisgünstiges RunTime-Entwicklungswerkzeug.
MPLAB-ICD Run-Time-Betrieb
Zusammen mit der Targetfirmware wird der
Debugging-Kernel über die ICSP-Schnittstelle
heruntergeladen. Nach einem Einzelschrittbetrieb oder nach Eintreffen eines Halt-Befehls
vom Host aktiviert ein nichtmaskierbarer Interrupt den Kernel, sobald der Programmzähler
eine zuvor angewählte Hardware-BreakpointAdresse erreicht. Wie bei allen Interrupts wird
dabei die Wiedereintrittsadresse in den Stack
eingefügt. Bei einem Reset wird das Breakpoint-Register auf den Wert des Resetvektors
gesetzt, sodaß der Kernel sofort aktiviert wird,
wenn das Bauteil aus dem Reset heraus hochfährt. Unmittelbar nach dem Herunterladen
von Daten gibt das ICD-Modul einen ResetBefehl an das PIC16F877-Ziel aus. Damit wird
der Kernel nach einem Download-Befehl aktiviert und die Kontrolle geht an die auf dem
elektronik industrie 12 – 1999
SYSTEMS ENGINEERING
Entwicklungssysteme
Burn&Learn
SoftwareSimulation
In-CircuitSimulation
In-CircuitEmulation
In-CircuitDebugger
Code-Ausführung in Echtzeit
Ja
Nein
Nein
Ja
Ja
Geringe Kosten
Ja/Gratis
Ja/Günstig/Gratis
Ja/Günstig
Nein
Ja/Günstig
Komplette
Implementation von
Peripheriebauteilen
Ja
Nein/Begrenzt
Ja/Begrenzt
Ja
Ja
Automatisches
Herunterladen eines
neuen Programms
Nein
Ja
Ja
Ja
Ja
Keine Verringerung
der Zahl der Target-I/O-Pins
beim Debugging
Ja
Ja/Manchmal
Ja/Manchmal
Ja
Nein
Verkabelung mit ZielSystem
Keine
Keine
Komplex
Komplex
Einfach
Betrachten und
Modifizieren von RAM und
Peripherieschaltungen
Nein
Ja
Ja/Begrenzt
Ja
Ja
Benötigte Ressourcen
für das Debugging
Keine
Keine
Serieller Port,
einige I/O-Pins
Keine
Zwei I/Os oder
weniger, sehr
wenig RAM für
Programm- und
Datenspeicher
Einfacher Anschluß
des Debuggers
an das Target
Keine
Keine
Nein/Komplex
Nein/Komplex
Ja
Real-Time Trace-Puffer
Keiner
Nein/Begrenzt
Nein/Begrenzt
Ja
Nein
Einzelschrittbetrieb
Nein
Ja
Ja
Ja
Ja
Hardware-Breakpoints
Keine
Ja/Unbegrenzt
Einer/Unbegr.
Einer/Unbegr.
Ja/Einer
Tabelle 1: Gegenüberstellung der verschiedenen Debugmöglichkeiten
Host laufende MPLAB-Umgebung über. Nun
läßt sich der Zielprozessor nach Wunsch steuern. Alle Register im RAM, wie z.B. Programmzähler und andere Sonderfunktionsregister
lassen sich modifizieren oder abfragen. Man
kann im Einzelschrittbetrieb arbeiten, einen
Breakpoint setzen, animieren oder mit der Programmausführung in voller Geschwindigkeit
beginnen. Unmittelbar beim Anhalten der Programmausführung wird die letzte Programmzähleradresse vor Aktivierung des Kernels
abgespeichert. Damit kann MPLAB im Quellcode die Stelle anzeigen, an der die Ausführung angehalten wurde. Sobald der Anwender den Target-Host weiterlaufen läßt,
führt der Kernel-Code einen "return from
interrupt" - Befehl aus, und die Codeausführung läuft ab der aus dem Hardware-Stack
entnommenen Adresse weiter.
elektronik industrie 12 – 1999
Anforderungen für die HardwareUnterstützung
Die erforderlichen Hardwareschaltungen bestehen im wesentlichen aus dem BreakpointAdressregister und -komparator sowie etwas
Logik für den Einzelschrittbetrieb bzw. zur
Erkennung der asynchronen Befehle vom
Host. Die ICSP-Schnittstelle für die Programmierung des Bauteils ist bereits vorhanden. Bei
Nutzung dieses Kanals für das In-CircuitDebugging dürfen diese I/O-Pins nicht für andere Run-Time-Funktionen verwendet werden.
Tabelle 1 faßt die wichtigsten Funktionen von
Emulatoren, Simulatoren und In-circuitDebuggern zusammen. Schon mit den grundlegenden Run-Time- Funktionen eines In-circuit Debuggers – Einzelschritt- und Echtzeitsausführung von Code mit Variablenüberwachung – kann man bei vielen Designs gute
Ergebnisse erzielen, bei denen man früher
einen Emulator hätte einsetzen müssen. Inve-
stiert man von Anfang an in die richtigen Entwicklungswerkzeuge, so kann man schnellere
Entwicklungs- und Debuggingzeiten erreichen.
551
John Andrews und John Day sind Senior Field
Applications Engineers der Firma Microchip Technology Inc., Chandler, AZ, USA.
http://www.elektronik-industrie.de
67