Externe Interrupts

while (1) {}

}

Ich habe die neuen Teile fett hervorgehoben.

Die neue Interrupt-Funktion wird das Hauptprogramm immer dann unterbrechen, wenn der ADC einen Interrupt ausgelöst hat. Dann können wir den gemessenen Wert direkt verarbeiten, ohne warten zu müssen. Auch brauchen wir das Interrupt-Flag nicht mehr zurück setzen, weil der ADC das beim Aufruf der Interrupt-Funktion schon automatisch macht (steht so im Datenblatt).

Damit der ADC überhaupt Interrupts auslöst, setzen wir beim Konfigurieren zusätzlich das ADIE-Bit. Außerdem müssen wir das globale Interrupt-Flag im Status Register des Prozessor-Kerns setzen, sonst würde die Interrupt-Funktion niemals aufgerufen werden. Auf das Status Register können wir in der Programmiersprache C nicht direkt zugreifen, daher gibt es zwei spezielle Funktionen:

• sei() „Set Interrupt-Flag“ setzt das Interrupt-Flag im Status Register

• cli() „Clear Interrupt-Flag“ löscht das Interrupt-Flag im Status Register

Wir setzen das Flag allerdings erst nach der Sekunde Wartezeit, damit unsere Interrupt Funkton nicht zu früh aufgerufen wird. Wir wollen die Messergebnisse des ADC ja erst nach Ablauf der Wartezeit auswerten.

Das Hauptprogramm ist nun ziemlich klein geworden. Es besteht nur noch aus einer leeren Endlosschleife. Das ist übrigens oft so. Viele Mikrocontroller-Programme sind komplett Interrupt-Gesteuert und ohne „richtiges“ Hauptprogramm.

6.11 Externe Interrupts

Mit externen Interrupts sind Signale von außerhalb des Mikrocontrollers gemeint, die Interrupt auslösen. Jeder Port-Pin kann einen Interrupt auslösen, wenn sich ein Signal von Low nach High oder umgekehrt ändert. Das funktioniert sowohl bei Eingängen als auch bei Ausgängen.

Darüber hinaus haben AVR Mikrocontroller spezielle Eingänge mit Name INT0, INT1, usw. bei denen man etwas feiner konfigurieren kann, wann sie einen Interrupt auslösen sollen. Und zwar hat man dort diese Auswahlmöglichkeiten:

• Interrupt wird wiederholt ausgelöst, solange der Eingang auf Low ist.

• Ein Signalwechsel löst den Interrupt aus (wie bei jeden anderen Port-Pin).

• Interrupt wird ausgelöst, wenn der Eingang von High nach Low wechselt.

• Interrupt wird ausgelöst, wenn der Eingang von Low nach High wechselt.

6.11.1 Programmierung

Das folgende Programm kannst du sehr schön im Debugger ausprobieren.

#include <avr/io.h>

GIMSK = (1<<PCIE); // Interrupts für diese Pins erlauben sei(); // Interrupts global erlauben

„ISR(PCINT0_vect)“. Wenn der Interrupt auftritt, soll sie die LED an PB0 einschalten.

Im Hauptprogramm werden zunächst die drei Ports PB0, PB1 und PB2 als Ausgang konfiguriert.

Dann wird die Auslösung von Interrupts für die beiden Pins PB1 und PB3 aktiviert.

Als nächstes setzt das Programm den Ausgang PB1 auf High. Dadurch wird von diesem Pin ein Interrupt ausgelöst. Das Hauptprogramm wird unterbrochen und die Interrupt-Funktion wird ausgeführt. Danach wird das Hauptprogramm fortgesetzt.

In diesem Fall liest das Hauptprogramm einfach immer wieder von PINB ohne den Wert jedoch weiter zu verarbeiten. Ich habe das gemacht, weil der Simulator sich mit leeren Schwer tut. So lässt sich das Programm besser im Simulator ausprobieren. Genau das tun wir jetzt:

Drücke F7, um das Programm zu kompilieren. Klicke dann auf den Menüpunkt Debug/Start Debugging um die Simulation zu starten:

Drücke dann F11 so oft, bis der gelbe Pfeil auf die oben dargestellte Zeile zeigt. Das Interrupt-System ist nun bereit, ausgelöst zu werden. Wenn du jetzt noch einmal F11 drückst, wechselt der Pin PB1 von Low nach High.

Wenn du jetzt noch ein paar mal F11 drückst, wirst du sehen, dass das Hauptprogramm einmal durch die Interrupt-Funktion unterbrochen wird.

Wenn du ganz genau hinschaust, fällt dir auch auf, dass der Signalwechsel von PB1 nicht sofort zum Interrupt führt, sondern erst 2 Takte verzögert. Das ist so in Ordnung, denn dies geht auch aus dem Diagramm im Kapitel „Pin Change Interrupt Timing“ des Datenblattes hervor.

6.11.2 Zugriff auf Variablen durch Interrupt-Routinen

Wenn du Variablen sowohl innerhalb als auch außerhalb von Interrupt-Funktionen veränderst, kann es zu einem Konflikt kommen:

Wenn das Hauptprogramm ausgeführt wird, kann folgendes unerwünschte Szenario passieren:

• Angenommen, die Variable zaehler hat gerade den Wert 400.

• Die Variable „zaehler“ wird in ein Prozessor-Register geladen, weil arithmetische Operationen nicht direkt im RAM ausführbar sind.

• Dann wird das Register um 100 erhöht, also auf 500.

• Dann wird das Hauptprogramm durch einen Interrupt unterbrochen.

• Die Interrupt-Routine erhöht den Wert der Variable um 1, also auf 401.

• Das Hauptprogramm wird fortgesetzt.

• Das Hauptprogramm schreibt den Wert des Registers zurück in die Variable.

• Die Variable hat jetzt den Wert 500, richtig wäre aber 501 gewesen.

Auch wenn du Ausdrücke wie „zaehler+=100“ verwendest, tritt der gleiche Fehler gelegentlich auf.

Du kannst sie Situation verbessern, indem du dem Prozessor an der kritischen Stelle verbietest, das Programm zu unterbrechen:

…

Es gibt noch ein anderes recht häufiges Konflikt-Szenario:

uint8_t weitermachen=1;

Bei dem obigen Programm geht es darum, dass das Hauptprogramm immer wieder etwas machen soll, solange die Variable „weitermachen“ den Wert 1 hat. Irgendein Ereignis (z.B. ein elektrisches Signal von außen) löst den Interrupt aus, und dann wird die Variable auf 0 gesetzt. Die while Schleife soll dann beendet werden.

So wie das Programm oben geschrieben ist, wird es nicht wie erwartet funktionieren, denn der Optimierer verändert den Programmcode ungefähr so:

uint8_t weitermachen=1;

Der Optimierer kopiert die Variable in ein Prozessor-Register, weil der wiederholte Zugriff auf Register schneller geht, als der wiederholte Zugriff auf eine Variable, die im RAM liegt. Das hat sich der Compiler ganz nett gedacht, aber in diesem Fall führt es dazu, dass die while Schleife niemals endet. Denn die Schleife prüft nun immer wieder den Wert von R2, während beim Interrupt aber nur der Wert von „weitermachen“ geändert wird.

Dieses Problem kannst du lösen, indem du die Variable als „volatile“ deklarierst:

volatile uint8_t weitermachen=1;

Durch das Schlüsselwort „volatile“ teilst du dem Compiler mit, dass er den Zugriff auf diese Variable nicht optimieren darf. Damit verhält sich das Programm wie erwartet. Generell ist es keine schlechte Idee, alle Variablen als „volatile“ zu deklarieren, die von Interrupt-Funktionen verändert werden und außerhalb der Interrupt-Funktionen gelesen werden.