Welchen Vorteil haben Kern-unabhängige Peripheriegeräte (Core independent peripherals, CIPs) für eine Anwendung? Sie ermöglichen Benutzern die Automatisierung von bestimmten Aufgaben, die normalerweise von der zentralen Verarbeitungseinheit basierend auf Anweisungen in der Software ausgeführt werden. Bei Verwendung von CIPs müssen Entwickler auch weniger Code schreiben und können dabei ein reaktionsschnelleres, energiesparendes System entwickeln. In diesem Video von Microchip wird detailliert erklärt, was CIPs sind, wie sie eingesetzt werden und welche Vorteile sie für Ihr Projekt bringen.
Danke für Ihr Interesse. Diesmal wird Marc McComb Ihnen Kern-unabhängige Peripheriegeräte detailliert vorstellen.
Wie Sie vielleicht wissen, sind sowohl PIC- als auch AVR-Mikrocontroller-Architekturen mit zahlreichen Peripheriegeräten ausgestattet. Viele davon bezeichnen wir als Kern-unabhängige Peripheriegeräte, kurz CIPs. Diese Peripheriegeräte wurden zur Automatisierung von bestimmten Aufgaben entwickelt, die normalerweise von der zentralen Verarbeitungseinheit oder kernbasierten Anweisungen im Softwarecode ausgeführt werden.
Diese Kern-unabhängigen Peripheriegeräte bergen inhärente Vorteile wie einen geringeren Codeumfang und gleichzeitig reaktionsschnelleren, energiesparenden Systemen. Ich möchte Ihnen in diesem Video kurz vorstellen, welche Vorteile Kern-unabhängige Peripheriegeräte für eine Anwendung bringen.
Hierfür verwende ich ein einfaches Beispiel, in dem ich einen E/A-Port-Pin hoch und runter schalten möchte, also im Prinzip ein Rechtecksignal, ein sogenanntes Heartbeat-Signal erzeuge. Um dieses Heartbeat-Signal zu erzeugen, habe ich Code geschrieben, um die Ausgabe in einer Schleife wiederholt hoch und runter zu schalten, wie in diesem Flussdiagramm zu sehen ist.
Jetzt füge ich dieser Anwendung eine weitere Aufgabe hinzu. Angenommen, wir möchten jedes Mal, wenn ein Druckknopf, der mit einem anderen Pin auf dem Mikrocontroller verbunden ist, gedrückt wird, einen Ausgabepuls mit einer Länge von zwei Millisekunden an wiederum einem anderen Pin generieren, also eine Art einmaliger Auslöser oder einem monostabilen Multivibrator.
Wenn wir jetzt einen Mikrocontroller mit rudimentären Peripheriegeräten haben, müssen wir diese zusätzliche Aufgabe mit Interrupts implementieren. Dies könnte etwa so aussehen. Hier verwende ich ein grundlegendes Timer-Peripheriegerät sowie einen allgemeinen E/A-Port, der mit einem Druckknopf verbunden ist. Die meisten dieser Peripheriegeräte können gängige Interrupts erzeugen, wie Sie auf den meisten modernen Mikrocontrollern zu finden sind.
Der erste Interrupt, den ich verwende, kann vom E/A-Peripheriegerät erzeugt werden, wenn sich die Spannung auf einem zugeordneten Pin ändert. Wenn also der Druckknopf betätigt wird, fällt die Pinspannung auf null Volt, da ich den Druckknopf hier auslöse und ein Interrupt ausgelöst wird. Wenn der Kern benachrichtigt wird, dass ein E/A-Port-Interrupt ausgelöst wurde, wird entweder auf Softwareebene oder, falls der Mikrocontroller entsprechend ausgestattet ist, auf Hardwareebene eine Priorisierungsprüfung ausgeführt.
Dadurch wird sichergestellt, dass nicht gleichzeitig ein anderes Interrupt-Ereignis stattfindet, das Priorität vor diesem E/A-Port-Interrupt hat. Ist dies nicht der Fall, ruft der Kern die Serviceroutine des E/A-Port-Interrupts auf. Innerhalb der Serviceroutine wird der Kern angewiesen, den Timer zurückzusetzen, ihn mit einem bestimmten Wert zu laden, damit er bei genau zwei Millisekunden überläuft, und der Timer beginnt zu zählen.
Außerdem wird der Kern angewiesen, den Ausgabepin hochzufahren. Dadurch wird die steigende Flanke unseres einmaligen Signals erzeugt. Wenn die Serviceroutine für den Port-Interrupt abgeschlossen ist, kann der Kern wieder mit seiner ursprünglichen Aufgabe, in unserem Fall das Auslösen unseres Heartbeat-Signals, zurückkehren. Der Kern schaltet also weiterhin das Heartbeat-Signal, bis der Timer bei unseren konfigurierten zwei Millisekunden überläuft und ein Interrupt ausgelöst wird, wie bei der in Hardware oder Software implementierten E/A-Port-Interrupt-Priorisierung, und – sofern keine anderen Interrupts mit höherer Priorität vorliegen – die Serviceroutine für den Timer-Interrupt aufgerufen wird.
Der Kern erhält eine Anweisung aus dem Code, setzt den Timer zurück und hält ihn an und fährt dann unser einmaliges Signal herunter. Dieser Code ist also nicht übermäßig komplex. Es gilt jedoch zu beachten, dass alle diese Schritte – vom Auftreten des Interrupt-Ereignisses bis zu dessen Erkennung, Priorisierung und Ausführung der zugehörigen Hardware-Serviceroutine – Zeit braucht, während derer der Kern unser Heartbeat-Signal nicht auslösen kann.
Sehen wir uns das einmal genauer an. Ich habe den Code für diese Anwendung geschrieben und ihn in einen Mikrocontroller heruntergeladen. Ich habe ein Oszilloskop mit zwei Ausgabepins verbunden. Dieses blaue Signal hier ist unser vom Kern erzeugtes Heartbeat-Signal, das den Pin jedes Mal durch die Schleife auslöst. Sehen Sie sich an, was passiert, wenn ich den Druckknopf betätige und den Port-Interrupt auslöse. Wie Sie hier sehen, fehlen in unserem Heartbeat-Signal jetzt einige Pulse direkt vor und nach der steigenden Flanke des einmaligen Pulses und kurze Zeit vor und nach der absteigenden Flanke.
Der Druckknopf wird etwa hier betätigt. Und diese Verzögerung vor der ersten Flanke des einmaligen Pulses resultiert aus mehreren Faktoren, darunter die Interrupt-Latenz. Diese bezeichnet die Dauer, bis der Kern einen Interrupt tatsächlich erkennt. Ein Großteil dieser Verzögerung liegt jedoch an unserer Interrupt-Priorisierung und dem tatsächlichen Ausführungscode innerhalb unserer Interrupt-Subroutinen.
Außerdem sehen Sie eine Verzögerung, nachdem der einmalige Puls ansteigt, bevor der Kern unser Heartbeat-Signal tatsächlich wieder auslöst. Wir erhalten also hier noch einige Pulse und dann unterbricht der Timer nach zwei Millisekunden. Und wieder hört der Kern, sobald er den Interrupt erkannt hat, auf, das Heartbeat-Signal zu erzeugen, und durchläuft die Priorisierung und springt dann in die Serviceroutine für den Timer-Interrupt, wo unser einmaliger Pin letztlich heruntergefahren wird.
Hier haben wir also eine sehr einfache Anwendung, in der wir einen E/A in der Software umschalten. Nun stellen Sie sich aber einmal vor, dass wir statt eines Heartbeat-Signals ein Eingabesignal umschalten, das der Kern erkennen muss. Dies kann beispielsweise eine Benutzereingabe wie ein kapazitiver Berührungssensor oder ein noch dringenderes Signal sein, beispielsweise bei einer Systemüberhitzung oder einer potenziellen Gefahr für den Benutzer.
Es kann also sein, dass der Kern gerade einen Interrupt ausführt und dieses Signal verpasst. Dies kann von einem genervten Benutzer bis hin zu katastrophalen Folgen für das System alles zur Folge haben. Dieses Risiko lässt sich durch Erhöhen der Betriebsgeschwindigkeit minimieren, sodass Interrupts schneller vom Kern abgearbeitet werden. Beachten Sie jedoch, dass dadurch auch der Stromverbrauch ansteigt. Und der schnellere Betrieb minimiert diese Unterbrechung im Heartbeat-Signal zwar, eliminiert sie jedoch nicht völlig.
Wir können unseren Anwendungsentwickler auch bitten, mehr Zeit in Benchmark-Tests der Anwendung zu investieren, indem er verschiedene Softwareroutinen schreibt oder die anderen Systemkomponenten optimiert, um die Situation zu verbessern. Doch Zeit ist Geld. Wenn ein Entwickler also noch mehr Zeit in das Schreiben von Code investiert oder unterschiedliche Konfigurationen für Sekundärsysteme ausprobiert, die mit dem Mikrocontroller verbunden sind, kann dies ziemlich kostspielig werden.
Sehen wir uns also eine andere Lösung an, bei der wir Kern-unabhängige Peripheriegeräte verwenden. Hier ist der ATTINY817 und das ist ein AVR-Gerät, das unter anderem mit einem Timer-basierten Peripheriegerät, einem sogenannten Timer/Counter Typ B, kurz TBC, und einem weiteren Peripheriegerät, einem sogenannten Ereignissystem, verbunden ist. Das Ereignissystem-Peripheriegerät kann ein Ereignis, das irgendwo im Mikrocontroller erzeugt wird, verwenden, um ein anderes Ereignis im selben Mikrocontroller auszulösen.
Wenn also beispielsweise eine Spannung, die mit einem Eingabepin unseres Komparators verbunden ist, einen festgelegten Schwellenwert überschreitet, kann die Komparatorausgabe so konfiguriert werden, dass sie ansteigt. Mimt dem Ereignissystem können wir diese Komparatorausgabe dann nutzen, um eine Spannung auf einem weiteren Pin von analog zu digital zu konvertieren.
Oder ein Zähler kann durch ein externes Signal wie das Betätigen eines Druckknopfs, der mit einem Port-Pin verbunden ist, ausgelöst werden und anfangen zu zählen. Ein Zähler wie das 16-Bit-Timer/Counter Typ B- oder TCB-Peripheriegerät auf dem ATTINY817 verfügt über einen Einzelgenerierungsmodus, der bei Auslösung einen Puls mit benutzerdefinierter Dauer ausgibt.
Diesen Mechanismus nutze ich nun, um unsere einmalige Ausgabe zu erzeugen. Der mit dem Druckknopf in unserem Design verbundene Port-E/A wird mit dem Ereignissystem an den Timer/Counter Typ B geleitet, sodass eine Änderung der Eingabe für diesen Pin diese einzelne Ausgabe auslöst. Die Implementierung dieser Funktion in unsere Anwendung sieht in etwa wie folgt aus.
Auch hier wird der Mikrocontroller-Kern verwendet, um das Heartbeat-Signal auf dem E/A-Pin umzuschalten. Diesmal verlassen wir uns jedoch nicht auf Interrupts im Kern, um unseren einmaligen Puls hochzufahren, sondern leiten das Änderungsereignis an unseren Port-Pin weiter, der mit dem Druckknopf über das Ereignissystem verbunden ist, und verbinden ihn mit unserem Timer/Counter Typ B, sodass ein Ausgabepuls für zwei Millisekunden ausgelöst wird.
Wie Sie an diesem Blockdiagramm sehen, werden dem Kern letztlich alle Aufgaben abgenommen, die mit dem Erkennen des Betätigens des Druckknopfs und dem Ausführen der einmaligen Ausgabe zusammenhängen. Diese Aufgaben werden über die Peripheriegeräte auf Hardwareseite ausgeführt. Ich habe den ATTINY817 mit dieser Anwendung programmiert. Sehen wir uns nun einmal die Wellenformen an.
Und wieder haben wir hier unseren Wechsel-E/A-Pin, der vom Kern gesteuert wird. Der Unterschied liegt darin, dass beim Betätigen des mit der Eingabe verbundenen Druckknopfs der zwei Millisekunden lange Ausgabepuls auf Hardwareebene von den Peripheriegeräten verarbeitet wird und sich nicht mehr auf das Heartbeat-Signal auswirkt, da der Kern nicht unterbrochen wird. Wenn Aufgaben auf Hardwareebene mit Peripheriegeräten statt auf Softwareebene verarbeitet werden, kann der Kern nun parallel andere Aufgaben ausführen, beispielsweise das Ausführen des Codes für den Heartbeat oder er kann sogar in den Energiesparmodus wechseln.
Vor allem haben wir nicht nur die Reaktionsgeschwindigkeit unseres Systems gesteigert, indem wir Software und Interrupts beseitigt haben, die den Kern binden – auch die Betriebsgeschwindigkeit konnte niedriger gehalten werden, um Strom zu sparen. Eine letzte Sache möchte ich Ihnen noch zeigen. Wir wollten schließlich, dass unser Ausgabepuls genau zwei Millisekunden lang ist.
Sehen wir uns jedoch einmal die Version dieser Anwendung mit Interrupt auf Softwareebene an. Wir konfigurieren den Timer, um einen Interrupt genau bei zwei Millisekunden zu erzeugen. Durch die Interrupt-Latenz und die Zeit, die zum Ausführen des Codes für die Interrupt-Serviceroutinen usw. benötigt wird, ist unser Ausgabepuls tatsächlich etwa 300 Millisekunden länger als gewünscht.
Sehen Sie sich einmal die mit den ATTINY817-Peripheriegeräten erzeugte Wellenform an. Wie Sie sehen, ist die Ausgabe genau zwei Millisekunden lang, da diese Aufgabe auf Hardwareebene ausgeführt wird und ohne den Overhead der Software und Interrupts auskommt. Diese Version mit Peripheriegeräten wurde mit den grafischen Programmiertools von Microchip Technology innerhalb kürzester Zeit entwickelt. Diese Tools stellen die Peripheriegeräte auf hoher Ebene dar, um die Anwendungsentwicklung mit PIC- und AVR-Mikrocontrollern zu vereinfachen.
Auf diese Tools und mehr werde ich in weiteren Videos eingehen. Weitere Informationen zu diesen und anderen Themen finden Sie auf www.microchip.com/8bit. Mein Name ist Marc McComb. Vielen Dank für Ihre Aufmerksamkeit.