Frage zu Interrupts in C++

Hallo,

zum Bsp.

ISR(TIMER0_COMPA_vect) {  // Timer 0 Compare.A
  ...
}

ISR(TIMER1_COMPA_vect) {  // Timer 1 Compare.A
  ...
}

ISR(TIMER1_COMPB_vect) {  // Timer 1 Compare.B
  ...
}


Was es alles an ISR's gibt kannste im Datenblatt zu Deinem Atmel µC 
nachlesen. Bei mir Kapitel 14.2 "Reset and Interrupt Vector placement" 
Das ist zwar nicht die C Schreibweise, aber man sieht was es alles gibt. 
Wird ja dann ähnlich geschrieben.

dann habe ich das Beispiel noch nicht ganz verstanden


> Nope.
> Jedes Timer Objekt hat seine eigene serviceRoutine.
>
> Bei der Erzeugung des Timer Objektes, gibst du an, an welchen Overflow
> Interrupt sich dieses Timer Objekt hängen soll.

das ist klar

aber wenn ich jetzt 2 Timer Objekte folgendermaßen erstelle:

1

2

timer timer0(....,TIMER0_OVERFLOW_VECTOR_NUMBER)

3

timer timer1(....,TIMER1_OVERFLOW_VECTOR_NUMBER)

dann wird doch für beide folgende (gleiche?) Implementation aufgerufen 
oder nicht?:

1

void timer::timerInterrupt::serviceRoutine()

2

{

3

  ++ownerTimer->i;

4

}

an welcher Stelle sind dann jetzt die unterschiedlichen 
Implementierungen für die serviceRoutine für Timer0 und Timer1?

C++
*********************************************************************
https://github.com/KonstantinChizhov/Mcucpp

https://github.com/KonstantinChizhov/Mcucpp/tree/master/mcucpp/AVR ...

...timer0.h .. timer2.h anschauen.

https://github.com/KonstantinChizhov/Mcucpp/tree/master/examples/AvrTimer 
...

... timertest.cpp + includes anschauen

http://www.atmel.com/products/microcontrollers/avr/default.aspx?tab=documents 
...

...atmel avr dokumention anschauen.

C
*********************************************************************
https://www.mikrocontroller.net/forum/mikrocontroller-elektronik ...

...Peter Dannegger's C-code anschauen, braucht immer Timer

*********************************************************************
Beispiele studieren,
Programmiertechnik studieren,
sich Fragen : was?, warum?, wieso?

Das war mein Weg ...

*********************************************************************
Alexandra

> Aber es hindert dich ja nichts daran, dir jeweils eigene
> aufgabenspezifische Klassen speziellen für den Anwendungszwecke zu
> erstellen und dann deine Timer Objekte davon zu instantiieren.

Ja genau das war meine Vermutung wie ich es umsetzen muss, aber ich war 
mir nicht sicher, ob ich das Beispiel zu 100 % verstanden habe. Habe ich 
dann aber doch richtig :)

> Edit:
> Im übrigen finde ich, das ist genau so ein Punkt an dem eine Verpackung
> in Klassen nichts oder nicht viel bringt. Hier ist ein OOP Ansatz
> Overkill.

leider hast du damit Recht, aber ansonsten sehe ich im OOP Ansatz schon 
einige Vorteile.

DANKESCHÖN :)

> Oh, ich bin ein starker Verfechter von OOP.
> Aber es zeigt sich immer wieder, dass es bestimmte Bereiche gibt, an
> denen OOP nichts bringt und eigentlich nur eine Menge Overhead erzeugt.
> Prominentes Beispiel ist immer dann gegeben, wenn es um SChnittstellen
> zu 'externen' Mechanismen geht. Hardware Timer (oder irgendeine andere
> Hardware aber auch Files) fallen da rein. An dieser Stelle bricht das
> Konzept etwas zusammen und speziell wenn es darum geht die Kurve in der
> umgekehrten Richtung zu kratzen (also von extern wieder ins Programm
> rein), kommt es dann zu Klimmzügen.
>
> Hast du dir schon mal angesehen, was in C++ ein 'Interface' ist? Im
> Grunde ist das eine kleine Klasse, mit lauter virtuellen Funktionen
> (meistens sind die auch pure, so dass man sie implementieren muss). Sinn
> der Sache ist es, mittels Mehrfachvererbung einer anderen Klasse so ein
> 'Interface' aufzupfropfen.

Ja, Interfaces nutze ich schon, danke für den Hinweis :)
Aber vielleicht könnte ich das ja an dieser Stelle auch noch machen, 
muss ich mir mal ein Konzept überlegen.

und ich finde es bringt sehr wohl etwas,

modularen Code !
**************
display in display.h,
Timer in Timer.h mit den ISR's,
Timebase in "public of "Timer,
DCF77 in DCF77.h

(DCF77 nach Beispiel Dannegger)