|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese
ENZYKLOPÄDIE DER FUNKELEKTRONIK UND ELEKTROTECHNIK Mikrocontroller für Einsteiger und Fortgeschrittene. Enzyklopädie der Funkelektronik und Elektrotechnik
Lexikon der Funkelektronik und Elektrotechnik / Mikrocontroller ERSTES TREFFEN Zunächst ein paar Worte für diejenigen, denen das Thema des Zyklus, seinem Titel nach zu urteilen, a priori uninteressant oder „fremd“ erscheint. Vielleicht haben Sie in Ihren Entwürfen noch keine Mikrocontroller verwendet (im Folgenden der Kürze halber MK genannt) und denken, dass Sie in absehbarer Zeit darauf verzichten können. Möglicherweise gehen Sie auch davon aus, dass der Aufbau eines Mikrocontrollersystems zur Lösung Ihres Problems zu aufwändig und wirtschaftlich unrentabel wäre. Beeilen Sie sich nicht: Speziell für Sie möchten wir ein paar Fakten und Statistiken liefern. Nehmen wir zum Beispiel den nächsten Verwandten von MK – einen Personal Computer – und vergleichen die Intensität seiner Nutzung. Laut dem Analystenhaus Loewenbaum & Co. Inc. (USA) erreichte die Zahl der weltweit auf den Markt gebrachten Personalcomputer im Jahr 1997 etwa 20 Millionen Einheiten. Stimmen Sie zu, das ist viel. Stellen Sie sich nun vor, dass diese gigantische Zahl nur 0,2 % der weltweiten MK-Produktion ausmacht. Nach Angaben des Analyseunternehmens IC Insights Inc. (USA) Der Weltmarkt hat 1998 mehr als 13,5 Milliarden davon aufgenommen! Die Schlussfolgerung liegt auf der Hand. Wenn es auch heute noch schwierig ist, einen Bereich menschlicher Tätigkeit zu finden, in dem der Computer nicht effektiv eingesetzt werden würde, was können wir dann über MK sagen? Warum sind sie so beliebt und buchstäblich unverzichtbar geworden? Die Antwort liegt in der Struktur des Mikrocontrollers. Als erste Annäherung an die Definition dieses Konzepts können wir davon ausgehen, dass der MC ein Computer ist, der sich in einem einzelnen Mikroschaltkreis befindet. Daher seine wichtigsten attraktiven Eigenschaften: kleine Abmessungen, Verbrauch, Preis; hohe Leistung, Zuverlässigkeit und Anpassungsfähigkeit an vielfältige Aufgaben. MK unterscheidet sich von einem Mikroprozessor dadurch, dass er neben der Zentraleinheit (CPU) Speicher und zahlreiche Ein-/Ausgabegeräte enthält: Analog-Digital-Wandler, serielle und parallele Informationskanäle, Echtzeit-Timer, Impulsbreite Modulatoren (PWM), programmierbare Impulsgeneratoren usw. In seinem Aufbau und Funktionsprinzip unterscheidet sich der MK im Wesentlichen nicht von einem Personal Computer. Daher sind die Wörter Mikrocontroller und Mikrocomputer synonym. Der erste Begriff (vom englischen Wort control – verwalten) ist jedoch gebräuchlicher, da er seinen Hauptzweck widerspiegelt – die Verwendung in automatischen Steuerungssystemen, die in eine Vielzahl von Geräten eingebaut sind: Kreditkarten, Kameras, Mobiltelefone, Stereoanlagen, Fernseher, Videorecorder und Camcorder, Waschmaschinen, Autos, Mikrowellenherde, Einbruchmeldeanlagen, Zündsysteme für Benzinmotoren, elektrische Antriebe von Lokomotiven, Kernreaktoren und vieles mehr. Eingebettete Steuerungssysteme sind zu einem solchen Massenphänomen geworden, dass sich tatsächlich ein neuer Wirtschaftszweig namens Embedded Systems (eingebettete Systeme – Englisch) gebildet hat. Derzeit werden weltweit Tausende von MK-Sorten produziert. Sie werden in Gehäusen mit 8 bis 356 Pins geliefert, arbeiten bei Temperaturen von -55 bis +125 °C bei Frequenzen von 32 kHz bis 200 MHz, können mit einer Versorgungsspannung von 1,2 V betrieben werden und verbrauchen dabei einen Strom von nicht mehr als einigen Mikroampere . . Auch die Preise der Produkte sinken ständig. Einige Acht-Bit-MCUs kosten bereits heute nicht mehr als 50 Cent, was mit den Kosten eines „Hard Logic“-Chips vergleichbar ist. All dies hat dazu geführt, dass es heute immer schwieriger wird, einen Bereich menschlicher Tätigkeit zu finden, in dem MC keine Anwendung finden würde, und der Prozess ihrer Verbreitung einen lawinenartigen Charakter hat. Wir hoffen, dass die oben genannten Fakten Sie bereits auf eine respektvolle Haltung gegenüber der Hauptfigur unserer Geschichte vorbereitet haben. Tatsächlich ist MC zu einem globalen Ereignis geworden, das fast alle Arten menschlicher Aktivitäten erfasst. Was hat dazu geführt, dass die Popularität dieser Produkte, die vor etwas mehr als 25 Jahren auf den Markt kamen, so schnell zunahm? Was sind diese Geräte und was sind ihre Fähigkeiten und Aussichten? Wenn Sie MC oder darauf basierende Systeme in Ihren Aktivitäten noch nicht eingesetzt haben, dann. Vielleicht ist es an der Zeit, darüber nachzudenken? Und wenn Sie sich für die Anwendung von MK entscheiden, wie sollte dann die Reihenfolge Ihrer Aktionen sein? Welche Schwierigkeiten erwarten Sie möglicherweise, was kann Ihnen auf dem Weg helfen? Diese Fragen versuchen wir in der vorgeschlagenen Artikelserie zu beantworten. MOORES GESETZ UND DER ERSTE MK Bereits 1965 machte Gordon Moore, einer der zukünftigen Gründer der mächtigen Intel Corporation, auf eine interessante Tatsache aufmerksam. Nachdem er das Leistungswachstum von Speicherchips aufgezeichnet hatte, entdeckte er ein interessantes Muster: Alle 18 bis 24 Monate erschienen neue Chipmodelle, deren Kapazität sich jedes Mal ungefähr verdoppelte. Wenn dieser Trend anhält, so G. Moore, wird die Leistung von Computergeräten in relativ kurzer Zeit exponentiell zunehmen. Die Vorhersage von G. Moore wurde anschließend hervorragend bestätigt, und das von ihm entdeckte Muster wird heute mit erstaunlicher Genauigkeit beobachtet und bildet die Grundlage für zahlreiche Prognosen zum Produktivitätswachstum. In den 28 Jahren, die seit der Einführung des 4004-Mikroprozessors (1971) vergangen sind, hat sich die Anzahl der Transistoren auf einem Chip um mehr als das 12-fache erhöht: von 000 auf 2 im Sorrettué-Chip. Nun, 1976 führte die exponentielle Entwicklung der Halbleitertechnologie zur Entwicklung des ersten MK-8048 durch Intel. Zusätzlich zur CPU umfasste er Programmspeicher, Datenspeicher, einen Acht-Bit-Timer und 27 E/A-Leitungen. Heute ist der 8048 bereits Geschichte, aber das nächste Produkt, das 1980 von Intel herausgebracht wurde, ist immer noch am Leben. Das ist MK 8051. ARCHITEKTUR MK 8051 Dieser MK kann als klassisches Modell angesehen werden, nach dessen Vorbild und Ähnlichkeit später viele andere Produkte geschaffen wurden. Sein Blockdiagramm ist in Abb. dargestellt. 1. CPU – der Hauptknoten des MK. Es ist mit einem so wichtigen Konzept wie einem Befehlssystem verbunden.
Der Befehlssatz ist ein einzigartiger Satz binärer Codes, die für eine bestimmte CPU spezifisch sind und eine Liste aller ihrer möglichen Operationen definieren. Jeder dieser Codes definiert eine Operation und wird als Operationscode oder Befehl bezeichnet. Je mehr Codes im Befehlssatz verwendet werden, desto mehr Operationen kann die CPU ausführen. MK 8051 ist 8-Bit, seine Opcodes sind also 256 Bit groß. Theoretisch kann es insgesamt 8051 Acht-Bit-Opcodes geben. 255 verwendet XNUMX. Abhängig von der Anzahl der verwendeten Operationscodes werden die Unterrichtssysteme in zwei Gruppen unterteilt: CISC und RISC. Der Begriff CISC bedeutet ein komplexes Befehlssystem und ist eine Abkürzung der englischen Definition von Complex Instruction Set Computer. Ebenso bedeutet der Begriff RISC einen reduzierten Befehlssatz und stammt vom englischen Reduced Instruction Set Computer. Das Befehlssystem MK 8051 kann dem Typ C15C zugeordnet werden. Trotz der weit verbreiteten Verwendung dieser Konzepte muss jedoch anerkannt werden, dass die Namen selbst nicht den Hauptunterschied zwischen den CISC- und RISC-Befehlssystemen widerspiegeln. Die Hauptidee der RISC-Architektur ist eine sorgfältige Auswahl solcher Kombinationen von Operationscodes, die in einem Zyklus des Taktgenerators ausgeführt werden könnten. Der Hauptvorteil dieses Ansatzes ist eine deutliche Vereinfachung der Hardware-Implementierung der CPU und die Möglichkeit, ihre Leistung deutlich zu steigern. Die Umsetzung eines solchen Ansatzes war zunächst nur durch eine deutliche Reduzierung des Befehlssatzes möglich, daher entstand der Name RISC. Beispielsweise umfasst der Befehlssatz des MK der Microchir PIC-Familie nur 35 Befehle und kann als RISC klassifiziert werden. Offensichtlich müssen im allgemeinen Fall mehrere Anweisungen der RISC-Architektur einer Anweisung der CISC-Architektur entsprechen. Allerdings überwiegen die Leistungsgewinne der RISC-Architektur in der Regel die Verluste durch den weniger effizienten Befehlssatz, was zu einer höheren Effizienz des RISC-Systems als Ganzes im Vergleich zum CISC führt. So. Der schnellste Befehl MK 8051 wird in 12 Zyklen ausgeführt. Auch wenn für jeden Befehl drei RISC-Controller-Befehle ausgeführt werden müssen, sorgt die RISC-Architektur am Ende für eine vierfache Leistungssteigerung. Nebenbei ermöglicht die RISC-Architektur die Lösung einer Reihe von Problemen. Tatsächlich nimmt mit der Vereinfachung der CPU die Anzahl der für ihre Implementierung erforderlichen Transistoren ab, daher nimmt die Fläche des Kristalls ab. Dies führt zu einer Reduzierung der Kosten und des Stromverbrauchs. An dieser Stelle könnte man ausrufen: Der RISC-Architektur gehört die Zukunft! Allerdings verschwimmt die Grenze zwischen diesen beiden Konzepten zunehmend. Zum Beispiel. Die MCUs der AVR-Familie von Atmel verfügen über einen Befehlssatz mit 120 Befehlen, der dem CISC-Typ entspricht. Allerdings werden die meisten davon in einem Zyklus ausgeführt, was ein Markenzeichen der RISC-Architektur ist. Heute ist es allgemein anerkannt, dass das Hauptmerkmal der RISC-Architektur die Ausführung von Befehlen in einem Zyklus des Taktgenerators ist. Die Anzahl der Befehle an sich spielt keine Rolle mehr. Der Taktgenerator erzeugt Impulse, um den Betrieb aller Knoten des Geräts zu synchronisieren. Die Frequenz ihrer Wiederholung kann durch einen Quarzresonator oder eine an die Ausgänge des MK angeschlossene RC-Schaltung eingestellt werden. In einigen MKs ist ein Taktgenerator-Betriebsmodus ohne den Einsatz externer Elemente vorgesehen. Dabei hängt die Frequenz der Taktimpulse von den Parametern des Kristalls ab, die bei seiner Herstellung ermittelt werden. ROM ist ein Nur-Lese-Speichergerät zum Speichern von Programmen. Daher wird dieser Speicher oft als Code- oder Programmspeicher bezeichnet. Bis vor kurzem gab es zwei Haupttypen von ROMs – maskierte und programmierbare. Informationen werden während des Herstellungsprozesses des MC mithilfe technologischer Vorlagen – Masken – in Masken-ROMs eingegeben. Es kann nach dem Ende des Produktionszyklus nicht mehr geändert werden. Solche ROMs werden nur in Fällen verwendet, in denen die Qualität des Programms außer Zweifel steht und bei diesem speziellen Programm ein großer Bedarf an MK besteht. Der Vorteil von Masken-ROMs sind die geringsten Kosten bei der Massenproduktion (ab mehreren tausend Stück). Programmierbare ROM-Informationen werden mit einem Gerät namens Programmierer geschrieben. Es gibt zwei Arten von MK mit solchen ROMs: einmalig und wiederholt programmierbar (umprogrammierbar). Die ersten erlauben, wie der Name schon sagt, nur eine einmalige Programmierung, danach ist es nicht mehr möglich, die Informationen zu löschen (MK mit OTP-Speicher – aus dem Englischen: One Time Programmable). Sie werden in Kleinserien (bis zu 1000 Stück) eingesetzt. wenn der Einsatz der Maske MK wirtschaftlich nicht gerechtfertigt ist. Wiederholt programmierbare Mikroschaltungen werden in MK mit ROM mit Löschung durch ultraviolette Strahlung (erhältlich in Gehäusen mit „Fenster“) und MK mit elektrisch umprogrammierbarem Speicher unterteilt. Der Nachteil von MC mit ROM mit Löschung durch ultraviolette Strahlung sind sehr hohe Kosten und eine relativ geringe Anzahl von Schreib-/Löschzyklen (hängt von der Gesamtdosis der Kristallbestrahlung ab und überschreitet normalerweise 15 ... 20 nicht). Derzeit erfreut sich eine neue Technologie zur Implementierung von ROM immer größerer Beliebtheit – Flash-Speicher. Sein Hauptvorteil ist dass es auf dem Prinzip der elektrischen Reprogrammierbarkeit basiert. d. h. es ermöglicht das mehrfache Löschen und Aufzeichnen von Informationen mithilfe von Programmierern. Die garantierte Mindestanzahl an Schreib-/Löschzyklen beträgt in der Regel mehrere Tausend. Dadurch wird der Lebenszyklus deutlich verlängert und die Flexibilität von MC-Systemen erhöht. da Sie damit Änderungen am MC-Programm sowohl in der Phase der Systementwicklung als auch während des Betriebs in einem realen Gerät vornehmen können. RAM ist ein Speicher mit wahlfreiem Zugriff, der zum Speichern von Daten verwendet wird. Daher wird dieser Speicher auch als Datenspeicher bezeichnet. Die Anzahl der Lese- und Schreibzyklen im RAM ist nicht begrenzt, jedoch gehen beim Abschalten der Versorgungsspannung alle Informationen verloren. Die Architektur des MK 8051 sieht die getrennte Nutzung von Programm- und Datenspeicher vor und heißt Harvard. Typischerweise wird diese Architektur verwendet, um die Systemleistung durch die Trennung der Zugriffspfade für Programm- und Datenspeicher zu verbessern. Beim 8051 wurde sie jedoch verwendet, um Programm- und Datenspeicher zu erreichen, die nicht die gleiche Größe erforderten. Der Gegenpol zu Harvard – die von Neumann-Architektur – beinhaltet die Speicherung von Programmen und Daten in einem gemeinsamen Speicher und ist am typischsten für Mikroprozessoren, die für den Einsatz in Computern entwickelt wurden. Ein Beispiel ist die x86-Mikroprozessorfamilie. Die Timer TO und T1 sind programmierbare 32-Bit-Timer/Zähler, die für die Ausführung verschiedener Funktionen programmiert werden können. Sie können zur genauen Bildung von Zeitintervallen, zum Zählen von Impulsen an den Ausgängen des MK, zum Bilden einer Impulsfolge und zum Takten des Transceivers eines seriellen Kommunikationskanals verwendet werden. Timer/Zähler sind in der Lage, Interrupt-Anfragen zu generieren, die CPU so zu schalten, dass sie sie bei Ereignissen bedient, und sie von der Notwendigkeit zu befreien, den Status der Timer regelmäßig abzufragen. Da die Hauptanwendung von MK in Echtzeitsystemen liegt, sind Timer/Zähler ihr unverzichtbares Element. In einigen Modifikationen erreicht die Anzahl der Timer XNUMX. Die serielle Schnittstelle ist ein Kanal für den Informationsaustausch zwischen dem MK und der Außenwelt. Solche Kommunikationskanäle beanspruchen eine minimale Anzahl von Kristallstiften und ermöglichen die Kommunikation über große Entfernungen bei minimalen Hardwarekosten. Der 8051 implementiert einen universellen asynchronen seriellen Transceiver (UART), der das RS-232C-Standardprotokoll unterstützt, wodurch die Kommunikation zwischen diesem MK und einem Personalcomputer organisiert werden kann. Neben RS-232C ist RS-485 das beliebteste Protokoll in der Welt der eingebetteten Systeme. I2C (bidirektionaler Zweidrahtbus). SPI (XNUMX-Draht-serielle Peripherieschnittstelle). Bitbus (serieller Steuerbus), CAN (Inter-Controller-Netzwerkschnittstelle), USB (universeller serieller Bus) und einige andere. Für fast jede Art von seriellem Kanal gibt es heute einen MK, der in seiner Zusammensetzung über einen entsprechenden seriellen Port verfügt. Parallele I/O-Ports sind ebenfalls ein wesentlicher Bestandteil jeder MCU. Normalerweise dienen sie der Kommunikation mit der unmittelbaren Umgebung – Sensoren und Aktoren. Ein wichtiges Merkmal der MK-Parallelanschlüsse ist die Möglichkeit, für die Ausführung mehrerer Funktionen programmiert zu werden. Beim 8051 können die Port-Pins P0 und P2 beispielsweise entweder als normale statische I/O-Register oder als Adress- und Datenbus zum Anschluss externer Geräte wie zusätzlichem Programmspeicher, Datenspeicher oder I/O-Geräten verwendet werden. Dies verleiht MK architektonische Flexibilität. Der RXNUMX-Port kann entweder als statisches I/O-Register verwendet werden oder spezielle Funktionen für den Betrieb eines seriellen Kanals, Timers, Interrupt-Controllers usw. ausführen. Durch die Neuprogrammierbarkeit können Sie alle Ausgänge des MC im entworfenen Gerät verwenden mit maximaler Effizienz. Das Interrupt-System ist einer der wichtigsten Teile von MK. Ein Merkmal von Echtzeitsystemen ist, dass für sie ein äußerst wichtiger Parameter die Reaktionszeit auf externe Ereignisse ist. Lassen Sie es uns anhand eines einfachen Beispiels erklären. Wenn Sie eine mathematische Berechnung auf einem Computer durchführen, führen Sie normalerweise ein Programm aus, das diese Berechnungen durchführen soll. Nachdem es in den Speicher des Computers geladen wurde, geben Sie die Problemstellung ein und warten auf das Ergebnis. Die Wartezeit ist in diesem Fall nicht von grundsätzlicher Bedeutung (natürlich im Rahmen des Zumutbaren) – der langsame Betrieb des Computers kann störend sein, hat aber keinen Einfluss auf das Ergebnis. Das Echtzeitsystem geht von einer ganz bestimmten, in der Entwicklungsphase berechneten Reaktionsgeschwindigkeit des Steuerungssystems auf externe Ereignisse aus. Verzögerungen über die kalkulierten hinaus sind hier einfach inakzeptabel – sie können katastrophale Folgen haben. Probleme der schnellen Reaktion auf Ereignisse werden durch die Organisation eines Interruptsystems gelöst. Dies bedeutet, dass für jedes dieser Ereignisse ein separater „Code“ entwickelt wird, der die Reaktion des MK darauf bildet. Dieses „Stück“ Code wird als Interrupt-Anforderungsroutine bezeichnet (aus Gründen der Kürze wird häufig der Begriff „Interrupt-Routine“ verwendet) und an einer bekannten Adresse im Programmspeicher abgelegt. Im Moment des Eintretens eines bestimmten Ereignisses wird ein entsprechendes Signal an den Eingang des Interrupt-Controllers gesendet. Letzteres ist ein Gerät, das eine Eins-zu-Eins-Entsprechung zwischen dem Eingangssignal über ein eingetretenes Ereignis und der Programmspeicheradresse herstellt, an der sich der Einstiegspunkt zur Interrupt-Anforderungsverarbeitungsroutine dieses Ereignisses befindet. Der Controller unterbricht die CPU-Ausführung des aktuellen Programms und leitet dessen Übergang zur Ausführung der Interrupt-Serviceroutine ein. Die Zeit, die vom Eintreten des Ereignisses bis zum Beginn der Ausführung des ersten Befehls der Interrupt-Routine verstrichen ist, wird als Reaktionszeit des MK auf das Ereignis bezeichnet. Nach Abschluss der Verarbeitung kehrt die CPU automatisch zur Ausführung des unterbrochenen Programms zurück. Eine weitere Funktion des Interrupt-Controllers besteht darin, Ereignisse zu priorisieren. Das Konzept der Priorität bedeutet, dass eine laufende Interrupt-Routine nur dann durch ein anderes Ereignis unterbrochen werden kann, wenn dieses eine höhere Priorität als das aktuelle hat. Andernfalls fährt die CPU mit der Verarbeitung eines neuen Ereignisses fort, nachdem sie die Verarbeitung des vorherigen Ereignisses abgeschlossen hat. Der Interrupt-Controller, der Teil des MK 8051 ist, verfügt über fünf Ereigniseingänge: zwei von externen Geräten, zwei von Timern und einer vom seriellen Kanal. Wenn sie über einen MK sprechen, erwähnen sie normalerweise immer die Familie, zu der er gehört. Eine Familie umfasst Produkte mit demselben Kern, worunter eine Reihe von Konzepten wie ein Befehlssystem, ein CPU-Betriebssequenzdiagramm, die Organisation von Programmspeicher und Datenspeicher, ein Interrupt-System und ein grundlegender Satz von Peripheriegeräten verstanden werden . Tatsächlich ist in Abb. In Abb. 1 zeigt den Kern, der die Grundlage für die Erstellung Hunderter anderer Modifikationen der 8051-Familie bildete. Die Unterschiede zwischen seinen verschiedenen Vertretern liegen vor allem in der Zusammensetzung der Peripheriegeräte und der Größe des Programm- bzw. Datenspeichers. Da das Aufgabenspektrum von MK gelöst wird. extrem breit, ihre Hersteller versuchen, möglichst viele Modifikationen herauszubringen, um den unterschiedlichsten Verbraucherbedürfnissen gerecht zu werden. In vielen Familien nähert sich die Zahl der Modifikationen der Hundertzahl oder übersteigt diesen Wert sogar. Das wichtigste Merkmal der Familie ist die Softwarekompatibilität auf der Ebene des Binärcodes aller darin enthaltenen MKs. Dadurch können Systementwickler eine Familie von Mikrocontrollern durch andere ersetzen, ohne ihre Softwareentwicklungen zu verlieren. Je größer die Anzahl der in der Familie enthaltenen Sorten ist, desto wahrscheinlicher ist es natürlich, dass die beste Option ausgewählt wird, und desto attraktiver ist diese Familie für den Entwickler. Die Frage nach der richtigen Wahl einer MC-Familie für eine Neuentwicklung ist von strategischer Bedeutung, da das Problem der Softwareübertragung zwischen Produkten verschiedener Familien äußerst komplex ist und selbst der Einsatz von Hochsprachen nicht immer eine Lösung zulässt es ohne große Verluste. Auf die Frage der Auswahlkriterien werden wir in den folgenden Artikeln der Serie zurückkommen. Die Programmentwicklung ist einer der wichtigsten Schritte bei der Erstellung eines MK-basierten Geräts. Ohne sie ist er „tot“, reagiert nicht auf äußere Einflüsse und gibt keine Steuersignale. Beim Einschalten beginnt die MCU sofort mit der Ausführung des Programms, das sich im mit ihr verbundenen Programmspeicher (normalerweise ROM) befindet. Seine Ausführung beginnt an einer festen Adresse, meist Null. Eine Adresse ist einfach eine ROM-Zellennummer. Der Vorgang läuft wie folgt ab: Die MCU liest die im Programmspeicher gespeicherte Nummer und führt abhängig von ihrem Wert, dem so genannten Maschinencode, bestimmte Aktionen am Inhalt der ALU-Register aus . Speicher, Ports usw. Beispielsweise durch Auslesen der Zahl 32H aus dem Programmspeicher. MK „versteht“, dass Sie den Wert vom Eingangsport Nummer 2 lesen und im Akkumulatorregister ablegen müssen. Oft reicht ein Byte nicht aus, um die Aktion zu beschreiben, und dann liest der MK weitere Bytes aus dem Speicher. Nach dem Ausführen der Aktion liest der MK den Wert aus der nächsten Speicherzelle der Reihe nach usw. Der Satz von Bytes, der eine vom MK ausgeführte Aktion beschreibt, wird als Maschinenbefehl (Anweisung) bezeichnet, und der Satz solcher Befehle, die der MK „ versteht“. - sein Befehlssystem oder Befehlssatz (Befehlssatz). MKs verschiedener Familien haben unterschiedliche Befehlssysteme, d. h. ihre Maschinencodes haben unterschiedliche Bedeutungen, obwohl sie ähnliche Aktionen ausführen. Das Programm für MK ist also eine Zahlenfolge, deren Werte ihm angeben, welche Aktionen ausgeführt werden sollen. Das Ergebnis der Entwicklung eines Programms ist eine Computerdatei, die diese Maschinencodes enthält. Mit Hilfe eines ROM-Programmierers wird es in den MK-Programmspeicher eingegeben („eingenäht“). Wie setzt sich diese Folge von Maschinencodes zusammen – ein Programm für MK? Muss sich der Entwickler wirklich die Werte von Maschinencodes merken und deren Reihenfolge manuell festlegen? Auf diese Weise entstanden die ersten Programme für MK. und man nannte es Programmieren in Maschinencodes. Es ist klar, dass diese Art der Programmentwicklung sehr zeitaufwändig und ineffizient ist. Der erste Schritt zur Erleichterung der Programmerstellung war ein Computerprogramm – der sogenannte Übersetzer aus der Assemblersprache. Die Idee bestand darin, die vom MK ausgeführten Aktionen in einer für Menschen besser lesbaren Sprache auszudrücken und diese Ausdrücke dann in Maschinencodes umzuwandeln. Im obigen Beispiel einer Maschinenanweisung, die den Wert von Port 2 liest und in den Akkumulator schreibt, kann die durchgeführte Aktion grob als MOV A.P2 bezeichnet werden. Hier bezeichnet das Wort MOV (aus dem Englischen move), auch Befehlsmnemonik genannt, die Übertragung eines Werts, und A und P2, sogenannte Operanden, geben an, woher der Wert kommt und wo er abgelegt werden soll. Diese Notation wird Assemblersprache genannt. Programm darauf geschrieben. von einem Übersetzer verarbeitet, der Assemblersprachenkonstrukte in Maschinencodes umwandelt. Die Assembler-Programmierung ist bis heute weit verbreitet. Assembler-Übersetzer für alle gängigen Mikrocontroller-Familien sind kostenlos. Trotz der offensichtlichen Vorteile der Programmierung in Assembler gegenüber der Programmierung in Maschinencode ist der Assembler in vielen Fällen nicht effizient genug, um die Aufgaben des Entwicklers umzusetzen. Tatsache ist, dass der MK nur die einfachsten Operationen wie arithmetische Operationen mit ganzen Zahlen, Übertragungen, Vergleiche usw. ausführen kann. Für komplexere Aufgaben, zum Beispiel Operationen mit Gleitkommazahlen, mussten Entwickler spezielle Routinen schreiben, die umständlich sind verwenden. und umständlich. Der nächste Schritt bei der Entwicklung von Programmen für MK war die Erstellung spezieller Computerprogramme – Übersetzer aus höheren Programmiersprachen oder Compiler. Die am weitesten verbreitete Programmiersprache ist C. Mit dem Aufkommen von Übersetzern wurde die Entwicklung von Programmen für MK erheblich vereinfacht. Wenn Sie im Programm beispielsweise zwei Zahlen addieren müssen, reicht es jetzt aus, nur noch a = b + c zu schreiben. und der Übersetzer wandelt diesen Ausdruck abhängig von den Variablentypen a, b und c in die erforderliche Folge von Maschinenanweisungen um. Die Verwendung einer Hochsprache ermöglicht es dem Entwickler, vom Befehlssystem eines bestimmten Mikrocontrollers zu abstrahieren und mit Kategorien zu arbeiten, die einfacher und für den Menschen verständlicher sind. Der Entwickler muss lediglich die allgemeine Architektur des Mikrocontrollers kennen. Funktionsprinzipien eingebetteter Peripheriegeräte, die zur Lösung der Aufgabe erforderlich sind, und Programmierkenntnisse in der Sprache C. Der funktionale Inhalt des Programms wird mit den C-Sprachtools implementiert. das eine Vielzahl verschiedener Unterprogramme (Funktionen) enthält: Arithmetik, für die Arbeit mit Zeichenfolgen und viele andere. Betrachten Sie den Prozess der Erstellung eines Programms für MK in der Sprache C. Für den Entwicklungsprozess ist ein PC erforderlich. Nachdem der Entwickler die Aufgabe verstanden hat, schreibt er mit einem beliebigen Texteditor den Quellcode seines Programms in der Sprache C. Anschließend wird das C-Übersetzerprogramm ausgeführt. Dadurch wird der Quelltext in eine Zwischenobjektdatei umgewandelt. Der Übersetzer wird durch eine Reihe von Schlüsseln gesteuert (ihre Beschreibung finden Sie in seiner Dokumentation), die in seiner Befehlszeile angegeben werden. Wenn dem Entwickler beim Schreiben des Programms syntaktische Fehler unterlaufen sind, zeigt der Übersetzer eine Liste davon auf dem Bildschirm an, mit Angabe für jede Zeilennummer in der Quelltextdatei. Der Entwickler muss alle Fehler beheben. Nach erfolgreicher Übersetzung müssen die Objektdateien vom Linker (Linker) verarbeitet werden, der die Programmdatei in Maschinencodes generiert. Bei der Verwendung einer Hochsprache gibt es ein Problem. Der Compiler ist für die Umwandlung von Sprachkonstrukten in Maschinencodes verantwortlich, und diese Umwandlung kann mit unterschiedlichem Effizienzgrad durchgeführt werden. Effizienzkriterien sind die Größe des Maschinencodes (je kleiner natürlich, desto besser) und die Geschwindigkeit des Maschinencodes. Die Aufgabe, kompakten und schnellen Code zu generieren, ist sehr schwierig, und die Gesamtqualität des Compilers hängt von seiner Lösung ab. Moderne C-Compiler verwenden mehrstufige Optimierung, Architekturfunktionen eines bestimmten MK und ermöglichen die Erstellung gemischter Programme, in denen einige der Unterprogramme in Assembler geschrieben sind. Der beschriebene Prozess sieht ziemlich umständlich aus: Der Entwickler muss verschiedene Programme manuell starten (Texteditor, C-Compiler, Linker zum Merken von Steuerschlüsseln, Suche nach Fehlern im Programm anhand der Zeilennummern in der Datei. Der neueste Schritt, um die Arbeit des Entwicklers zu erleichtern von Programmen für MK war die Entstehung integrierter Entwicklungsumgebungen (Integrated Development Environment, IDE). Eine integrierte Entwicklungsumgebung ist ein Computerprogramm, das alle Phasen der Programmentwicklung miteinander verbindet. Sie kombiniert einen Texteditor zum Schreiben von Quellcode, Übersetzer von Assembler und C, ein Linker, ein Debugger, Referenzinformationen zu MK und andere für den Entwickler notwendige Tools. Die Konfiguration von Übersetzern, Linkern und anderen Komponenten erfolgt nicht durch Angabe von Schaltern in der Befehlszeile, sondern in Form von Dialogfeldern, wo Sie sie nur benötigen um die Kästchen an den richtigen Stellen anzukreuzen. . Das Aufkommen integrierter Softwareentwicklungsumgebungen steigerte die Effizienz bei der Erstellung von Programmen für MC weiter und ermöglichte es dem Entwickler, sich auf das Wesentliche des zu lösenden Problems zu konzentrieren und von den spezifischen Details seiner Implementierung zu abstrahieren. Integrierte Softwareentwicklungspakete werden von mehreren Unternehmen hergestellt. Pakete verschiedener Hersteller ähneln in ihrer Funktion, unterscheiden sich jedoch in den Servicefunktionen, der Benutzerfreundlichkeit und der Qualität des generierten Maschinencodes. Die Hauptmerkmale der beliebtesten Entwicklungskits sind in der Tabelle aufgeführt.
SYMBOLISCHES DEBUGING VON PROGRAMMEN FÜR MK Mit seltenen Ausnahmen funktionieren Programme für MK aufgrund der darin enthaltenen Fehler nicht beim ersten Mal und erfordern ein Debuggen. Entwickler gehen auf unterschiedliche Weise mit Debugging-Problemen um. Einige von ihnen glauben, dass es ausreicht, den Quelltext sorgfältig zu analysieren, mit einem Oszilloskop zu sehen, was an den MK-Ausgängen passiert, und alle Fehler korrigiert werden können. Diese Methode ist anwendbar, wenn der Entwickler über umfangreiche Erfahrung verfügt, das verwendete MK perfekt kennt und über einen Übersetzer verfügt, der immer den richtigen Code generiert (normalerweise ein Assembler), sowie über ausreichend Zeit. Andere verwenden in ihrer Praxis selbst erstellte Debug-Monitore – Sätze spezieller Unterroutinen, die zusammen mit dem Hauptprogramm in das MK geladen werden. Letzterer ruft an Checkpoints die Monitor-Subroutinen auf, die Auskunft über den Zustand der MK-Ressourcen geben. Fast jedes Programm kann auf diese Weise debuggt werden, es gibt jedoch Nachteile, die erheblich sein können. Erstens muss dem Debug-Monitor ein Teil der MC-Ressourcen für die Arbeit zur Verfügung gestellt werden: mindestens ein Teil des Adressraums des Codes und eine bestimmte Anzahl von Stapelzellen und maximal auch ein Teil des RAM und der Peripherie Geräte des MC. Wird vom Monitor zur Anzeige von Informationen verwendet. Es kann schwierig sein, dem Debug-Monitor Ressourcen zuzuweisen, wenn das Hauptprogramm selbst den MK aktiv lädt. Beispielsweise verfügt der PIC 16С5х (Microchip) MK nur über zwei Stapelzellen, und es ist schwierig, Unterprogrammaufrufe zur Debug-Überwachung zu verwenden. Zweitens nehmen Monitoraufrufe Zeit vom Hauptprogramm in Anspruch und können daher nicht von zeitkritischen Teilen des Programms aufgerufen werden. Drittens nimmt die Erstellung eines Debug-Monitors an sich Zeit in Anspruch. Der effektivste Weg, Programme für MK zu debuggen, ist die Verwendung spezieller professioneller Debugging-Tools, zu denen Simulator-Debugger und In-Circuit-Emulatoren gehören. Bevor auf die Möglichkeiten solcher Debugger eingegangen wird, muss auf die Wahl des Compilers eingegangen werden, mit dessen Hilfe die Quelltexte von Programmen in Maschinencode umgewandelt werden. In den allermeisten Fällen ist die Programmierung in einer Hochsprache vorzuziehen. Der Einsatz von Assembler ist erforderlich, wenn sehr hohe Anforderungen an die Größe und Geschwindigkeit des generierten Codes gestellt werden. Derzeit kommen solche Fälle immer seltener vor, da man fast immer einen „schnelleren“ MK mit mehr Speicher nehmen kann. Darüber hinaus erleichtern moderne Cross-Tool-Pakete das Schreiben gemischter Programme, bei denen einige Module in C geschrieben sind. und die leistungskritischsten Teile befinden sich im Assembler. C-Compiler ermöglichen auch das Einfügen von Assembleranweisungen in den Quellcode. Welche Vorteile bietet die Programmierung in C gegenüber der Programmierung in Assembler? Kurz gesagt lauten sie wie folgt:
Um in einer Hochsprache geschriebene Programme effektiv debuggen zu können, muss der Entwickler über Debugging-Tools verfügen, die ausreichende Möglichkeiten zur Anzeige der im Programm verwendeten Daten sowie zur Verfolgung der Ausführung des Programms anhand seines Quellcodes bieten . Damit dies möglich ist, sind zwei Voraussetzungen notwendig:
Überlegen wir nun, wie der Debugger symbolische Informationen interpretieren soll und welche Optionen dem Benutzer in diesem Zusammenhang zur Verfügung gestellt werden sollen. VERFOLGEN DER AUSFÜHRUNG DES PROGRAMMS NACH SEINEM QUELLTEXT Im Allgemeinen wird eine Zeile Quelltext vom Compiler in mehrere Maschinenanweisungen umgewandelt. Selbst ein Assembler-Programm enthält fast immer Makros, die sich bei der Übersetzung in mehrere Prozessoranweisungen erweitern. Es ist unpraktisch, ein solches Programm mit dem Disassembler seines Codes zu debuggen, daher fügen Compiler eine Tabelle mit Zeilennummern in die Debug-Informationen ein. Es enthält Informationen über die Übereinstimmung von Quelltextzeilennummern und Quelltextdateinamen mit absoluten Adressen des Programmcodes. Der Debugger zeigt den Quellcode des Programms auf dem Bildschirm an. Wenn es dieser Tabelle folgt, kann es das Programm „Zeile für Zeile“ ausführen und dabei alle vom Compiler für die aktuelle Zeile generierten Maschinenanweisungen in einem Schritt ausführen. Mit der Zeilennummerntabelle können Sie auch kontextbezogene Aktionen mit dem Programmtext ausführen, z. B. ihn „bis zum Cursor“, d. h. an einer vom Benutzer angegebenen Stelle im Quelltext, ausführen, Haltepunkte an bestimmten Zeilen setzen usw. Kontextbezogene Aktionen sind praktisch, da der Entwickler die den Zeilen des Quelltexts entsprechenden Adressen nicht kennen muss: Der Debugger ermittelt sie selbst aus der Tabelle. Der Debugger muss außerdem die Adressen von Unterprogrammen, Funktionen und Codebezeichnungen „kennen“ und in der Lage sein, den Quelltext einer Funktion anhand ihres Namens zu finden. ANZEIGEN VON DATEN, DIE IN DEM PROGRAMM VERWENDET WERDEN, DAS SIE DEBUGTEN Für ein vollständiges Debugging muss der Entwickler die vom Programm manipulierten Daten jederzeit einsehen können. Der Debugger muss „in der Lage sein“, alle vom Programm verwendeten Daten auf die am besten geeignete Weise anzuzeigen. In der Regel verwenden Entwickler benannte Daten in Programmen, d. h. jedes Objekt, das im Programm verwendet wird, erhält einen Namen. Objekte können unterschiedlich komplex sein – von einfachen Speicherzellen bis hin zu komplexen Strukturen von Hochsprachen wie Strukturen, Arrays usw. DATEN IN MONTAGEPROGRAMMEN Assemblerprogramme nutzen meist einfache Daten, also Speicherzellen. Es werden auch Arrays verwendet. Um einfache Daten korrekt anzuzeigen, muss der Debugger Folgendes „wissen“:
Mit den oben genannten Informationen sollte der Debugger, nachdem er vom Benutzer den Namen des Objekts erhalten hat, dessen Wert entsprechend dem Typ anzeigen. Die „fortschrittlichsten“ Debugger können zusätzlich die restlichen Attribute des Objekts anzeigen. DATEN IN PROGRAMMEN IN HOCHSPRACHEN Die Anzeige von Objekten, die in Hochsprachen verwendet werden, ist aufgrund der Vielfalt der Objektstrukturen, der Art und Weise, wie sie im Speicher gespeichert werden, und des Umfangs viel schwieriger. Als Beispiel verwenden wir die Sprache C, die unter Entwicklern am beliebtesten ist. STRUKTUR DER OBJEKTE Neben einfachen Variablen unterschiedlicher Länge verwenden C-Programme auch Gleitkommavariablen, Strukturen (Struct), Unions oder Unions (Union), Zeiger, eindimensionale und mehrdimensionale Arrays. Letztere können sowohl aus einfachen als auch aus komplexen Objekten (Strukturen, Unions, Zeiger) bestehen. Die Verwendung komplexer Objekte in Programmen ist sicherlich praktisch. Aufgrund der Komplexität ihrer Struktur ist es jedoch äußerst wünschenswert, diese in der Debugging-Phase angemessen darstellen zu können. In den Debuggern von Fiton können komplexe Objekte sowohl in komprimierter (Liste der Elementwerte) als auch in erweiterter Form angezeigt werden, wobei die Adresse, der Wert und der Typ jedes Array-Elements und/oder Strukturelements angegeben werden. Die Implementierung von Zeigern in verschiedenen Compilern ist unterschiedlich. Zusätzliche Schwierigkeiten bereitet die Tatsache, dass der MK in der Regel über mehrere Adressräume verfügt, da beim Arbeiten mit einem Zeiger neben der Adresse auch der Adressraum bekannt sein muss, auf den der Zeiger zeigt. In einigen Implementierungen ist die Adressraumkennung Teil des Zeigerwerts; in anderen „weiß“ der Compiler dies im Voraus und generiert den entsprechenden Code. Darüber hinaus kann die Adresskomponente in einem Zeiger 8 bis 32 Bit groß sein. Beim Anzeigen von Zeigerwerten muss der Debugger alle Details ihrer Implementierung in jedem Compiler „kennen“. Methoden zur Lokalisierung von Objekten im Speicher Neben statischen Objekten, deren Adressen sich während der Ausführung des Programms nicht ändern, kann es in einem in einer Hochsprache geschriebenen Programm sogenannte automatische Objekte geben, für die im MK-Stack vorübergehend Speicher reserviert wird . Die Adressen solcher Objekte sind nicht absolut, sondern werden dynamisch bei der Programmausführung bestimmt. Sie werden normalerweise anhand des aktuellen Werts einer statischen Variablen gemessen, die als Stapelrahmenzeiger (Basiszeiger oder BP) bezeichnet wird. Da der Wert von BP zur Laufzeit dynamisch vom Programm generiert wird, sind die Werte automatischer Objekte nur innerhalb ihres Gültigkeitsbereichs, also mit einem gültigen BP-Wert, verfügbar. Der Debugger muss bei der Anzeige der Werte automatischer Objekte „wissen“, wie Adressen ermittelt werden, und die Richtigkeit des BP-Werts überwachen Es ist auch möglich, Variablen vorübergehend in MK-Registern zu platzieren. In diesem Fall muss der Debugger „wissen“, welche Variablen wie lange in welche Register gelegt werden. Und schließlich kommt es oft vor, dass dasselbe Objekt im Laufe seines Lebens die Art und Weise ändert, wie es im Gedächtnis abgelegt wird, und zwar mehr als einmal. Dies kann beispielsweise passieren, wenn eine Funktion einen oder mehrere Parameter in Registern empfängt und diese dann auf den Stapel schiebt. OBJEKT SICHTFELD Wie Assembler-Programme verfügen C-Programme über globale Objekte, auf die von jedem Modul aus über ihren Namen zugegriffen werden kann, sowie über Objekte, die im Modul lokalisiert sind (diese Objekte werden als statisch deklariert). Automatische Variablen und Registervariablen erschweren jedoch die Anzeige ihrer Werte durch Debugger. Die Sache ist die. Erstens ist die Lebensdauer eines automatischen Objekts durch seinen Bereich begrenzt, und zweitens können umschließende Bereiche eigene automatische Objekte mit demselben Namen haben. Lassen Sie uns dies anhand eines Beispiels einer Funktion veranschaulichen, die über mehrere verschachtelte Bereiche verfügt:
Die Variable mit dem Namen „a“ existiert solange die Funktion f ausgeführt wird, je nachdem welcher Teil der Funktion ausgeführt wird, steht der Name „a“ jedoch für unterschiedliche Variablen. Beim Tracing der Funktion f muss der Debugger, je nachdem welche Variable aktiv ist, deren Wert korrekt anzeigen. Beim Erstellen eines Programms kümmert sich der Entwickler nicht um die Details der Implementierung der Konzepte, die er im Programm verwendet. In Bezug auf „selbstverständliche“ Kategorien ahnt er oft nicht, wie schwierig es für Entwickler von Compilern und Debuggern war, diese zu implementieren. Letztere müssen das Problem lösen, in einer Shell gleichzeitig eine einfache und intuitive Benutzeroberfläche, eine Fülle von Funktionen und eine detaillierte Untersuchung von allem zu vereinen, was mit der Implementierung der Architekturmerkmale und der Funktionsweise eines bestimmten MK zusammenhängt. Wenn der Debugger dem Entwickler keine der Komplexität des zu lösenden Problems angemessenen Debugging-Tools zur Verfügung stellt, verliert der Entwickler unweigerlich an Produktivität. Wer von uns musste nicht stunden- und tagelang nach einem lästigen Fehler oder Tippfehler im Quelltext suchen?! Bei der Entwicklung und Erstellung eines Mikroprozessorsystems kommt früher oder später der Moment, in dem es endlich in Hardware verkörpert ist und Lebenszeichen zeigt. In den meisten Fällen erweisen sich diese Anzeichen jedoch als unvorhersehbar, das System beginnt ein Eigenleben zu führen. Viele Programmierer würden wahrscheinlich zustimmen, dass jedes neue Programm Fehler enthält. Auch deshalb verhält sich der neue MK zunächst wie eine „Black Box“. Um den Prozess des Debuggens von Systemen zu erleichtern, wurde eine ganze Klasse von Tools entwickelt. Ihr Hauptzweck besteht darin, den Funktionsprozess des debuggten MK „transparent“ zu machen, d. h. leicht kontrollierbar, willkürlich kontrollierbar und nach dem Willen des Entwicklers modifizierbar. Ein gutes professionelles Toolkit kann dem Entwickler zusätzlich viele Dienste bieten und ihm so die Arbeit erheblich erleichtern, da Routinearbeiten entfallen. Zu den wichtigsten Debugging-Tools gehören In-Circuit-Emulatoren, Softwaresimulatoren, Entwicklungsboards (Evaluierungsboards), Debug-Monitore und ROM-Emulatoren. Es gibt auch Kombigeräte und Sets. IN-CIRCUIT-EMULATOREN Ein In-Circuit-Emulator (ICE) ist ein Hardware-Software-Tool, das einen emulierten Prozessor in einem realen Gerät ersetzen kann. VSE ist das leistungsstärkste und vielseitigste Debugging-Tool. Funktionell werden VEs in solche unterteilt, die an einen externen Computer (in der Regel ein IBM-kompatibler PC) angeschlossen sind und autonom funktionieren. Letztere verfügen über eigene Rechenressourcen und Ein-/Ausgabemöglichkeiten, sind daher bei gleicher Leistungsfähigkeit deutlich teurer als erstere und sind ihnen bei gleichem Preis in Funktionalität und Servicefähigkeit deutlich unterlegen. Beim Debuggen des Systems wird die VSE normalerweise über ein Kabel mit einem speziellen Emulationskopf verbunden. Vor relativ kurzer Zeit sind VSE-Modelle aufgetaucht, bei denen ein solcher Kopf strukturell mit der Haupteinheit verbunden ist und anstelle des MK in das zu debuggende System eingefügt wird. Wenn letzterer nicht entfernt werden kann (die Pins sind mit der Platine verlötet), ist die Verwendung des VSE zulässig, sofern dieser MC über einen Debug-Modus verfügt, in dem sich alle seine Pins im dritten (hochohmigen) Zustand befinden. In diesem Fall wird zum Anschluss des VSE ein spezieller Clip-Adapter verwendet, der direkt an die Ausgänge des emulierten MK angeschlossen wird. Zumindest. VSE enthält einen Debugger, einen MK-Emulationsknoten. Emulationsspeicher und Breakpoint-Subsystem. Fortgeschrittenere TSEs können zusätzlich einen Tracer, einen Breakpoint-Prozessor, einen Profiler (Programmcode-Effizienzanalysator), einen Echtzeit-Timer sowie Software- und Hardware-Tools enthalten, mit denen Sie die Ressourcen des emulierten Prozessors „on the fly“ lesen und ändern können. , Software- und Hardware-Tools, die eine synchrone Verwaltung ermöglichen und für die Emulation in Multiprozessorsystemen eine integrierte Entwicklungsumgebung benötigen. Der Debugger ist eine Art Brücke zwischen dem Entwickler und dem Debugging-Tool. Ein guter Debugger sorgt dafür, dass die zu debuggenden Programme in den Systemspeicher geladen werden, die Zustände und Inhalte aller Register und Speicher (und ggf. deren Änderungen) auf dem Monitor angezeigt werden und der Emulationsprozess gesteuert wird. Leistungsstärkere Debugger (allgemein als High-Level- oder High-Level-Debugger bezeichnet) ermöglichen dies ebenfalls.
Ein solcher Debugger ermöglicht es dem Benutzer, gleichzeitig den Fortschritt des Programms zu steuern und die Entsprechung zwischen dem Quelltext, dem Bild des Programms in Maschinencodes und dem Zustand aller Ressourcen des emulierten Mikrocontrollers zu sehen. Es ist zu beachten, dass ein High-Level-Debugger die Leistung aller seiner Funktionen nur dann bereitstellt, wenn ein Cross-Compiler verwendet wird, der vollständige und korrekte Debugging-Informationen liefert (nicht alle Compiler, insbesondere ihre Raubkopien, sind dazu in der Lage), und bei Gleichzeitig ist das Format seiner Darstellung dem Debugger „vertraut“. Im Debugging-Prozess wird Emulationsspeicher anstelle des ROM des zu entwickelnden Systems verwendet. Darüber hinaus können Sie das Programm debuggen, wenn kein echtes System oder dessen Layout vorhanden ist. Wenn Sie Änderungen am zu debuggenden Programm vornehmen müssen, reicht es aus, ein neues oder geändertes Programm in den Speicher des Emulators zu laden, anstatt das ROM neu zu programmieren. Es gibt VSE. die es dem Benutzer ermöglichen, Emulationsspeicher anstelle von ROM nicht nur vollständig, sondern auch Block für Block zu „ersetzen“ (bei einigen Modellen beträgt die minimale Blockgröße 1 Byte). in der vom Benutzer angegebenen Reihenfolge. Dazu genügt es ihm, die Aufteilung von Datenspeicher und Programmspeicher festzulegen, wonach der Prozessor sowohl auf den Inhalt des ROM im zu debuggenden System als auch auf den Inhalt des Emulationsspeichers des TSE zugreift. Ein solcher Speicher wird üblicherweise als Speicher mit Mapping-Möglichkeit bezeichnet. Der Tracer ist ein Logikanalysator, der synchron mit dem Prozessor arbeitet und den Fluss der ausgeführten Befehle sowie den Zustand ausgewählter externer Signale erfasst. Es gibt VSEs, die es ermöglichen, nicht nur externe Signale, sondern auch die Zustände der internen Ressourcen des MC zu verfolgen. z.B. Register. In solchen Geräten werden spezielle Versionen von MK (Emulationskristallen) verwendet. Der Breakpoint-Prozessor ermöglicht es, die Programmausführung zu stoppen oder andere Aktionen auszuführen (z. B. Starten oder Stoppen des Tracers), wenn vom Benutzer angegebene Bedingungen erfüllt sind. Im Gegensatz zum üblichen Breakpoint-Mechanismus können Sie mit dem Prozessor nahezu beliebige Bedingungen bilden und verfolgen Komplexität auf der Hardwareebene, während die Emulation des Prozesses nicht aus der Echtzeitskala abgeleitet wird. Bei einigen VSE-Modellen kann der Breakpoint-Prozessor optional zur dynamischen Steuerung des Tracers verwendet werden. Der Profiler (Programmcode-Effizienzanalysator) ermöglicht es, basierend auf den Ergebnissen der Ausführung des debuggten Programms Informationen über die Anzahl der Aufrufe verschiedener Abschnitte des Programms und die für deren Ausführung aufgewendete Zeit zu erhalten. Die Analyse der vom Profiler gelieferten statistischen Informationen ermöglicht es, „tote“ oder überlastete Programmabschnitte zu identifizieren und dadurch die Struktur des zu debuggenden Programms zu optimieren. Eine integrierte Entwicklungsumgebung ist eine Reihe von Softwaretools, die alle Phasen der Softwareentwicklung vom Schreiben des Quellcodes eines Programms bis zum Kompilieren und Debuggen unterstützen und eine einfache und schnelle Interaktion mit einem Software-Debugger-Simulator und Programmierer ermöglichen. Das Vorhandensein eines integrierten Editors, Projektmanagers und Steuerungssystems in der VSE-Software-Shell erleichtert die Arbeit des Entwicklers erheblich und erspart ihm viele Routinetätigkeiten. Für ihn ist die Grenze zwischen dem Schreiben eines Programms, seiner Bearbeitung und dem Debuggen fließend. Der Übergang von der Quelltextbearbeitung zum Debuggen und umgekehrt erfolgt „transparent“ und synchron mit der Aktivierung der entsprechenden Fenster. Der Projektmanager startet bei Bedarf automatisch die Kompilierung und aktiviert das entsprechende Fenster der Programmoberfläche. Sie können genauso einfach mit dem Debuggen des Projekts mit dem vorhandenen Simulator-Debugger fortfahren oder mit einem debuggten Programm mit dem Flashen des ROM beginnen. Einige ITUs bieten Benutzern weitere zusätzliche Funktionen. Unter ihnen ist besonders die Fähigkeit hervorzuheben, zwar recht spezifisch, aber in einigen Fällen von grundlegender Bedeutung, die Fähigkeit, Multi-Emulator-Komplexe aufzubauen, die zum Debuggen von Multiprozessorsystemen erforderlich sind. Eine Besonderheit eines solchen Komplexes ist die synchrone Steuerung (von einem Computer aus). ) mehrerer Emulatoren. Im Allgemeinen kann die Fähigkeit des TSE, die Funktion debuggter Geräte zu steuern und zu verwalten, eingeschränkt sein (z. B. falsche Interrupt-Behandlung im Schrittmodus, Verbot der Verwendung einer seriellen Schnittstelle usw.). Beachten Sie auch, dass jedes VSE-Modell über eine eigene Liste unterstützter Mikrocontroller und Compiler verfügt. Für die meisten gängigen Mikrocontroller wurden jedoch VSEs entwickelt, die keine Einschränkungen hinsichtlich der Ressourcennutzung debuggter Quarze aufweisen. Die Möglichkeiten eines solchen ESS veranschaulichen wir am Beispiel des PICE-51-Modells der Firma Fiton. PICE-51 ist ein Gerät, das mit einem programmierbaren Logik-IC (FPGA) erstellt wurde. Dadurch war es möglich, die Größe des VSE drastisch zu reduzieren, die Abweichungen seiner elektrischen und Frequenzeigenschaften von den Eigenschaften des emulierten MC zu minimieren und dadurch eine maximale Emulationsgenauigkeit bei Frequenzen bis zu 33 MHz bei Versorgungsspannungen von 3,3 bis 5 V zu erreichen . Emulation fast aller MKs der MCS-51-Familie. Die Softwareunterstützung funktioniert in der Windows-Umgebung. PICE-51 besteht aus einer Hauptplatine, einem austauschbaren Adapter für eine bestimmte MK-Gruppe und einem austauschbaren Emulationskopf auch für einen bestimmten Gehäusetyp. Auf der Hauptplatine sind ein Tracer und ein Breakpoint-Prozessor montiert, auf der austauschbaren Adapterplatine ist ein Emulationsprozessor für einen bestimmten MK-Typ installiert. Die Emulationsköpfe ermöglichen die Installation des Geräts in DIP- und PLCC-Sockeln auf der Benutzerplatine. Die Stromversorgung erfolgt über einen Block mit einer Ausgangsspannung von +5 V (0,5 A) oder über ein zu debuggendes Gerät. Die Kommunikation mit einem Computer erfolgt über einen galvanisch getrennten RS-232C-Kanal mit einer Geschwindigkeit von 115 kBaud. Weitere Merkmale und Fähigkeiten des PICE-51 sind wie folgt:
Dieser große Funktionsumfang macht VSE zum leistungsstärksten und vielseitigsten Debugging-Tool. SIMULATOREN Simulator – ein Softwaretool, das den Betrieb des MK und seines Speichers simulieren kann. Typischerweise besteht es aus einem Debugger, einem CPU-Modell und Speicher. Fortgeschrittenere Geräte enthalten Modelle integrierter Peripheriegeräte (Timer, Ports, ADCs und Interrupt-Systeme). Der Simulator muss Programmdateien in allen gängigen Formaten „laden“ können und Informationen über den Zustand der Ressourcen des simulierten Mikrocontrollers möglichst vollständig anzeigen. und bieten auch Möglichkeiten zur Simulation der Ausführung des geladenen Programms in verschiedenen Modi. Während des Debuggens führt das Modell das Programm aus und der aktuelle Status des Modells wird auf dem Computerbildschirm angezeigt. Durch Laden des Programms in den Simulator. Der Benutzer kann es im Schritt-für-Schritt- oder kontinuierlichen Modus ausführen, bedingte oder unbedingte Haltepunkte festlegen, den Inhalt der Speicherzellen und Register des simulierten Mikrocontrollers steuern und frei ändern. Mit dem Simulator können Sie schnell die Logik der Programmausführung und die Richtigkeit arithmetischer Operationen überprüfen. Abhängig von der verwendeten Debuggerklasse unterstützen einige Simulatormodelle das symbolische Debuggen von Programmen auf hoher Ebene. Der Simulator kann auch eine Reihe zusätzlicher Softwaretools enthalten, beispielsweise eine externe Umgebungsschnittstelle. Das Vorhandensein einer solchen Schnittstelle ermöglicht es Ihnen, ein Modell der externen Umgebung des MC zu erstellen und flexibel zu nutzen. Funktionieren und Beeinflussen des debuggten Programms gemäß einem bestimmten Algorithmus. In einem realen System ist der MC normalerweise damit beschäftigt, Informationen von an ihn angeschlossenen externen Geräten (Sensoren) zu lesen, zu verarbeiten und Steuersignale an Aktoren auszugeben. Um den Betrieb eines Sensors in einem einfachen Simulator zu simulieren, müssen Sie den aktuellen Zustand des Modells des Peripheriegeräts, an das der Sensor angeschlossen ist, in einem realen System manuell ändern. Wenn beispielsweise beim Empfang eines Bytes über eine serielle Schnittstelle ein bestimmtes Flag gesetzt ist und das Byte selbst in ein bestimmtes Register fällt, müssen beide Aktionen manuell im Simulator durchgeführt werden. Bei einigen Modellen ist dieses Problem gelöst: Simulatoren verfügen über integrierte Tools zum Erstellen von Modellen externer Geräte, die an den MK angeschlossen sind, einschließlich Tools zur grafischen Anzeige von Informationen. Das ist ein offensichtliches Merkmal von Softwaresimulatoren dass die darin geladenen Programme in einer anderen Zeitskala als der Echtzeit ausgeführt werden. Der niedrige Preis und die Möglichkeit zum Debuggen, auch wenn kein Modell des zu debuggenden Geräts vorhanden ist, machen Softwaresimulatoren jedoch zu einem sehr attraktiven Debugging-Tool. Zu beachten ist auch, dass es eine ganze Klasse von Fehlern gibt, die nur mit einem Simulator erkannt werden können. DEBUG-MONITOREN Ein Debug-Monitor ist ein spezielles Programm, das in den Speicher des zu debuggenden Systems geladen wird. Es zwingt den MK, zusätzlich zur angewendeten Aufgabe auch Debugging-Funktionen auszuführen:
Das Monitorprogramm arbeitet „in Verbindung“ mit einem Computer oder einem passiven Terminal, auf dem die Visualisierung und Steuerung des Debugging-Prozesses erfolgt. Der Vorteil dieses Ansatzes
ENTWICKLUNGSBOARDS Entwicklungsboards oder, wie sie in der ausländischen Literatur üblicherweise genannt werden, Evaluationsboards (Evaluation Boards). - Originalkonstrukteure für die Prototypenerstellung angewandter Systeme. In letzter Zeit haben viele Herstellerfirmen neue MK-Modelle auf den Markt gebracht. Angebot und entsprechende Entwicklungsboards. Normalerweise handelt es sich dabei um eine Leiterplatte mit einem darauf installierten MK und allen für den normalen Betrieb erforderlichen Elementen sowie um Kommunikationssysteme mit einem Computer. In der Regel bietet die Platine freien Platz für die Montage des zu entwickelnden Benutzergeräts. Manchmal gibt es auch eine vorgefertigte „Verkabelung“ für den Einbau zusätzlicher, vom Unternehmen empfohlener Geräte (ROM, RAM, LCD-Display, Tastatur, ADC usw.). Vom Anwender modifizierte Platinen können vorteilhaft als Single-Board-Controller zum Einbau in Kleinprodukte (5...20 Stk.) eingesetzt werden. Für den Komfort des Benutzers sind Entwicklungsboards außerdem mit einem einfachen Debugging-Tool ausgestattet, das auf dem Debug-Monitor basiert. Dabei haben sich zwei unterschiedliche Ansätze herauskristallisiert: Einer wird für MK verwendet. mit einem externen Bus und der zweite - für MKs, die keinen haben. Im ersten Fall wird der Debug-Monitor als ROM-Chip geliefert. welches in einem speziellen Sockel auf der Entwicklungsplatine verbaut wird. Das Board verfügt außerdem über RAM für Benutzerprogramme und einen Kommunikationskanal mit einem Computer oder Terminal. Ein Beispiel ist das von Intel entwickelte Entwicklungsboard für die MK MCS-51-Familie. Im zweiten Fall enthält die Entwicklungsplatine integrierte Programmiersysteme für das interne ROM des MK. die von einem Computer gesteuert werden. Das Monitorprogramm wird zusammen mit der entsprechend vorbereiteten Anwendung in das ROM des MK eingetragen (Aufrufe der Monitor-Debugging-Routinen werden an den richtigen Stellen eingefügt). Anschließend wird ein Testlauf durchgeführt. Um Korrekturen am zu debuggenden Programm vorzunehmen, wird es aus dem ROM gelöscht und das korrigierte Programm hineingeschrieben. Das fertige Anwendungsprogramm wird aus dem debuggten erhalten, indem der Monitor und alle Aufrufe seiner Funktionen entfernt werden. Entwicklungsboards für MKs der Familien PIC-micro (Microchip), 80C750 (Philips) und 89C2051 (Atmel) sind für einen solchen Debugging-Algorithmus ausgelegt. Entwicklungsboards sind manchmal mit Debugging-Programmen ausgestattet, die auf einem externen Computer „in Verbindung“ mit einem Monitor laufen. Diese Programme sind in letzter Zeit deutlich komplexer geworden und verfügen oft über hochprofessionelle Debugging-Funktionen (z. B. einen Debugger-Simulator) oder verschiedene Elemente, die nur integrierten Entwicklungsumgebungen in reiner Form innewohnen. Die Kits können auch Anwendungsprogramme enthalten, die in der Praxis am häufigsten vorkommen. Die Debugging-Funktionen des „Development Board plus Monitor“-Kits sind nicht so universell wie die des ESS. Darüber hinaus werden einige der MC-Ressourcen im Debugging-Prozess ausgewählt, damit der Monitor funktioniert. Dennoch ist in vielen Fällen die Verfügbarkeit eines kompletten Satzes vorgefertigter Software- und Hardware-Tools, die es Ihnen ermöglichen, ohne Zeitverlust mit der Installation und dem Debuggen des eingesetzten Systems zu beginnen, ein entscheidender Faktor. Vor allem, wenn man bedenkt, dass ein solches Kit um ein Vielfaches weniger kostet als ein vielseitigerer Emulator. ROM-EMULATOREN Ein ROM-Emulator ist ein Software- und Hardware-Tool, mit dem Sie das ROM des zu debuggenden Geräts durch RAM ersetzen können. in das Sie das Programm über einen der Standardkommunikationskanäle von Ihrem Computer herunterladen können. Dadurch kann der Benutzer mehrere Zyklen des ROM-Flashens vermeiden. Der ROM-Emulator wird nur zum Debuggen von MK-Programmen verwendet, die auf externen Programmspeicher zugreifen können. In Bezug auf Komplexität und Kosten ist dieses Gerät mit Entwicklungsboards vergleichbar. Es hat einen großen Vorteil: Vielseitigkeit. Der ROM-Emulator kann mit jedem MK arbeiten. Die ersten ROM-Emulatoren erlaubten nur das Laden, Ausführen und Stoppen eines Programms durch einen Master-Reset. Dann gab es komplizierte Modelle mit Hardware-Erzeugung von Trace-Signalen an das Oszilloskop bei Erreichen einer bestimmten Adresse. Der emulierte Speicher in solchen Produkten konnte eingesehen und geändert werden, die Kontrolle über die internen Steuerregister des MK war jedoch bis vor kurzem unmöglich. In letzter Zeit sind sogenannte intelligente ROM-Emulatoren erschienen. Sie ermöglichen einen „Blick“ in den MC auf dem Board des Benutzers und ähneln in der Debugging-Steuerung dem VSE. Cactus präsentiert seinen eigentlich intelligenten ROM-Emulator sogar als VSE der MK-Serie, es ist so unmöglich, zwischen der Arbeit mit einem zu unterscheiden und das andere. Tatsächlich wird in diesem Fall der Prozessor nicht ersetzt, und derjenige, der auf die Benutzergebühr entfällt, wird verwendet. Der Smart-ROM-Emulator ist eine Mischung aus dem normalen ROM-Emulator. ein Debug-Monitor und ein System zum schnellen Umschalten des Busses von einem zum anderen. Dies erzeugt den Effekt, als ob der Debug-Monitor auf dem Board des Benutzers installiert wäre, und beansprucht gleichzeitig praktisch keine Hardware-Ressourcen vom MK, bis auf eine kleine (ca. 4 KB) Zone von Softwareschritten. Ein solcher Emulator wurde beispielsweise von der Firma Fiton für alle bestehenden und zukünftigen MKs entwickelt, die über den 8051-Kern verfügen, aber zusätzlich mit diversen Ein-/Ausgabegeräten gesättigt sind. Das Produkt unterstützt viele verschiedene MCs von Philips, Siemens. OKI. INTEGRIERTE ENTWICKLUNGSUMGEBUNGEN Streng genommen gehören integrierte Entwicklungsumgebungen nicht zu den Debugging-Tools. Es wäre jedoch falsch, diese Klasse von Softwaretools zu ignorieren, die den Prozess der Entwicklung und Fehlerbehebung von Mikroprozessorsystemen erheblich erleichtern und beschleunigen. Beim traditionellen Ansatz ist die Anfangsphase beim Schreiben eines Programms wie folgt aufgebaut. Der Quelltext wird mit einem Texteditor eingegeben. Nach Abschluss der Eingabe stoppt die Arbeit mit dem Texteditor und der Cross-Compiler startet. In der Regel enthält ein neues Programm Syntaxfehler und der Compiler meldet diese an die Bedienkonsole. Anschließend wird der Texteditor erneut gestartet und der Bediener sucht und behebt die erkannten Fehler. Gleichzeitig sind vom Compiler angezeigte Meldungen über deren Art nicht mehr sichtbar, da der Bildschirm von einem Texteditor belegt wird. Dieser Zyklus kann sich mehr als einmal wiederholen. Und wenn das Programm relativ komplex ist, aus verschiedenen Teilen zusammengesetzt ist, überarbeitet oder modernisiert werden muss, kann bereits diese Anfangsphase viel Aufwand und Zeit für den Programmierer erfordern. Um ein hohes Maß an Routinearbeit zu vermeiden und dadurch die Produktivität eines Programmierers deutlich zu steigern, sind sogenannte integrierte Entwicklungsumgebungen (Shells) der Entwicklung (Integrated Development Environment IDE) aufgetaucht und erfreuen sich zunehmender Beliebtheit. In der Regel kombiniert eine gute integrierte Umgebung die verfügbaren Debugging-Tools (In-Circuit-Emulator, Software-Simulator, Programmierer) und stellt dem Programmierer Programmtexte im „Turbo“-Stil zur Verfügung. Die integrierte Umgebung ermöglicht:
In letzter Zeit sind die Funktionen integrierter Entwicklungsumgebungen Teil der Programmierschnittstellen der „fortschrittlichsten“ Emulatoren und Debugger-Simulatoren geworden. Diese Funktionalität, kombiniert mit einer benutzerfreundlichen Oberfläche, beschleunigt die Arbeit des Programmierers erheblich. Daher ist es ratsam, bei der Auswahl von Debugging-Tools die folgenden Indikatoren zu berücksichtigen: die Liste der unterstützten Mikrocontroller, Einschränkungen der Ressourcen emulierter/simulierter Mikrocontroller, die Möglichkeit des symbolischen Debuggens, die Liste der unterstützten Compiler und, schließlich Servicefähigkeiten. Autoren: Yu.Zobnin, Sh.Kobakhidze, Moskau
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
▪ Enthüllte das Geheimnis der Langlebigkeit von Schildkröten ▪ Eine neue Form von amorphem Eis wurde erhalten ▪ Intel wird Fernsehern beibringen, Menschen zu erkennen
▪ Standortabschnitt Dosimeter. Artikelauswahl ▪ Artikel Wenn ich es nur wüsste, wenn ich es nur wüsste. Populärer Ausdruck ▪ Artikel Wo auf der Welt haben Bürger überhaupt keine Nachnamen? Ausführliche Antwort ▪ Artikel Leiter Tagesklinik. Jobbeschreibung ▪ Artikel Funkempfänger mit Feldeffekttransistoren. Enzyklopädie der Funkelektronik und Elektrotechnik ▪ Artikel Konverter 12/220 Volt. Enzyklopädie der Funkelektronik und Elektrotechnik
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