Knoten im Kopf, Klassen und Vererbung

A. Z. schrieb:
> nun aber 4 CaptureCompare-Kanäle. Diese möchte ich gerne als separate
> Objekte ansprechen und trotzdem sollen sie sich wie ein eigenständiger
> Timer verhalten.

Das "trotzdem" verstehe ich nicht.

Viele liebe Grüße
timm

Damit meine ich, dass ich gerne über die CaptureCompare Instanz die 
Grundfunktionen des Timers bedienen möchte.
Am Ende müsste es dann also möglich sein über jede Instanz der 
CaptureCompare Klasse zum Beispiel den Prescaler zu verstellen. Das 
hätte natürlich auswirkungen auf die jeweiligen anderen Instanzen.

edit: ist wohl ein bisschen doof formuliert.

vlt ist so besser:

> Diese möchte ich gerne als separate
> Objekte ansprechen und trotzdem sollen sie sich bezüglich der
> Grundfunktionen wie ein Timer (eine Instanz der Klasse Timer) verhalten.

Mal ein Vorschlag.

Die class Timer ist ein Interface, das die Timermethoden vorgibt.
Davon abgeleitet ist dann class CaptureCompare, die diese Funktionen 
implementiert.
Eine class X die deine Hardware ansteuert. Die CaptureCompare Instanzen 
haben alle eine Referenz auf die selbe Instanz von X, die dann die 
Abhängigkeiten verwaltet.

> Mal ein Vorschlag.
Das wäre dann sowas in der Art?

1

class X{

2

private:

3

registerstruct* timer_reg;

4

};

5

6

class Timer{

7

public:

8

virtual void startTimer(void);

9

};

10

11

class CaptureCompare:public Timer{

12

private:

13

X* manager;

14

15

public:

16

void startTimer(void){

17

manager->timer_reg->register_A|=startbit;

18

};

19

}

Vka schrieb:
> Das ist IMHO eine blöde Architektur. Dann brauchst du irgend eine
> Abstraktion vom eigentlichen Timer, damit sich nicht alles gegenseitig
> verstellt.

Das mag sein, mir ist leider noch keine bessere Idee gekommen. Ich weiß 
aber, dass ich am Ende ganz gerne die einzelnen CaptureCompare Channel 
als separate Objekte übergeben möchte.

Ja. Ich habs mal leicht geändert so wie ich es schreiben würde.

1

class X{

2

private:

3

registerstruct* timer_reg;

4

};

5

6

class Timer{

7

public:

8

virtual void startTimer() = 0;

9

};

10

11

class CaptureCompare:public Timer{

12

private:

13

X& manager;

14

15

public:

16

void startTimer() override {

17

manager.timer_reg->register_A|=startbit;

18

};

19

}

void als Funktionsparameter ist in C++ nicht nötig (in C schon, weil 
sonst beliebige Parameter möglich wären).
Die Funktion im Interface ist pure virtual und das override im 
CaptureCompare gibt einen Fehler, wenn man damit irgendwann nichts mehr 
aus der Basis überschreibt. Das ist vorallem dann wichtig, wenn die 
überschrieben Funktion nicht pure virtual wäre.
Manager als Referenz, dann bekommt man einen Fehler, wenn man es nicht 
initialisiert. Allerdings kann man gegenüber einem Pointer die Referenz 
nachher nicht mehr tauschen (aber in diesem Fall ändert sich die HW ja 
auch nicht zur Leufzeit).

M.K. B. schrieb:
> Ja. Ich habs mal leicht geändert so wie ich es schreiben würde.

Vielen Dank für die Mühe, ich gucke morgen mal, ob ich das gescheit 
umgesetzt bekomme.

A. Z. schrieb:
> Am Ende müsste es dann also möglich sein über jede Instanz der
> CaptureCompare Klasse zum Beispiel den Prescaler zu verstellen. Das
> hätte natürlich auswirkungen auf die jeweiligen anderen Instanzen.

Schon alleine deshalb würde ich das nicht machen.

> vlt ist so besser:
>
>> Diese möchte ich gerne als separate
>> Objekte ansprechen und trotzdem sollen sie sich bezüglich der
>> Grundfunktionen wie ein Timer (eine Instanz der Klasse Timer) verhalten.

Ableitung drückt eine ist-ein-Beziehung aus. Also musst du dir die Frage 
stellen: Ist eine Capture-Compare-Unit ein eigener Timer? Wenn nicht, 
sollte sie auch nicht davon abgeleitet sein.
Das Problem ist, dass du im ersten Schritt nicht darüber nachdenkst, wie 
die Struktur deiner Ressourcen aussieht, sondern wie du auf die Elemente 
nachher gerne zugreifen würdest.

Maier schrieb:
> Ware die natuerliche Struktur nicht zwei Klassen, eine fuer den Timer
> mit seinen Einstellungen und eine fuer die Captures.

Ja.

> Instanzen der Captureklasse sind dann Eigenschaften der Timerklasse. So
> koenntest du auch an einen anderen Timer die gleichen
> CaptureCompare-Channel-Einstellungen uebergeben. Also keine Ableitung,
> sondern Hirarchie.

Aggregation nennt sich das. Die Wikipedia-Seite für Vererbung 
https://de.wikipedia.org/wiki/Vererbung_(Programmierung) fasst es in 
einem Satz gut zusammen:
"Eine weitere fragwürdige Verwendung ist, wenn die erbende Klasse nicht 
in einer „ist-ein“-, sondern in einer „hat“-Beziehung zur Basisklasse 
steht, und eine Aggregation angebracht wäre."

Und ein Timer hat Capture-Compare-Einheiten.

Ich bin zwar normalerweise ein Freund des "single responsibility 
principle", aber in dem Fall lohnt sich der zusätzliche 
Verwaltungsaufwand in meinen Augen nicht.

Das größte Problem bei 2x getrennten Klassen wäre vermutlich die 
Interrupts vernünftig unter einen Hut zu bringen. Selbst bei den größten 
Cortex M4/7 Prozessoren hat nur ein kleiner Teil der Timer mehr als 
einen Interrupt Vektor. Die überwiegende Mehrheit teilt sich 
Update/CaptureCompare/etc. Interrupts auf einem einzigen Vektor.

Wo landet also die Funktionalität des Interrupts? In der Timer Klasse? 
Oder im CaptureCompare? Und was wenn du aus versehen einen Update 
Interrupt bekommst, aber im CaptureCompare tatsächlich nur 
CaptureCompare Interrupts behandelst... Dann ist dein Prozessor defakto 
tot.