Hallo Forum, folgenden Artikel hier auf mikrocontroller.net finde ich richtig gut: http://www.mikrocontroller.net/articles/AVR_Interrupt_Routinen_mit_C%2B%2B Ich habe aber noch eine Frage zur zweiten Variante mit Interrupt Elternklasse: Sehe ich es richtig, dass damit für jeden z.B. TimerOverflow-Interrupt die selber Routine aufgerufen wird? z.B. Timer0, Timer1, Timer2 Oder übersehe ich die Differenzierung irgendwo? Es gibt zwar eine Differenzierung der Interrupts in der abstrakten Interrupt-Klasse, aber nur eine Implementierung der serviceRoutine für die Timerklasse. Dieser übergebe ich zwar die Nummer, aber bei der serviceRoutine wird nicht nach dieser Nummer unterschieden. Wenn dem so ist, liese sich das ja mit einer virtuellen Implementierung von serviceRoutine() umgehen, indem ich für jeden einzelnen Timer die Timerklasse ableite und dann nur die serviceRoutine implementiere? Vielen Dank schon mal, Heinz
heinz schrieb: > Sehe ich es richtig, dass damit für jeden z.B. TimerOverflow-Interrupt > die selber Routine aufgerufen wird? z.B. Timer0, Timer1, Timer2 > > Oder übersehe ich die Differenzierung irgendwo? > > Es gibt zwar eine Differenzierung der Interrupts in der abstrakten > Interrupt-Klasse, aber nur eine Implementierung der serviceRoutine für > die Timerklasse. 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. > Dieser übergebe ich zwar die Nummer, aber bei der > serviceRoutine wird nicht nach dieser Nummer unterschieden. muss auch nicht. Die serviceRoutine ist nicht statisch
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
heinz schrieb: > aber wenn ich jetzt 2 Timer Objekte folgendermaßen erstelle: > >
1 | > timer timer0(....,TIMER0_OVERFLOW_VECTOR_NUMBER) |
2 | > timer timer1(....,TIMER1_OVERFLOW_VECTOR_NUMBER) |
3 | >
|
> > dann wird doch für beide folgende (gleiche?) Implementation aufgerufen > oder nicht?: Ach das meinst du. Ja, das stimmt. 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. 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.
> 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 :)
heinz schrieb: >> 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. 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.
> 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)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.