OOP in C - Problem mit Funktionspointern

sowas kann man machen
.. muss man aber nicht ^^


z.B.
linuxlike gibt es diverse I/O funktionen für devices
also read/write/open/close/ioctl

gibt dazu sogar schon diverse abstractionen zu wo man geräte mit 
"dev/..." anspricht

entweder macht man nun auch structs im treiber so das man mehrere 
intanzen des treibers laden kann ...
wo halt adressen und so gespeichert werden..

jede geraetestruct merkt sich dann die erzeugt instanz im treiber
und greift darauf zu


oder wenn die peripherie überschaubar ist , dann adressparameter in die 
geraetestruct ...

Bei einer C++-Klasse würde implizit der this-Pointer an die Funktion 
übergeben werden. In C musst Du das explizit hinschreiben:

1

Geraet[1]->Licht(&Geraet[1], AN);

Die Schnittstelle ist dann ein Element in der Gerät-Struktur, auf die 
die Funktion "Licht" zugreift.

Wenn Dich das redundante "Geraet[1]" stört, könntest Du den Aufruf 
höchstens in ein Makro verpacken, so dass es dann in etwa so aussieht:

1

LICHT(Geraet[1], AN);

oder du baust dir macros ...

um aus

Geraet[1]->Licht(Geraet[1]->Schnittstelle,AN)

ein


Geraet[1]->Lichtmacro(AN)

zu erzeugen

Jobst Q. schrieb:
> Rahul D. schrieb:
>> Bisher habe ich Funktionen, denen noch die Schnittstelle mit übergeben
>> wird. Das würde ich mir - wenn möglich - gerne sparen und die Funktionen
>> nur so aufrufen:
>>
>> Geraet[1]->Licht(AN).
>
> Ich würde Gerät 1 nur so aufrufen wollen:
>
> schalte(1,AN);
> oder
> schalte(1,AUS);
>
> Den ganzen Kram mit den Arrays und Schnittstellenzuordnung brauchst du
> dann nur einmal, eben in der Funktion schalte(geraetenummer,an_aus).

das ist auch schick ..

ICH würde aber die "1"  durch eine pinter auf die gerätestruct ersetzen.

geht  sicherach benennung durch enum/defines ...

aber das debuggt sich einfacher.


zudem kann , wenn eh schon malloc/free verwendet wird
ein konstructor - gebilde gebaut werden


geraet_t *netzteil;

netzteil = malloc ( sizeof( geraet_t ));

Licht(netzteil , AN);


oder durch fp* + macros..

netzteil->licht(1);

jeder treiber hat eine struct mit fp* zu den passenden
read/write/init/conf
funktionen

deine funktionen nutzen dann eben nur die struct

1

device->phy->write( param , len );

wobei phy ein struct mit den fp der jeweiligen HW ist
ob das nun I²C oder UART /SPI ist ... das musst du vorher eben festlegen

1

void licht( *device , param ){

2

   device->phy->write( param , len );

3

}

Eigentlich macht man das, indem man logische Devices (hier 1, mit 3 
Instanzen) und physikalische erstellt und verbindet.

1

struct Lampe; /*logisches Device*/

2

typedef struct sLampe *TLampe; /*Zeiger*/

3

TLampe LKinderzimmer;

4

TLampe LWohnzimmer;

5

TLampe LFlur;

6

7

/*physikalische, im selben Schema*/

8

typedef struct sphyUSB TphyUSB; 

9

typedef struct sphyI2C TphyI2C;

10

typedef struct sphyUart TphyUart;

11

12

TphyUSB phyUSB_a;

13

TphyUSB phyUSB_b;

14

TphyUart phyUart;

15

16

void LichtAn(TLampe L); /*logische Funktion*/

Alternativ zu LichtAn als Funktion kann es auch Memberfunktion sein

die physikalischen Devices enthalten die Umsetzung, mit allgemeinen 
Funktionen oder quasi das phy-Pendant zu LichtAn. sphyUart.LichtAn() 
sendet z.B. "Befehl 37" raus.

Es gibt dann je phy-Typ eine oder zwei Create und Initroutine, in denen 
der Speicher für den Treiber und z.B. Baudrate und Port mitgegeben 
werden (Uart):
phyUSBA_a = CreateUart(usb_a, 9600, ...);

Ebenso für die logischen Devices
LKinderzimmer = CreateLampe(lampe1, ...);

Zusätzlich gibt es je eine Verknüpfungsrouteine, die TLampe mit einem 
physikalischen Device verbindet.

ConnectLampe_USB(TLampe L, TphyUSB USB);
ConnectLampe_I2C(TLampe L, TphyI2C I2C);
ConnectLampe_Uart(TLampe L, TphyUart Uart);

Warum jeweils 3 Routinen? Weil es keine Gemeinsamkeiten gibt zwischen 
USB, I2C und Uart. Es macht 0 Sinn, die Obermenge zu abstrahieren und 
entsprechend kryptische Funktionen und Werteinterpretationen durch den 
Anwendercode zu ziehen.

Man kann manchmal die Initialisierung des physikalischen Devices sparen 
und an die Connect_Funktion dranpappen. Ist aber meist nicht sinnvoll.

Im Code hast Du nacher

1

   LampeAn(LKinderzimmer);

2

   ...

3

   for(p=ListOfLamps, p, p++)

4

   { 

5

       LampeAus(p);

6

   }

bzw. mit Funktionspointern:

1

   LKinderzimmer->LampeAn(LKinderzimmer):

2

   ...

3

   for(p=ListOfLamps, p, p++)

4

   { 

5

       p->LampeAus(p);

6

   }

Reinhard M. schrieb:
> USB, I2C und Uart sind jeweils Frame-orientierte Übertragungsprotokolle.

Wie bitte?

Du schreibst Unsinn.
Beim UART hat man völlig asynchrone Einzelzeichen-Übertragung
Beim I2C hat man adressierte Einzelzeichen-Übertragung (OpenSlave, 
Übertragung(en), CloseSlave)
Beim USB hat man erstmal garnichts, sondern muß sich aus den 
Möglichkeiten, die USB so bietet, eine aussuchen und implementieren. Ob 
das nun Frame-orientiert ist oder nicht, isochron ist oder nicht und und 
und, hängt davon ab, was man da implementiert.


Rahul D. schrieb:
> Ich würde mir nun gerne eine Art Treiber scheiben (Keil C, RTOS u.a.
> wegen USB-Host), der dafür sorgt, dass das übergeordnete Programm alle
> Geräte gleich ansprechen kann.

Ja, ist verständlich.

> Wie realisiert man das?

Etwa so:

1

#define CSTA  const struct TActuator

2

struct TActuator

3

{ int AllgDaten;   // etc.

4

  void  *Data;     // zeiger auf die veränderlichen Daten

5

  // hier kommen nun die Methoden:

6

  void  (*OnInit)     (CSTA* self, weitere parameter..);

7

  void  (*OnMachwas)  (CSTA* self, weitere parameter..);

8

  void  (*OnSchaltEin)(CSTA* self, weitere parameter..);

9

  void  (*OnSchaltAus)(CSTA* self, weitere parameter..);

10

};

So. So einen Struct kann man in den Flash legen. Der Typ muss 
einheitlich sein für alle Aktuatoren, die du so hast, egal ob so einer 
an einem UART oder I2C oder sonstwo dran hängt.

Die allgemeinen daten im struct sollen allgemeingültig sein, also alles, 
was du so an allgemeinen und konstanten Daten benötigst. Für spezielle 
Daten, die sich auch ändern können, mußt du *Data benutzen. Der ist 
void, du mußt also dort in jedem Falle casten. Aber genau DAS machst du 
niemals in deinen übergeordneten Programmteilen, sondern NUR in deinen 
Treibern, die per OnInit oder OnMachwas oder so aufgerufen werden.

Alle solche Treiber müssen das gleiche Interface haben, also die 
gleichen allgemeinen Parameter im Aufruf haben. Dazu kommt ein 'self', 
der auf den aktuellen struct zeigen muß. Zu jeder Interfaceart schreibst 
du dir nen Treiber. Das Entscheidende ist deren gleiches Interface zum 
aufrufenden Programm hin. Du hast also pro Gerät einen Struct im Flash. 
Dort stehen die nötigen Daten drin (z.B. Adresse oder Formatangaben für 
dessen Ansprechen) und es stehen die Funktionen drin, mit denen man das 
Gerät anspricht. Wenn variable Daten benötigt werden, bekommt jeder 
Struct einen eigenen Bereich im RAM, wo *Data hinzeigt.

W.S.

Nana, DU bist doch garnicht der TO. De wollte seine diversen 
Aktuatoren trotz höchst unterschiedlicher HW auf gleiche Weise behandeln 
können.

Und wenn dir ein Beispiel namens OnMachwas(...) nicht von selbst 
einleuchtet, dann sei's dir erklärt: Das ist ein Beispiel. Man braucht 
nicht vier Funktionspointer, sondern eben so viele, wie man im konkreten 
Fall eben braucht - genauso geht's mit eventuellen konstanten Daten 
und/oder Variablen. Aber das ist Sache des TO.

Nochwas: Wenn dir schon klar war, daß du Unsinn schreibst, warum tatest 
du es? Frame-orientierte Übertragungsprotokolle sind solche, die eben 
einen Frame, also einen Rahmen haben. Ethernet-Pakete zum Beispiel. Aber 
ein asynchron gesendetes Zeichen auf einer seriellen Schnittstelle 
gehört nicht dazu. Es ist eben nur ein Zeichen und sonst nix.

W.S.

S. R. schrieb:
> In meiner naiven Weltsicht erfüllt die Übertragungseinheit einer
> seriellen Schnittstelle

Ach, frag dich doch erstmal, ob der TO von solcher Sophisterei einen 
Nutzen hätte. Ich bezweifle dies.

Und hier geht es auch nicht darum, was Reinhard fokussiert:
Reinhard M. schrieb:
> USB, I2C und Uart sind jeweils Frame-orientierte Übertragungsprotokolle.
> Ich sehe da schon Gemeinsamkeiten. Eine öffentliche Schnittstelle könnte
> so aussehen, dass man..

Nein, Eben genau das ist eigentlich egal. Dem TO ging es nicht darum, 
Gemeinsamkeiten diverser Peripheriecores und deren Verhalten zu finden, 
sondern er will seine Aktuatoren (O-Ton: "verschiedene gleichartige 
Geräte") unabhängig von deren Anbindung auf gleiche Weise ansprechen.

Nochmal zum Mitschreiben: Die Geräte sind das Ziel und nicht die Strippe 
zu ihnen.

Deshalb soll es für das Ansprechen herzlich wurscht sein, ob das eine am 
I2C und das nächste am USB-OTG oder sonstwo dran hängt. Ich hab ihm eine 
Art Quasi-Objekt-Lösung vorgeschlagen, wo die Unterschiede in der Art 
der "Strippe" im jeweiligen Objekt gehandhabt werden und das Interface 
zum aufrufenden Programm hardwareunabhängig ist.

Klaro?

W.S.

Reinhard M. schrieb:
> Kommt eben drauf an, ob man Gemeinsamkeiten finden will, oder nicht.
> Ich hatte den TE so verstanden, dass er nach Gemeinsamkeiten suchte und
> zugleich seinen Code leserlicher machen wollte.

Das klappt aber bei Dir nicht. Vermutlich hast Du meinen Post entweder 
nicht gelesen oder nicht verstanden, ebenso nicht die Ausführungen von 
W.S.

Bei Deinem Bemühen, Gemeinsamkeiten zu finden, verlagerst Du

A)Implementierungsdetails der Device-Treiber in die abstrakte 
Lampenebene.

Reinhard M. schrieb:
> Device LampeKinderzimmer = {
>   .address    = LAMPE_KINDERZIMMER,
>   .onCommand  = USB_EIN,
>   .offCommand = USB_AUS,
>   .send       = commUSB.send,
>   .receive    = commUSB.receive,
>   .commInfo   = &commUSB
>   };

und legst Dir Beschränkungen bei der Implementierung auf, um künstlich 
"Gemeinsamkeiten" zu beschwören.

W.S.: (oder mein Beispiel) trennt die Logische Ebene (Lampen schalten) 
komplett den Device-Treibern. Falls es Gemeinsamkeiten gibt, spricht 
ja nichts dagegen, die aus einer gemeinsamen Basis zu bedienen, auf 
keinen Fall aber über die Lampenebene.

Wenn Du solche Device-Treiber mal wirklich selbst durchdenkst (von A bis 
O), dann wirst Du das folgende früher oder später selbst erkennen:

Achim S. schrieb:
> Warum jeweils 3 Routinen? Weil es keine Gemeinsamkeiten gibt zwischen
> USB, I2C und Uart. Es macht 0 Sinn, die Obermenge zu abstrahieren und
> entsprechend kryptische Funktionen und Werteinterpretationen durch den
> Anwendercode zu ziehen.

Explizit nochmal zu Deiner Frage:

Reinhard M. schrieb:
> wieso soll ich Platz für
> vier Funktionszeiger verschwenden, wenn einer dafür ausreicht?

Weil die 4 Funktionszeiger in dem Beispiel sehr les- und handhabbar 
sind. Wenn dem Designer 1 Funktionszeiger lieber ist, macht er nur eine 
Funktion "DoCommand(..., int cmd, ...)" mit festgelegten Kommandos. Aber 
genau nicht auf Datenebene der Devicetreiber, sondern abstrakt dazu, 
z.B. 1=Init, 2=An, 3=Aus, 4=Toggle,....)

Reinhard M. schrieb:
> Naja - ich habe die Abstraktion eben anders aufgeteilt.

Nein, du hast es noch immer nicht begriffen. Natürlich kann man immer 
mit dem Argument kommen, daß es ja auch anders ginge. Stimmt, in 
Assembler kann man alles - nur so als Beispiel. Aber das ist hier kein 
wirkliches Argument.

Mal ganz vom hohen Roß aus gesprochen:
Objektorientierte Programmierung besteht darin, daß man Objekte hat, die 
nach außen hin, also in Richtung der übergeordneten Programmschichten, 
sich gleich verhalten, obwohl sie im Inneren höchst unterschiedlich 
sein können. Dazu haben sie alle einen Satz von Methoden und allgemeinen 
Eigenschaften, die auf alle Objekte zutreffen - obwohl sie im Inneren 
sowohl unterschiedliche weitere Eigenschaften haben können als auch im 
Inneren der äußerlich gleichen Methoden die Luzie von einem Objekt zum 
anderen ganz unterschiedlich abgeht.

Lehrbeispiel sind grafische Elemente auf einem Programmfenster: Selbiges 
sagt nur "For All My Elements: Draw_Yourself();" und es ist dem Fenster 
egal, ob das nun ein Punkt, eine Linie, Dreieck, Kreis oder Kringel ist. 
Im Inneren dieser Objekte sind unterschiedliche Zeichenmethoden 
vorhanden, denn ein Kreis zeichnet sich anders als ein Dreieck. Aber 
gegenüber dem Fenster sind sie alle gleich.

Nun klaro?

W.S.

S. R. schrieb:
> Welcher Ansatz ist immer und ausnahmslos besser?

Natürlich der zweite Ansatz.

Der spräche auf den ersten Blick für Reinhard (mehr im Aufrufer 
zentralisieren). M.E. hinkt der Vergleich hier aber, da Reinhard nicht 
nur Printf (da stimme ich zu), sondern (um im Beispiel zu bleiben) auch 
Display-Kommandos und Schnittstellen-internas zum Aufrufer verlagert 
(das lehne ich ab).