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
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...
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.
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.
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.
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...
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.