|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese
ENZYKLOPÄDIE DER FUNKELEKTRONIK UND ELEKTROTECHNIK Debuggen von Mikrocontrollern mithilfe eines ROM-Emulators. Enzyklopädie der Funkelektronik und Elektrotechnik
Lexikon der Funkelektronik und Elektrotechnik / Mikrocontroller Die Komplexität der Entwicklung und des Debuggens des Arbeitsprogramms eines elektronischen Geräts, das einen Mikroprozessor enthält, bestimmt oft die Kosten seiner Entwicklung insgesamt. Bei Mikrocontrollern (MCUs), die Speicher und einige Peripheriegeräte integrieren, ist dies besonders ausgeprägt. Eines der Tools, das das Debuggen erheblich erleichtert, ist der in [1] beschriebene ROM-Emulator. Dieser Artikel beschreibt die Technologie für die Arbeit damit. Die Debugging-Funktionen sind nicht auf die beschriebenen Techniken beschränkt. Dieser Prozess ist, wie Design im Allgemeinen, gewissermaßen eine Kunst: Jeder kreiert „seine eigene Musik“ für dasselbe Instrument. Wir sind den Lesern dankbar, die ihre ursprünglichen Tools und Methoden zum Debuggen von MK-Programmen teilen. Die Komplexität und Arbeitsintensität des Prozesses zum Debuggen von MK-Software wird durch folgende Faktoren bestimmt [2]:
Herkömmliche Testgeräte (z. B. ein Oszilloskop) können zum Debuggen von MCUs nur bedingt verwendet werden. Die einfachste (und gleichzeitig ineffektivste) Methode des Debuggens ist die „Trial-and-Error-Methode“: Laden eines Programms in ein umprogrammierbares Nur-Lese-Speichergerät (RPM), Ausführen des Versuchs, Erkennen und Korrigieren von Fehlern im Programm und Hardware, Löschen des ROM, erneutes Laden des Programms usw. d. Die Prozesse des Löschens und Schreibens von Daten auf den EEPROM-Chip nehmen viel Zeit in Anspruch und schlagen nach einer bestimmten Anzahl von Neuprogrammierungszyklen vollständig fehl. Durch wiederholtes Ein- und Ausbauen der Mikroschaltung verringert sich die Zuverlässigkeit der elektrischen Kontakte im ROM-Sockel. Es besteht praktisch keine Möglichkeit, Debugging-Informationen über das System zu erhalten. Derzeit werden Mikrocontroller am häufigsten mit Cross-Tools auf Basis eines Personalcomputers debuggt. Dies ermöglicht eine minimale Ablenkung der MK-Ressourcen. Das zu debuggende Gerät ist, wie in der Abbildung dargestellt, über ein Tool, beispielsweise einen ROM-Emulator, mit dem Computer verbunden. Ein solcher Komplex ermöglicht es Ihnen, ein Programm herunterzuladen und zu bearbeiten, Testmodule darin einzugeben, bestimmte Informationen über das System zu erhalten und vieles mehr, worauf wir weiter unten eingehen. Obwohl ROM-Emulatoren nicht das einzige oder leistungsstärkste Debugging-Tool sind, erfreuen sie sich dennoch großer Beliebtheit. Ihre „Langlebigkeit“ erklärt sich aus ihrer Unabhängigkeit vom MK-Typ (nur die Fähigkeit, mit externem Programmspeicher zu arbeiten ist erforderlich), dem Echtzeitbetrieb, dem niedrigen Preis und der Zugänglichkeit für eine breite Palette von Geräteentwicklern und Funkamateuren. Betrachten wir die Technologie des Programm-Debuggens mit einem ROM-Emulator am Beispiel der Mikrocontroller der MCS-51-Familie (8031, 8051, 80C31, 80C51. KR1816BE31, KR1816BE51, KR1830BE31, KR1830BE51 usw.). Zu Beginn des Debuggens ist es notwendig, die Funktionsfähigkeit der Systemhardware und des MK selbst zu überprüfen. Hierzu können Sie die „kostenlosen Account“-Tests [3] nutzen. die darin bestehen, alle möglichen Codekombinationen auf den Leitungen der MK-Ports zu durchsuchen. Während des Tests werden die Portleitungen in den Ausgangszustand versetzt. Überprüfen Sie daher zunächst anhand des Schaltplans des zu debuggenden Geräts, ob sie nicht auf die Ausgänge anderer Elemente geladen werden. Trennen Sie solche Lasten vorübergehend, sofern vorhanden. Laden Sie den ROM-Emulator mit NOP-Befehlscodes (No Operation) innerhalb des gesamten Adressraums von MK-Programmen. Für MCS-51 ist dies Code 00Н. Beim Ausführen eines solchen „Programms“ durchsucht der Mikrocontroller nacheinander alle Programmspeicheradressen. Überprüfen Sie die Signale von ALE, PME und den Ports P0, P2 mit einem Oszilloskop. Die Oszillogramme auf den Portleitungen müssen den Zeitdiagrammen des Binärzählers entsprechen, unter Berücksichtigung der Multiplexierung des Low-Byte der Adresse und der Daten auf P0. Überprüfen Sie als Nächstes die Ports P1 und R1, indem Sie das in Tabelle 00 angegebene Testprogramm in den ROM-Emulator laden. 0. Es gibt eine Folge von Codes von XNUMXH bis XNUMXFFH auf den Leitungen der angegebenen Ports aus und simuliert so einen XNUMX-Bit-Binärzähler. Wenn die Oszillogramme den erforderlichen entsprechen, stellen Sie die von den Ports getrennten Lasten wieder her und fahren Sie mit dem Debuggen des Arbeitsprogramms des MK fort. Denken Sie daran, dass Sie gleichzeitig die Software- und Hardwareteile des Systems debuggen, und vergessen Sie nicht, die Signale an den Kontrollpunkten regelmäßig mit einem Oszilloskop zu überwachen. Die Diskrepanz zwischen der Art der Signale und Ihren Vorstellungen darüber ist Anlass für ernsthafte Überlegungen und zusätzliche Kontrollen.
Um die Entwicklung und das Debuggen zu erleichtern, sollten Sie sich an das Baukastenprinzip der Programmierung halten, d. h. das MK-Programm entsprechend der Funktionalität in Teile unterteilen. Dadurch können einzelne Module einfach verschoben und bei Bedarf in anderen Projekten verwendet werden. Das Modul, an das die Steuerung nach dem Einschalten oder Zurücksetzen des MK übertragen wird, wird als Hauptmodul oder Hauptmodul bezeichnet. Sie sollten die Kontrolle über einen Sprungbefehl und nicht über einen Unterprogrammaufruf an den Programmeinstiegspunkt übergeben, um den Stapel nicht mit der Rücksprungadresse zu überladen. Um unerwartete Programmergebnisse zu vermeiden, weisen Sie jeder Variablen unbedingt einen Anfangswert zu, bevor Sie sie zum ersten Mal verwenden. In manchen Fällen kann es erforderlich sein, Peripheriegeräte zu initialisieren. Der Initialisierungsblock wird am Anfang des Hauptprogrammmoduls platziert. Eine ungefähre Ansicht des Hauptsoftwaremoduls zu Beginn des Debuggens ist in der Tabelle dargestellt. 2. Es enthält nur den Einstiegspunkt zum Programm und den Exit-Handler. Obwohl ein solcher Ausgang in Mikrocontrollersystemen äußerst selten verwendet wird, muss er für die korrekte Bewältigung von Notfallsituationen bereitgestellt werden. Im betrachteten Beispiel durchläuft das Programm nach Abschluss der Arbeiten eine „Schleife“. Dieser Zustand wird nur durch einen Neustart des Systems mit einem Hardware-Reset-Signal wieder verlassen.
Während des Debuggens werden dem Hauptmodul weitere Softwaremodule hinzugefügt, sobald diese bereit sind. Die Reihenfolge, in der sie verbunden und debuggt werden, spielt eine wichtige Rolle. Sie sollten mit den Treibern der Informationsausgabegeräte (Display, Digital-Analog-Wandler usw.) beginnen und deren Aufrufe im Hauptmodul platzieren. Anschließend werden die Treiber der übrigen Peripheriegeräte und Datenverarbeitungsroutinen debuggt und erst danach die gemeinsame Funktion aller Softwaremodule überprüft. Wenn eine alphanumerische Anzeige vorhanden ist, wird deren Treiber zuerst debuggt und in Zukunft zur Anzeige von Debugging-Informationen verwendet, beispielsweise dem Inhalt des internen Datenspeichers des MK. Wenn ein ROM-Emulator so verwendet wird, dass die darin enthaltenen Informationen sowohl vom Steuercomputer als auch vom zu debuggenden Gerät geschrieben und gelesen werden können, kann der MK Debugging-Daten im freien Speicherbereich des ROM-Emulators und der Steuerung ablegen Der Computer liest sie und zeigt sie auf seinem Display an. Um beispielsweise den Inhalt des internen Daten-RAM des MK auszugeben, verbinden Sie dessen Schreibsignalausgang mit dem externen Datenspeicher (WR) mit dem Schreibsignaleingang des ROM-Emulators und verwenden Sie das in der Tabelle angegebene Unterprogramm. 3. Es wird davon ausgegangen, dass die Programmspeichergröße des zu debuggenden Geräts 32 KB nicht überschreitet. Daher beginnen die im Emulatorspeicher abgelegten Debugging-Informationen bei Adresse 8000H. Der Inhalt der Register R0 und R1 wird separat gesendet, da er später im Unterprogramm zur Organisation der Schleife verwendet wird. Nach Ausgabe der Debugging-Informationen wird das MK-Programm angehalten, der Inhalt der Speicherzellen des 8000H-807FH ROM-Emulators wird vom Steuerrechner gelesen, angezeigt und analysiert. Auf ähnliche Weise können die Inhalte aller programmgesteuert zugänglichen MK-Register angezeigt werden.
Wenn Sie mit dem Debuggen des Treibers eines Peripheriegeräts beginnen, trennen Sie vorübergehend die vom Mikrocontroller erzeugten Steuersignale davon, um einen möglichen Ausfall des Geräts aufgrund von Fehlern im Programm zu vermeiden. Wenn der Vorgang einmalig ist, „schleifen“ Sie ihn und programmieren Sie bei Bedarf das Oszilloskop-Synchronisationssignal. Debuggen Sie den Treiber, indem Sie die vom MC erzeugten Signale mit einem Oszilloskop überwachen. Nachdem Sie sichergestellt haben, dass die Zeitdiagramme der Steuersignale den erforderlichen entsprechen, schließen Sie das Peripheriegerät an und fahren Sie mit dem Debuggen des Treibers auf echter Hardware fort. Entfernen Sie abschließend Debugging-Elemente aus dem Softwaremodul und überprüfen Sie dessen Funktionsfähigkeit in seiner endgültigen Form. Die Verwendung gemeinsam genutzter MK-Ressourcen durch verschiedene Module führt häufig dazu, dass das debuggte Programm nicht mehr funktioniert, wenn ein weiteres Unterprogramm hinzugefügt wird. Stellen Sie daher nach dem Debuggen des nächsten Moduls sicher, dass alle zuvor debuggten Treiber und Unterprogramme weiterhin ordnungsgemäß funktionieren. Wenn Ihr Programm Interrupts verwendet, deaktivieren Sie diese nur, wenn dies unbedingt erforderlich ist. Ein debuggtes Modul sollte nicht aus dem Programm entfernt werden, auch wenn es im Moment nicht benötigt wird. Wenn der MK einfriert, ist die folgende Methode zur Fehlerlokalisierung hilfreich: Geben Sie Kontrollpunkte in das Programm ein, die sukzessive steigende Zahlen auf dem Display anzeigen. Nach dem Einfrieren zeigt das Display die Nummer an, die dem letzten erfolgreich passierten Kontrollpunkt entspricht. Wenn mehrere dieser Punkte in einer Endlosschleife gefangen sind, ändern sich die Zahlen auf dem Display schnell. Um festzustellen, welche Punkte in der Schleife enthalten sind, müssen Sie die Änderung der Zahlen künstlich verlangsamen, indem Sie bei der Ausgabe jedes einzelnen Punktes eine Softwareverzögerung einstellen, beispielsweise in Form einer Leerlaufschleife. Verfügt das zu debuggende System nicht über ein eingebautes Display, können Informationen über den freien Speicherbereich des ROM-Emulators auf dem Display des Steuerrechners angezeigt werden. Nachdem wir alle Gerätetreiber debuggt haben, beginnen wir mit dem Debuggen anderer Routinen. Wenn einer von ihnen einen komplexen Algorithmus zur Verarbeitung oder Konvertierung von Daten implementiert, liefert die Anzeige eines oder mehrerer Zwischenvariablenwerte häufig keine ausreichenden Informationen für die Fehleranalyse. Schreiben von Debugging-Informationen des erforderlichen Volumens in den freien Speicherbereich des ROM Der Emulator wird hier helfen, Schwierigkeiten zu überwinden. Nachdem Sie den normalen Betrieb aller Softwaremodule erreicht haben, können Sie sie gemeinsam debuggen. Die dabei auftretenden Schwierigkeiten lassen sich in zwei Gruppen einteilen. Das erste umfasst die Probleme der gemeinsamen Nutzung gemeinsamer Ressourcen des Mikrocontrollers: arithmetisch-logische Einheit, Datenspeicher, Eingabe-Ausgabe-Ports. Die zweite bezieht sich auf den Betrieb von Mikrocontroller-Geräten in Echtzeit. Echtzeitsysteme sind in der Regel Multithread-Systeme. Mehrere Softwareaufgaben (Threads) laufen parallel, interagieren miteinander und nutzen gemeinsame Ressourcen. Aber der MC löst aufgrund seiner Struktur zu jedem Zeitpunkt nur einen von ihnen und wechselt unter Berücksichtigung der Priorität abwechselnd zu anderen. Konflikte zwischen Aufgaben entstehen sowohl aufgrund fehlender Ressourcen als auch aufgrund mangelnder Zeit für die Datenverarbeitung. Achten Sie daher besonders auf die MC-Ressourcen, die in Softwaremodulen verwendet werden, und überwachen Sie häufig Änderungen in ihrem Status, indem Sie Debugging-Informationen anzeigen. Versuchen Sie, die Anzahl globaler Variablen zu reduzieren und sie nach Möglichkeit durch lokale zu ersetzen. Überwachen Sie den Status des Stapels. Schätzen Sie die Ausführungszeit kritischer Programmabschnitte ab und testen Sie das System auf verschiedene Werte von Eingangssignalen, die in der Praxis möglich sind. Mit einem ROM-Emulator können Sie auch ein Programm debuggen, das für die Arbeit im internen Speicher des MK konzipiert ist, wenn Sie es vorübergehend im externen Programmspeicher ablegen. Da in diesem Fall die Ports P0 und P2 mit der Bedienung des externen Speichers beschäftigt sind, werden P0 und P2 durch I/O-Ports ersetzt, die als externe Datenspeicherzellen adressiert sind, wenn die verbleibenden freien I/O-Leitungen des MK nicht ausreichen. Sie werden nach Standardschaltungen angeschlossen, wobei Triggerregister zur Erhöhung der Anzahl der Ausgangsleitungen und Elemente mit drei Ausgangszuständen zur Erhöhung der Anzahl der Eingangsleitungen verwendet werden. Nachdem Sie das System mit einem Emulator debuggt haben, entfernen Sie Debugging-Elemente daraus, schreiben Sie das Programm in das ROM (oder in den internen Programmspeicher des MK) und überprüfen Sie den Betrieb des Geräts in seiner endgültigen Form. Literatur
Autoren: G.Vydolob, V.Samoylov, Moskau (Zelenograd)
Eine neue Möglichkeit, optische Signale zu steuern und zu manipulieren
05.05.2024 Primium Seneca-Tastatur
05.05.2024 Das höchste astronomische Observatorium der Welt wurde eröffnet
04.05.2024
▪ Das am weitesten entfernte Objekt im Sonnensystem ▪ Die globale Erwärmung wird die USA besonders hart treffen
▪ Abschnitt der Website Wissenschaftliches Kinderlabor. Artikelauswahl ▪ Artikel Der historische Weg ist nicht der Bürgersteig des Newski-Prospekts. Populärer Ausdruck ▪ Artikel Wie schaffen es Wolken, am Himmel zu bleiben? Ausführliche Antwort ▪ Artikel Arbeiten mit Handwinde und Handwinde. Standardanweisung zum Arbeitsschutz ▪ Artikel Eine einfache Piepserschaltung. Enzyklopädie der Funkelektronik und Elektrotechnik ▪ Artikel Das Verschwinden des Getränks. Fokusgeheimnis
Startseite | Bibliothek | Artikel | Sitemap | Site-Überprüfungen
www.diagramm.com.ua |
Siehe andere Artikel Abschnitt 
Neueste Nachrichten aus Wissenschaft und Technik, neue Elektronik:
Alle Sprachen dieser Seite