Interrupt-Klasse für ATXMegas

[Nicolas G. (Gast)]

Hi Leute,

ich habe mir eine hübsche Klasse geschrieben, die es mir ermöglicht bei 
OOP-Projekten komfortabler mit Interrupts umgehen zu können.

Zunächst mal die Klasse selbst. Sie ist aufgesplittet in eine .h- und 
eine .cpp-Datei.

InterruptHelper.h

/*
 * InterruptHelper.h
 *
 *  Created on: 30.07.2014
 *      Author: nicolas
 */

#ifndef INTERRUPTHELPER_H_
#define INTERRUPTHELPER_H_

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>

#if (_VECTORS_SIZE / _VECTOR_SIZE > 255)
  typedef uint16_t INTERRUPT_NUM_t;
#else
  typedef uint8_t INTERRUPT_NUM_t;
#endif

class Interrupt;

// Eine Art LinkedList, falls mehrere Instanzen auf einen Interrupt reagieren sollen.
struct interruptFunc_t {
    Interrupt* interrupt;
    interruptFunc_t* next;
};

extern interruptFunc_t interruptFunctions[_VECTORS_SIZE / _VECTOR_SIZE];

class Interrupt {
  private:
    INTERRUPT_NUM_t vectorNum;

  public:
    Interrupt() {
      vectorNum = -1;
    }

    virtual ~Interrupt() {
      if (vectorNum >= 0) {
        removeFromInterrupt();
      }
    }

    void addToInterrupt(INTERRUPT_NUM_t vectorNum) {
      this->vectorNum = vectorNum;
      interruptFunc_t* e = &interruptFunctions[vectorNum];
      if (e->interrupt) {
        while (e->next) {
          e = e->next;
        }
        e->next = (interruptFunc_t*) malloc(sizeof(interruptFunc_t));
        e->next->interrupt = this;
        e->next->next = 0;
      } else {
        e->interrupt = this;
        e->next = 0;
      }
    }

    void removeFromInterrupt() {
      interruptFunc_t* e = &interruptFunctions[vectorNum];
      if (e->interrupt == this) {
        if (e->next) {
          e->interrupt = e->next->interrupt;
          interruptFunc_t* tmp = e->next->next;
          e->next = tmp;
          free(tmp);
        }
      } else {
        interruptFunc_t* previous = e;
        e = e->next;
        while (e) {
          if (e->interrupt == this) {
            previous->next = e->next;
            free(e);
            break;
          }
          previous = e;
          e = e->next;
        }
      }
    }

    virtual void interrupt() {
    }
};

#endif /* INTERRUPTHELPER_H_ */

InterruptHelper.cpp

/*
 * InterruptHelper.cpp
 *
 *  Created on: 30.07.2014
 *      Author: nicolas
 */

#include "InterruptHelper.h"

interruptFunc_t interruptFunctions[_VECTORS_SIZE / _VECTOR_SIZE];

#define declareISR(name)  ISR(name, ISR_BLOCK) { \
                interruptFunc_t* e = &interruptFunctions[name##_num]; \
                if (e->interrupt) { \
                  e->interrupt->interrupt(); \
                  while (e->next) { \
                    e = e->next; \
                    if (e->interrupt) { \
                      e->interrupt->interrupt(); \
                    } \
                  } \
                } \
              } \


/*
 * Im folgenden Abschnitt einfach alle Intrrupts deklarieren, die später mal
 * genutzt werden sollen.
 */
declareISR(TCD1_OVF_vect)
declareISR(TCD1_ERR_vect)

// Nachfolgend ein Beispiel
#if false
class InterruptExample : Interrupt {
  InterruptExample() {
    addToInterrupt(TCD1_OVF_vect_num);
  }

  void interrupt() {
    /* Diese Methode wird ausgeführt, sobald der
     * entsprechende Interrupt ausgeführt wird.
     */
  }
};


/* Nachfolgend ein Beispiel wie man innerhalb einer Klasse
 * auf unterschiedliche Interrupts reagieren kann.
 */
class MyClass {
    class Interrupt1 : public Interrupt {
        MyClass* parent;

        Interrupt1(MyClass* _parent) : parent(_parent) {
          addToInterrupt(TCD1_OVF_vect_num);
        }

        void interrupt() {
          parent->interrupt1();
        }
    };

    class Interrupt2 : public Interrupt {
        MyClass* parent;

        Interrupt2(MyClass* _parent) : parent(_parent) {
          addToInterrupt(TCD1_ERR_vect_num);
        }

        void interrupt() {
          parent->interrupt2();
        }
    };

    Interrupt1* int1;
    Interrupt2* int2;

    MyClass() {
      int1 = new Interrupt1(this);
      int2 = new Interrupt2(this);
    }

    void interrupt1() {
      // Wird aufgerufen bei TCD1_OVF_vect
    }
    void interrupt2() {
      // Wird aufgerufen bei TCD1_ERR_vect
    }
};
#endif

In der .cpp-Datei befinden sich auch zwei ausgeklammerte Beispiele, die 
verdeutlichen sollen wie die Klasse funktioniert.

Hat man also eine Klasse geschrieben, die auf genau einen Interrupt 
reagieren soll, so erbt man einfach von der Klasse 'Interrupt', 
definiert den Interrupt, auf den man reagieren will, im Konstruktor und 
überschreibt dann die Methode 'void interrupt()'.

Möchte man innerhalb einer Klasse auf mehr als einen Interrupt reagieren 
können, muss man Unterklassen erstellen, die wiederum die Methoden aus 
der Hauptklasse aufrufen.

Es ist keine gute Idee einfach alle Interrupt zu deklarieren, die es 
gibt. Also man sollte nicht einfach alle möglichen 
'declareISR()'-Varianten einbauen, die man finden kann, da das zu viel 
Flash-Speicher benötigt. Wenn man den Speicher natürlich hat, spricht 
nicht unbedingt etwas dagegen.

Ich hoffe euch gefällt das Konstrukt. Über Kritik und 
Verbesserungsvorschläge freue ich mich aber trotzdem. Ich hoffe hier 
entfacht jetzt keine Diskussion darüber wie sinnvoll es ist mit OOP auf 
einem AVR zu hantieren.

[c-hater (Gast)]

Nicolas G. schrieb:

> ich habe mir eine hübsche Klasse geschrieben, die es mir ermöglicht bei
> OOP-Projekten komfortabler mit Interrupts umgehen zu können.

Du hast einen Fehler gemacht...

> Es ist keine gute Idee einfach alle Interrupt zu deklarieren, die es
> gibt. Also man sollte nicht einfach alle möglichen
> 'declareISR()'-Varianten einbauen, die man finden kann, da das zu viel
> Flash-Speicher benötigt.

Und das zeigt ihn überdeutlich...

Mehr ist dazu eigentlich nicht zu sagen.

OO ist nett (für den Programmierer) auf fetten Systemen mit viel 
Reserven. Ja ich gebe zu, daß auch ich auf solchen Zielsystemen 
größtenteils reinen OO-Code produziere (allerdings nur unter 
fürchterlichem Zwang in C++, wenn schon gemütlich, dann richtig 
gemütlich: also "managed" Code).

Aber auf Systemen mit eng begrenzten Resourcen knallt der Overhead 
einfach viel zu stark rein. Und das nicht nur bezüglich des 
Speicherbedarfs. Mach einfach mal eine Analyse bezüglich des 
Rechenzeitbedarfs deines OO-Konstruktes. DEN Overhead braucht man echt 
nicht, ganz sicher jedenfalls nicht in ISRs. Da ist oft genug schon der 
Overhead der Runtime von plain C schon Show-Stopper.

[Moby (Gast)]

Nicolas G. schrieb:
> Ich hoffe hier
> entfacht jetzt keine Diskussion darüber wie sinnvoll es ist mit OOP auf
> einem AVR zu hantieren.

Oh ja, die wär aber bitter nötig... Natürlich aus Performance- und 
Platzgründen. Und als Asm-Progger stell ich mir natürlich auch gleich 
die Frage, warum es komplizierte Konstrukte wie diese hier für 
Interrupts braucht, wo solche doch oft aus nur wenigen Assemblerzeilen 
bestehen (können).

[Nicolas G. (Gast)]

Ich kenne die Nachteile. Aber bei unserem Quadcopter sind die größten 
Geschwindigkeitsfresser die Fließkommaberechnungen. Die Klassen werden 
scheinbar gut umgesetzt. Wobei natürlich keine Lust hatte das mit einer 
reinen C-Version zu vergleichen. Immerhin müsste ich dann alles 
umschreiben.
Das einzige, was noch in C geschrieben ist, ist die main-Methode. Die 
wird aber am Ende eh noch mal aufgeräumt.

Falls es dich interessiert: https://github.com/NicolasGoeddel/Quadcopter

[Moby (Gast)]

Nicolas G. schrieb:
> Aber bei unserem Quadcopter sind die größten
> Geschwindigkeitsfresser die Fließkommaberechnungen. Die Klassen werden
> scheinbar gut umgesetzt.

Na das zeigt ja wenigstens wieder mal die Leistungsfähigkeit der 
AVR/Xmegas ;-)

[c-hater (Gast)]

Nicolas G. schrieb:

> bei unserem Quadcopter sind die größten
> Geschwindigkeitsfresser die Fließkommaberechnungen.

Dann wäre es doch sinnvoll, den Fließkommascheiß auszumerzen. Das ist in 
aller Regel nur eine Krücke für Programmierer, die zu faul oder zu doof 
sind, die Wertebereiche ihrer Algorithmen gut genug abschätzen zu 
können.

Aber OK, es gibt Ausnahmen von dieser Regel. Wenn du mir nachweist, daß 
du in deinem Copter zwingend einen solchen Algorithmus mit nicht 
abschätzbarem Wertebereich verwenden mußt, dann darfst du ungestört 
weiter mit dem Werkzeug der Dummen und Faulen arbeiten...

Um aber auf's Thema zurückzukommen: ISRs bringen bei hinreichend 
häufigem Aufruf der ISR absolut *jedes* System zum Erliegen. Und 
selbst wenn die Aufruffrequenz nicht derart hoch ist: Jeder in einer ISR 
sinnlos verschwendete Takt fehlt genau mit der Häufigkeit ihres Aufrufs 
an jeder anderen Stelle des Systems.

Also: Nur 10 Takte in einer ISR sinnlos verschwendet und diese ISR 
100000mal pro Sekunde aufgerufen, mindert den effektiv nutzbaren 
Systemtakt schon um ein ganzes 1MHz.

Das kann doch nicht so schwer zu verstehen sein, oder?

[Peter II (Gast)]

Nicolas G. schrieb:
> Ich kenne die Nachteile.

ist ja nicht nur das C++. Schon das malloc zieht haufenweise Probleme 
nach sich. So mal du nicht mal eine Fehlerbehandlung eingebaut hast.

Und wie wahrscheinlich ist es wohl das man Interrupts zur Laufzeit ein 
oder aushängt?

Wenn überhaupt sollte man das als Template und alles static umsetzen, 
dann dürfte der Overhead sehr gut zu vermeiden sein.

Auch die Stabilität vom removeFromInterrupt wage ich zu bezweifeln, wenn 
gleichzeitig auch Interrupts auftreten.

[Peter D. (peda)]

Nicolas G. schrieb:
> ich habe mir eine hübsche Klasse geschrieben, die es mir ermöglicht bei
> OOP-Projekten komfortabler mit Interrupts umgehen zu können.

Kannst Du mal erläutern, worin der Komfort besteht.

Warum soll ich erst eine Zwischeninstanz schreiben müssen und nicht 
einfach gleich:

ISR( PCINT1_vect )
{
  // Code
}

Ich vermute mal stark, daß diese ganze Pointerei nicht zur Compilezeit 
aufgelöst werden kann und daher ein erheblicher Overhead an Flash, RAM 
und CPU-Belastung entsteht.

[Dr. Sommer (Gast)]

Nicolas G. schrieb:
> while (e->next) {
>           e = e->next;
>         }
>         e->next = (interruptFunc_t*) malloc(sizeof(interruptFunc_t));
>         e->next->interrupt = this;
>         e->next->next = 0;
Füg doch am Anfang der Liste ein, das ist dann O(1) und nicht O(n).

Nicolas G. schrieb:
> e->next = (interruptFunc_t*) malloc(sizeof(interruptFunc_t));
Warum "malloc" und nicht "new"?

Was auch interessant wäre, statt virtueller Funktionen std::function zu 
verwenden. Dann könnte man auch Lambdas hinzufügen, zB so:

int main () {
  Interrupts::add (TCD1_ERR_vect_num, [] () {  /* do something */ });
}

Dazu müsste diese add Funktion ein std::function<void()> entgegennehmen 
und in die Linked List einfügen. Beim Interrupt dann die Liste 
durchgehen und den operator() auf den std::function Objekten aufrufen.

[Nicolas G. (Gast)]

c-hater schrieb:
>> bei unserem Quadcopter sind die größten
>> Geschwindigkeitsfresser die Fließkommaberechnungen.
>
> Dann wäre es doch sinnvoll, den Fließkommascheiß auszumerzen. Das ist in
> aller Regel nur eine Krücke für Programmierer, die zu faul oder zu doof
> sind, die Wertebereiche ihrer Algorithmen gut genug abschätzen zu
> können.
>
> Aber OK, es gibt Ausnahmen von dieser Regel. Wenn du mir nachweist, daß
> du in deinem Copter zwingend einen solchen Algorithmus mit nicht
> abschätzbarem Wertebereich verwenden mußt, dann darfst du ungestört
> weiter mit dem Werkzeug der Dummen und Faulen arbeiten...

Zeig mir schöne Routinen, mit denen mein atan schneller wird und genau 
genug bleibt. Außerdem hätte ich dann gerne noch Routinen, die den 
Komplementärfilter und die PID-Regelung sauber ohne Fließkommazahlen 
berechnen.
Und da wir schon bei Beleidigungen angekommen sind: Du bist wohl selber 
dumm, wenn du so eine Gülle schreibst.
Schau dir einfach mal andere Quadrocopter-Projekte an. Die nutzen auch 
alle floats. Außerdem habe ich ja noch Rechenzeit übrig. Der Xmega darf 
ruhig arbeiten. Der muss nicht idlen.


Peter II schrieb:
> Nicolas G. schrieb:
>> Ich kenne die Nachteile.
>
> ist ja nicht nur das C++. Schon das malloc zieht haufenweise Probleme
> nach sich. So mal du nicht mal eine Fehlerbehandlung eingebaut hast.

Es sind noch nicht alle Dinge abgesichert. Aber ich bin hier ja auch 
sozusagen noch in der Alpha-Phase.

Dr. Sommer schrieb:
> Nicolas G. schrieb:
>> while (e->next) {
>>           e = e->next;
>>         }
>>         e->next = (interruptFunc_t*) malloc(sizeof(interruptFunc_t));
>>         e->next->interrupt = this;
>>         e->next->next = 0;
> Füg doch am Anfang der Liste ein, das ist dann O(1) und nicht O(n).

*Kopf->Tisch* Du hast natürlich Recht. Lag wohl an der späten Uhrzeit. 
:D Hintergrund war wahrscheinlich, dass ich wollte, dass die Interrupts 
auch in der Reihenfolge ausgeführt werden, in der sie sich eingeklingt 
haben.
Und bezüglich der Lambdas: Das habe ich so noch nie gemacht. Klingt aber 
interessant, wenn das mit avr-g++ geht.

Peter Dannegger schrieb:
> Kannst Du mal erläutern, worin der Komfort besteht.
>
> Warum soll ich erst eine Zwischeninstanz schreiben müssen und nicht
> einfach gleich:ISR( PCINT1_vect )
> {
>   // Code
> }
> Ich vermute mal stark, daß diese ganze Pointerei nicht zur Compilezeit
> aufgelöst werden kann und daher ein erheblicher Overhead an Flash, RAM
> und CPU-Belastung entsteht.

Eine statische Funktion weiß nichts über die Datenstruktur, auf der sie 
arbeiten soll. Man müsste diese also auch global machen. Von der 
Interrupt-Klasse oben wird einem das abgenommen und man hat automatisch 
Zugriff auf alle Klassen-Attribute und weitere Methoden.

Moby schrieb:
> Nicolas G. schrieb:
>> Aber bei unserem Quadcopter sind die größten
>> Geschwindigkeitsfresser die Fließkommaberechnungen. Die Klassen werden
>> scheinbar gut umgesetzt.
>
> Na das zeigt ja wenigstens wieder mal die Leistungsfähigkeit der
> AVR/Xmegas ;-)

Naja, was willst du ohne FPU anders machen. ;) Mit reiner 
Ganzzahlarithmetik komme ich nicht besonders weit. Das habe ich damals 
schon mit dem PID-Regler versucht und die Wertebereiche waren einfach zu 
groß. Das nimmt mir der float-Typ eben alles ab.

Falls es interessiert: Im Anhang ist der grobe Ablauf der Regelung vom 
Quadcopter drin.

[Peter II (Gast)]

Nicolas G. schrieb:
> Zeig mir schöne Routinen, mit denen mein atan schneller wird und genau
> genug bleibt.

welche Winkel können denn vorkommen?

fixe Tabelle bietet sich doch an. Bis 1/10 Grad ist das doch kein 
Problem.

[Nicolas G. (Gast)]

Peter II schrieb:
> Nicolas G. schrieb:
>> Zeig mir schöne Routinen, mit denen mein atan schneller wird und genau
>> genug bleibt.
>
> welche Winkel können denn vorkommen?
>
> fixe Tabelle bietet sich doch an. Bis 1/10 Grad ist das doch kein
> Problem.

Für Tangens würde sich eine Lookup-Table anbieten, aber bei ArcusTangens 
ist es problematisch, da der Definitionsbereich von -Unendlich bis 
Unendlich geht. Bei Zwischenwerten kann man sehr schlecht auf eine 
Tabelle mappen, da das keine lineare Funktion ist. Würde man jetzt die 
Lookup-Tabelle mit gleichen Abständen zwischen den Werten erstellen, 
dann wäre es im niedrigen Bereich sehr ungenau und im oberen sehr genau. 
Und beim Quadcopter können durchaus alle Werte vorkommen.
Abgesehen davon ist die bereits vereinfachte Atan-Funktion sehr klein. 
Natürlich wird hier auch nur das Polynom 3. Grades genommen, aber es ist 
genauer als eine Lookup-Table.

float myAtan(float x) {
  if (x > 1.0) {
    return M_PI_2 - (x / (x * x + 0.28));
  } else if (x < -1.0) {
    return -M_PI_2 - (x / (x * x + 0.28));
  }
  return x / (1 + 0.28 * x * x);
}

Oder wie würdest du es mit einer Lookup-Tabelle machen?

[Peter II (Gast)]

Nicolas G. schrieb:
> Oder wie würdest du es mit einer Lookup-Tabelle machen?

ich hatte nur tan gelesen, für atan scheint deine Formel schon recht 
kompakt zu sein.

[Peter D. (peda)]

Nicolas G. schrieb:
> Von der
> Interrupt-Klasse oben wird einem das abgenommen und man hat automatisch
> Zugriff auf alle Klassen-Attribute und weitere Methoden.

Ich muß zugeben, von C++ verstehe ich nur Bahnhof.
Wenn ich das richtig sehe, soll dieses Klassendingens nur die Variablen 
zusammen fassen, die der Interrupt und damit zusammen arbeitende 
Funktionen benutzen. Ich kann mir nur schwer vorstellen, daß es in C++ 
keinen besseren Weg geben sollte ohne diesen riesen Overhead.

Vielleicht kannst Du ja mal ein konkretes Beispiel mit Variablen zeigen, 
wie das mit den Klassen gedacht ist, z.B. UART Interrupt mit FIFO, init, 
putchar und getchar.

[Nicolas G. (Gast)]

Peter Dannegger schrieb:
> Vielleicht kannst Du ja mal ein konkretes Beispiel mit Variablen zeigen,
> wie das mit den Klassen gedacht ist, z.B. UART Interrupt mit FIFO, init,
> putchar und getchar.

Vielleicht hilft dir das hier weiter:
https://github.com/NicolasGoeddel/Quadcopter/blob/master/Quadcopter/Clock.h
https://github.com/NicolasGoeddel/Quadcopter/blob/master/Quadcopter/Clock.cpp


Im Übrigen hat hier im Wiki schon einmal jemand etwas gemacht bezüglich 
Interrupts und OOP. Allerdings erschien mir das viel zu kompliziert und 
am Ziel vorbei. Da gefällt mir meine Lösung wesentlich besser. ;)
https://www.mikrocontroller.net/articles/AVR_Interrupt_Routinen_mit_C%2B%2B

[Dr. Sommer (Gast)]

Peter Dannegger schrieb:
> Ich kann mir nur schwer vorstellen, daß es in C++
> keinen besseren Weg geben sollte ohne diesen riesen Overhead.
Ja, indem man den "next" Pointer direkt in die "Interrupt" Klasse packt, 
und sich somit das extra struct und den 2. malloc Aufruf spart.

[Nicolas G. (Gast)]

Dr. Sommer schrieb:
> Peter Dannegger schrieb:
>> Ich kann mir nur schwer vorstellen, daß es in C++
>> keinen besseren Weg geben sollte ohne diesen riesen Overhead.
> Ja, indem man den "next" Pointer direkt in die "Interrupt" Klasse packt,
> und sich somit das extra struct und den 2. malloc Aufruf spart.

Das Problem ist eben der einmalige Aufruf im globalen Scope von 
'declareISR'. Der erstellt erst die ISR-Funktion. Wenn ich den 
next-Pointer in die Interrupt-Klasse packe, dann weiß eine weitere 
Instanz nichts mehr von der ersten und kann sich nicht dahinter hängen. 
Oder wie hast du das gemeint?

[Dr. Sommer (Gast)]

Nicolas G. schrieb:
> Oder wie hast du das gemeint?
So:

InterruptHelper.h:

void runISR (INTERRUPT_NUM_t i);

class Interrupt {
    friend void runISR (INTERRUPT_NUM_t i);
  private:
    INTERRUPT_NUM_t vectorNum;
    Interrupt* next;

  public:
    Interrupt ();
    virtual ~Interrupt ();
    void addToInterrupt (INTERRUPT_NUM_t vectorNum);
    void removeFromInterrupt ();
    virtual void interrupt () = 0;
};
extern Interrupt* interruptFunctions [_VECTORS_SIZE / _VECTOR_SIZE];

InterruptHelper.cpp:

Interrupt* interruptFunctions [_VECTORS_SIZE / _VECTOR_SIZE];

Interrupt::Interrupt () {
  vectorNum = -1;
}

Interrupt::~Interrupt () {
  if (vectorNum >= 0) {
    removeFromInterrupt ();
  }
}

void Interrupt::addToInterrupt (INTERRUPT_NUM_t vectorNum) {
  this->vectorNum = vectorNum;
  Interrupt* first = &;
  if (interruptFunctions [vectorNum]) {
    next = interruptFunctions [vectorNum];
    interruptFunctions [vectorNum] = this;
  } else {
    interruptFunctions [vectorNum] = this;
    next = nullptr;
  }
}

void Interrupt::removeFromInterrupt () {
  // ...
}

void runISR (INTERRUPT_NUM_t i) {
  Interrupt* scan = interruptFunctions [i];
  while (scan) {
    scan->interrupt ();
    scan = scan->next;
  }
}

ISR(TCD1_OVF_vect, ISR_BLOCK) {
  runISR (TCD1_OVF_vect_num);
}

Nutzungs-Beispiel:

class MyInterrupt : public Interrupt {
  public:
    MyInterrupt () {
      addToInterrupt(TCD1_OVF_vect_num);
    }
    void interrupt () {
      // ...
    }
} myInterrupt;

So hat man sich malloc/new sogar komplett gespart.

[Nicolas G. (Gast)]

Dr. Sommer schrieb:
> So:

Sehr cool. Darf ich das so übernehmen? Das bleibt eh OpenSource. :)

[Ex-C++-Programmierer (Gast)]

Peter Dannegger schrieb:
> Ich kann mir nur schwer vorstellen, daß es in C++
> keinen besseren Weg geben sollte ohne diesen riesen Overhead.

Naja, Templates sind schon erfunden. Und declareISR() ist, ähm, auch 
weit entfernt vom Optimum. Die hier vorgestellte Lösung ist eben, sagen 
wir mal, etwas infantil.

Die wichtigste Frage wurde weiter oben schon gestellt: Ist es wirklich 
nötig, auf einem Mikrocontroller Interrupt-Handler dynamisch zur 
Laufzeit zu ändern?

Die zweite Frage könnte lauten, muss das (Mini-) Framework wirklich 
mehrere Handler pro Interrupt unterstützen?

Es gibt viele Überlegungen, die hier augenscheinlich nicht gemacht 
wurden. Klar, es funktioniert für den Ersteller erstmal soweit. Elegant 
und wiederverwendbar ist aber anders.

[Ex-C++-Programmierer (Gast)]

Nicolas G. schrieb:
> Im Übrigen hat hier im Wiki schon einmal jemand etwas gemacht bezüglich
> Interrupts und OOP. Allerdings erschien mir das viel zu kompliziert und
> am Ziel vorbei.

NIH-Syndrom?

[Nicolas G. (Gast)]

Ex-C++-Programmierer schrieb:
> Peter Dannegger schrieb:
>> Ich kann mir nur schwer vorstellen, daß es in C++
>> keinen besseren Weg geben sollte ohne diesen riesen Overhead.
>
> Naja, Templates sind schon erfunden. Und declareISR() ist, ähm, auch
> weit entfernt vom Optimum. Die hier vorgestellte Lösung ist eben, sagen
> wir mal, etwas infantil.
Templates nutze ich an einigen anderen Stellen auch, also sind mir 
bekannt. Aber mir ist so auf die Schnelle nicht eingefallen wie ich die 
an dieser Stelle geschickt einsetzen könnte. Ich würde gerne den ISR 
erst an der Stelle erstellen, an der er auch benutzt wird. Soll heißen, 
wenn ich nirgendwo eine Klasse habe, die einen bestimmten Interrupt 
benutzen möchte, dann soll auch nicht die entsprechende ISR-Funktion 
erstellt werden. Momentan muss man eben mit 'declareISR()' jeden ISR 
zunächst erstellen, die irgendwo anders mal benutzt werden soll.

> Die wichtigste Frage wurde weiter oben schon gestellt: Ist es wirklich
> nötig, auf einem Mikrocontroller Interrupt-Handler dynamisch zur
> Laufzeit zu ändern?
Vermutlich nicht. Zur Compile-Zeit reicht ja schon. Zur Laufzeit geht es 
ja auch gar nicht. Man kann ihn nur während der Compile-Zeit erstellen 
und dann währender Laufzeit entscheiden, ob man ihn benutzen möchte oder 
nicht. Bei manchen Interrupts hat man dann eben das Problem, dass 
bestimmte Bits gesetzt werden, wenn er ausgeführt wurde, auch wenn man 
ihn nicht wirklich nutzt. Das heißt man muss schon genau wissen, ob man 
'declareISR(x)' wirklich braucht oder nicht und das händisch festlegen.

> Die zweite Frage könnte lauten, muss das (Mini-) Framework wirklich
> mehrere Handler pro Interrupt unterstützen?
Das ist recht unwahrscheinlich, aber ich wollte mir die Möglichkeit mal 
offen halten. Und eigentlich spricht ja auch nicht viel dagegen, oder?

> Es gibt viele Überlegungen, die hier augenscheinlich nicht gemacht
> wurden. Klar, es funktioniert für den Ersteller erstmal soweit. Elegant
> und wiederverwendbar ist aber anders.
Ich lerne ja gerne dazu. Aber elegant im Sinne der Objektorientierung 
ist es doch eigentlich schon, oder etwa nicht?

Ex-C++-Programmierer schrieb:
>> Im Übrigen hat hier im Wiki schon einmal jemand etwas gemacht bezüglich
>> Interrupts und OOP. Allerdings erschien mir das viel zu kompliziert und
>> am Ziel vorbei.
>
> NIH-Syndrom?
Nicht wirklich. Ich erfinde zwar gerne mal ein Rad neu, aber die 
Möglichkeit wie sie im Wiki beschrieben ist, hat mir wegen der vielen 
Code-Dopplungen nicht so recht gefallen. Aber naja, im Grunde kann man 
da wohl wieder weiter drüber streiten. ;)

[Peter D. (peda)]

Was passiert eigentlich, wenn der Interrupt freigegeben wird, bevor die 
Interruptklasse aufgerufen wurde, bzw. nach Aufruf von 
removeFromInterrupt.

Wird dann der BADISR_vect ausgeführt oder ein RETI?

[Nicolas G. (Gast)]

Peter Dannegger schrieb:
> Was passiert eigentlich, wenn der Interrupt freigegeben wird, bevor die
> Interruptklasse aufgerufen wurde, bzw. nach Aufruf von
> removeFromInterrupt.
>
> Wird dann der BADISR_vect ausgeführt oder ein RETI?

Ich verstehe nicht ganz. Der eigentliche ISR besteht ja immer. Ob sich 
jetzt eine Interrupt-Instanz nun damit verbunden hat oder nicht, spielt 
da keine Rolle.

Oder ging es einfach nur um die Frage, was passiert, wenn man 
'removeFromInterrupt()' aufruft, ohne vorher 'addToInterrupt()' 
aufzurufen? Das geht nämlich gar nicht erst, weil man die Methode 
'removeFromInterrupt()' erst aufrufen kann, wenn eine Instanz von der 
Interrupt-Klasse existiert.

[Peter D. (peda)]

In plain C werden alle Handler zur Compilezeit eingetragen und alle 
nicht benutzten Vectoren rufen BADISR_vect auf

Mit Deiner Klasse wird aber erst zur Laufzeit der Zeiger initialisiert.
Wohin zeigt er vor dem "addToInterrupt" bzw. nach dem 
"removeFromInterrupt"?

[Yalu X. (yalu) (Moderator)]

Peter Dannegger schrieb:
> In plain C werden alle Handler zur Compilezeit eingetragen und alle
> nicht benutzten Vectoren rufen BADISR_vect auf

Das ist hier genau so. Die Interrupthandler werden mit

declareISR(IRGENDEIN_vect)

festgelegt und zu Laufzeit auch nicht mehr geändert. Beim Eintreffen
eine Interrupts werden die interrupt()-Methoden der mit addToInterrupt()
registrierten Interrupt-Objekte aufgerufen. Sind keine solchen Objekte
registriert, tut der Interruphandler nicht viel mehr als diese Tatsache
festzustellen (das entsprechende Element in interruptFunctions[] ist
dann NULL) und wieder zurückzukehren.

Alle Vektoren, die nicht mit declareISR() definiert werden, werden zu
BADISR_vect.