Externe Interrupts mit der UML

Die externen Interrupts wurden bereits mit den Sprachmitteln von C bearbeitet. Dieser Abschnitt soll das bereits Erläuterte kurz wiederholen und dieselbe Aufgabenstellung mit dem objektorientierten Paradigma und den Sprachmitteln der UML bewerkstelligen. Es lohnt in jedem Fall, sich auf einen direkten Vergleich der Effizienz der Ansätze einzulassen.

Um die Interrupt-Programmierung des XMC mit der UML kennenzulernen, nehmen wir uns eine bekannte Aufgabenstellung vor. Wir lassen eine LED über einen Digital-Port ein-, aus- bzw. umschalten.

Der Blick auf das bekannte Blockbild verrät uns, dass wieder die Bausteine ERU (Event Request Unit) und NVIC (Interruptcontroller) ordnungsgemäß initialisiert werden müssen. Fassen wir die Aufgabenstellung kurz objektorientiert zusammen:

  1. Klasse Taster mit geeigneten Basisklassen oder Templates
    1. an Pin1.15 als Eingang konfigurieren
    2. ERU konfigurieren
    3. NVIC initialisieren
    4. eine ISR schreiben
  2. Klasse Led mit geeigneten Basisklassen oder Templates
    1. an Pin1.0 als Ausgang konfigurieren

Falls Sie jetzt noch das Klassendiagramm geöffnet haben, wählen Sie im Kontextmenü (rechte Maustaste) des Diagramms den Menüpunkt nach oben. Falls das Projekt nicht mehr geöffnet ist, öffnen sie das SiSy UML-Projekt wieder. Legen Sie ein neues Klassendiagramm an und wählen Sie die Sprache ARM C++. Beachten Sie die Einstellungen für die Zielplattform XMC4500 Relax Kit. Beim Öffnen des Diagramms (rechte Maustaste, nach unten) laden Sie die Diagrammvorlage für eine PEC Applikation und fügen das Treiberpaket für den XMC4500 ein.

Die Controller der XMC-Familie verfügen, wie wir bereits wissen, über den NVIC und die ERU. Die ERU verknüpft Systembausteine mit dem NVIC und dem DMA-Line-Router, aber auch die Systembausteine untereinander und ist somit die entscheidende Schaltstelle für die Ereigniskonfiguration.

Vergegenwärtigen wir uns in der Übersicht noch mal welche Bausteine jetzt eine entscheidende Rolle spielen.

  • NVIC, Nested Vectored Interrupt Controller
  • ERU, Event Request Unit
  • GPIO-Ports, General Purpose I/O Ports

Die ERU ist verantwortlich, ein bestimmtes Ereignismuster (Pattern) zu erkennen und an einen Empfänger zu melden. Dazu gliedert sich die ERU in vier Blöcke:

  • ERU-Eingangslogik
    • ERS, Event Request Select, Empfang der Ereignisse von den Ereignisquellen
    • ETL, Event Trigger Logic, logische Verknüpfung der Ereignisquellen
  • ERU-Ausgangslogik
    • CCM, Cross Connect Matrix, Verknüpfung der Ereignisquellen mit dem Ausgabekanal OGU
    • OGU, Output Gating Unit, Verteilung/Senden der Ereignisse an Empfänger

Laut Aufgabenstellung ist einer der Taster auf dem Relax Kit zu nutzen. In der Übersicht ist zu erkennen, wie dieser eingangsseitig an die ERU angebunden werden kann.

Wie wir uns vielleicht noch erinnern, war der Schreibaufwand zur Konfiguration, vor allem der ERU (Event Request Unit), mit der Initialisierung der ETL (Eingangsseite) und der OGU (Ausgangsseite) doch recht erheblich. Dabei bestand die Aufgabe doch „nur“ darin, einen Interrupt für die fallende Flanke an Pin1.15 auszuwerten. Da wir jetzt mit einem Framework und der UML arbeiten, bietet es sich an zu schauen, ob sich für diese Aufgabe geeignete Basisklassen oder Templates finden lassen. Wir werden recht schnell im Paket pec_Gpio fündig.

Das Tempate PecPinInterrupt scheint für die gestellte Aufgabe geeignet zu sein. Es bietet eine Operation mit dem Namen onPinInterrupt zum überschreiben an. An diese Schnittstelle wollen wir uns dran hängen.

Wir benötigen, wie gehabt, eine LED, mit der wir das Unterbrechungsereignis visualisieren wollen. Die LED ist an Pin1.0 angeschlossen. Wir verwenden hier bereits bewährte Entwurfsmuster. Zusätzlich benötigen wir eine Taste, welche diesmal eine Realisierung von PecPinInterrupt sein soll.

In der Realisierung der Taste überschreiben wir die Operation onPinInterrupt

Das Template PecPinInterrupt bringt eine Reihe von Parametern mit. Diese sind bereits vorkonfiguriert bzw. werden durch die Zuweisung der Pin-Ressource parametrisiert. Eigentlich müssen Sie die Realisierungsparameter bei diesem Beispiel nicht mehr ändern. Das ist nur nötig, falls es bei der Programmierung mehrerer Ereignisquellen zu Konflikten bei der verwendeten OGU kommt. Sie können sich aber gern einmal in den Realisierungsparametern umschauen.

Es bleibt jetzt nur noch eins zu tun, das konkrete Verhalten beim Auslösen des Interrupts zu programmieren. Entsprechend der Aufgabenstellung schalten wir die LED bei jedem Tastenereignis an bzw. aus.

Taster::onPinInterrupt

app.led.toggle();

Übersetzen und übertragen Sie das Programm. Testen Sie die Anwendung.

Und hier diesen Abschnitt wiederum als Videozusammenfassung.

Erstellen Sie eine äquivalente Anwendung mit einem der Taster (z.B. Pin1.13) und einer LED (z.B. Pin2.1) auf dem Zusatzboard. Beachten Sie, dass der Taster auf dem Zusatzboard einen PullUp benötigt.