Forum: Mikrocontroller und Digitale Elektronik Referenz von "usi_onReceiverPtr"


von Vam L. (vam_l)


Angehängte Dateien:

Lesenswert?

Moin zusammen,

ich habe mir mal og. file von github gezogen und suche verzweifelt die 
Referenz für den usi_onReceiverPtr, damit ich dies auf Ordnungsgemäß 
auf Free Pascal für Lazarus umschreiben kann.

es Darf auch gerne ein Hinweiß auf eine andere USI-TWI kommen, solange 
ADURINO NICHT mit reinspielt

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Vam L. schrieb:

> ich habe mir mal og. file von github gezogen und suche verzweifelt die
> Referenz für den usi_onReceiverPtr, damit ich dies auf Ordnungsgemäß
> auf Free Pascal für Lazarus umschreiben kann.

Den gibt es nicht. Das ist einfach eine globale Variable, die einen 
Funktionszeiger enthält, der auf die Empfängerfunktion der Anwendung 
zeigt.

Sowohl die eigentliche Funktion als auch den Zeiger darauf hat die 
Anwendung bereitzustellen. Der Sinn ist: es kann durchaus 
unterschiedliche Empfangsaufgaben in einer Anwendung geben (weil z.B. 
mehrere verschiedene Devices über den Bus angesprochen werden sollen) 
und dann ist es sehr praktisch für die Anwendung, jeweils die zum 
angesprochenen Device passende Empfängerroutine "einzustellen", bevor 
sie beginnt, mit dem Device zu reden.

Soweit also alles vollkommen logisch. Was fehlt, um das in Pascal 
nachbauen zu können, ist nur der Funktionsprototyp für die Funktion, die 
dürfte sich in usiTwiSlave.h finden. Zur Not kann man aber auch allein 
aus dem vorhandenen Code in usiTwiSlave.c den Prototypen rekonstruieren. 
Wäre (in Pascal) eine procedure mit einem einzigen Übergabeparamter vom 
Typ "Byte". In C natürlich eine von diesen schwachsinnigen "Funktionen" 
die garkeine Funktionen sind, weil sie keinen Ergebniswert 
zurückliefern, was mit viel Syntax-Bombast und dem 
schwachsinnig-vielbenutzten Schlüsselwort "void" als Ergebnistyp zu 
deklarieren wäre. Naja, C halt...

von Vam L. (vam_l)


Lesenswert?

Weder in der *.c noch in der entsprechenden .h ist etwas zu finden.

wenn ich mir allerdings die Zeile
1
    if (usi_onReceiverPtr) \
 anschaue würde ich diese als bool definieren.

aber die Zeile
1
           usi_onReceiverPtr(usiTwiAmountDataInReceiveBuffer()); \
sagt mit:
Satz mit X

vielleicht schaue ich mir auch die hier an...
https://www.mikrocontroller.net/attachment/12870/mfc_ro7021.c
in der Hoffnung, auf dem selben Effekt zu kommen.

von c-hater (Gast)


Lesenswert?

Vam L. schrieb:

> wenn ich mir allerdings die Zeile
1
    if (usi_onReceiverPtr) \
> anschaue würde ich diese als bool definieren.

Quatsch. Da wird nur geprüft, ob der Funktionszeiger überhaupt 
initialisiert wurde. In Pascal würde das entsprechen:

if assigned(usi_onReceiverPtr) begin
 ...
end;

Diese Prüfung ist äußerst sinnvoll, denn ansonsten steht da schlicht 
null (C) bzw. nil (Pascal) drinne, was beim AVR8 bedeuten würde, dass 
der Treiber beim Aufruf der Funktion über diesen Zeiger einen 
"Softwarereset" auslösen würde. Der mit einiger Wahrscheinlichkeit 
nichtmal einen geordneten Neustart zur Folge hätte, weil die Hardware 
halt nicht resetted wird.

> vielleicht schaue ich mir auch die hier an...
[...]

Vielleicht schaust du dir einfach erstmal überhaupt das Konzept von 
Funktionszeigern und Funktionstypen (Pascal: prozedurale Typen) an...

Egal, ob in Pascal oder C, alles eine Soße. Nur die Syntax unterscheidet 
sich, das Prinzip ist immer dasselbe.

von Vam L. (vam_l)


Lesenswert?

wird also auf unliebsame Pointer hinauslaufen und mit 
Aktionen/Experimente in Richtung
1
type
2
    TIntegerFunction = function: Integer;
3
    TProcedure = procedure;
4
    TStrProc = procedure(const S: string);
5
    TMathFunc = function(X: Double): Double;
6
  var
7
    F: TIntegerFunction; // F is a parameterless function that returns an integer
8
    Proc: TProcedure;    // Proc is a parameterless procedure
9
    SP: TStrProc;        // SP is a procedure that takes a string parameter
10
    M: TMathFunc;        // M is a function that takes a Double (real)
11
                         // parameter and returns a Double
12
  
13
    procedure FuncProc(P: TIntegerFunction);  // FuncProc is a procedure
14
                         // whose only parameter is a parameterless
15
                         // integer-valued function
 will ich verzichten, wenn nicht unbedingt nötig.

von c-hater (Gast)


Lesenswert?

Vam L. schrieb:
> wird also auf unliebsame Pointer hinauslaufen

Natürlich, was hast du denn erwartet, wenn schon der Name der Variablen 
das mit dem Suffix "ptr" nahelegt?

> verzichten, wenn nicht unbedingt nötig.

Ist aber unbedingt nötig, wenn man I²C effizient als das nutzen will, 
wofür es designed wurde: als Bus, an dem verschiedene Devices hängen 
können. Ja, das Programmiererleben ist kein Ponyhof. Da muss man sich 
halt auch mit Zeigern auskennen...

von Vam L. (vam_l)


Lesenswert?

c-hater schrieb:
> Ja, das Programmiererleben ist kein Ponyhof. Da muss man sich halt auch mit 
Zeigern auskennen...

betrifft nicht nur das Programmiererleben...

zumal bisher bin ich immer OHNE Zeigern glargekommen, was größere Sachen 
angeht und das bissel zeiger, was ich in C brauchte...
Nun das kann man in den Berühmten SKAT drücken.

Bitte 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
Noch kein Account? Hier anmelden.