Pascal Bindings

Hallo

Ich bin noch recht neu, was TK angeht. Ich finde es klasse, wie einfach das alles geht.

Hier ein Großes Lob an die Entwickler.

Nun stelle ich mir die Frage: Wie kann ich ein eigenes Interface für Object Pascal erstellen: Am besten für FPC/Lazarus. Das kann ich, da habe ich Jahrelang Erfahrung.

Aber ich finde kein guten Einstig in das für mich recht neue Thema. Ich habe gelesen, Sie verwenden TCP/IP aber der Port scheint geschlossen zu sein wenn ich per nmap localhost nach schaue. Der BrickV geht, problemlos. Sogar PHP geht Problemlos.

Ich habe gelesen, Sie Planen ein Delphi Interface? Sinnvoller wäre: Ein FPC Interface zu erstellen, welches auch unter Delphi läuft. FPC ist sehr gut zu Delphi Kompatibel. Damit können Sie zwei Fliegen mit einer Klappe schlagen(Aber ob das in diesen Fall möglich ist, müsste man mal Ausprobieren).

Wenn mir möglich, kann ich es gerne selbst versuchen. Ich habe mir schon verschiedene Codes-Angeschaut, z.b. den von BrickV. Aber so ganz schlau werde ich daraus noch nicht.

"Delphi" Bindings sind als nächstes geplant:

http://www.tinkerforge.com/doc/Timeline.html

Diese sollen dann natürlich nicht Delphi spezifisch sein sondern mit möglichst vielen Pascal Dialekten, Varianten und Compilern funktionieren, u.a. auch mit FPC/Lazarus.

Zu nmap: 'nmap localhost' testet wohl nur die unteren 1024 Ports. Mit expliziter Angabe des Ports zeigt nmap diese als offen an:

nmap -p 4223 localhost

Der für Bindings interessante Code findet sich nicht direkt in BrickV. Unsere Bindings finden sich in einem eigenen git Repository

https://github.com/Tinkerforge/generators

Dort gibt es für jeden Brick und Bricklet eine Config Datei die dessen API beschreibt und für jede unterstütze Programmiersprache ein Python Script das aus den Configs die Bindings und die Dokumentation generiert.

@Pluto,

Du kannst Deine Erfahrungen mit FPC gerne miteinbringen.

Die Grundlagen für das Migrieren in neue Sprachen sind einmal gegeben durch die Doku der TCP/IP Schnittstelle:

http://en.blog.tinkerforge.com/2012/4/30/low-level-protocol-documentation

und/oder als Referenz die C#-Bindings.

Erfahrungen im Programmieren sind genauso Voraussetzung wie spezielle Kenntnisse der Zielsprache.

Unter http://www.tinkerunity.org/forum/index.php/topic,444.0.html

habe ich einen ersten Prototypen für Delphi 7 eingestellt. Du kannst diesen gerne analysieren und probieren ob dieser mit dem FPC kompatibel ist, und ev. Änderungen durchführen, sodaß die Bindings universell einsetzbar sind.

@photron

Gleich zu Beginn den größten gemeinsamen Nenner zu erreichen, um alle Pascal Derivate mit einzuschließen, ist m.E. eine sportliche Angelegenheit. Ev. würde es reichen, nur mit einem Dialekt starten, und dann mit Hilfe der "spezialisierten" User die Anpassungen sukzessive für die anderen Dialekte durchzuführen.

Erstmal Danke für eure Antworten.

Ich werde mir dein Code mal ansehen und mal ausprobieren.

Ich habe eben versucht per LNet auf den Port zuzugreifen... Das geht wohl auch, ist aber nicht so Toll... da ich noch nicht weiß, wie ich weiter machen könnte.

Das Tolle an FPC ist, es hält sich an Delphi7, d.h. das ist Kompatible. Bestimmte Code-Ausschnitte müssen natürlich ausgeklammert werden und einmal für FPC und einmal für Delphi geschrieben werden, aber ich denke, über 80% dürften gleich sein(Ohne mir den Code angeschaut zu haben). Aber mal sehen.

Habe eine Weg gefunden, um Tinkerforge auch unter Lazarus nutzen zu können. Ist zwar bestimmt nicht Effizient aber es scheint zu gehen:

Ich nutzte PHP als Zwischen Sprache. Habe mir zwei PHP Scripte erstellt:

Das erste zum Lesen und das zweite zum Schreiben. Die rufe ich in meiner Lazarus-Anwendung auf.

Die Kommunikation läuft über PIPES.

Zum Spielen reicht es. Dieser Weg ist einfacher als jetzt gleich TCP/IP zu verwenden.

eine weitere Möglichkeit wäre: Über C eine Art Wapper zu erstellen.

Ich hoffe ihr wisst was ich damit meine.

Aber erst mal finde ich es toll. Z.b. nutzte ich ein Timer in Lazarus der alle 1000 ms das Datum und die Uhrzeit auf das LCD Schreibt. Außerdem wird noch die Temperatur angezeigt.

Toll wäre natürlich, wenn es noch eine weitere Möglichkeit geben würde außer dem BrickD direkt zu nutzen. Ich dachte da an Botschaften. 

pluto, das ist ja mal ganz schön von hinten durch die Brust in's Auge

Ich sehe aber gerade gar nicht warum du das so tust. Ich bin gerade mit den Delphi Bindings beschäftigt und das läuft wunderbar unter Lazarus

Die Timeline setzt Delphi Bindings für nächste Woche an. Ich denke das kann ich einhalten.

pluto, das ist ja mal ganz schön von hinten durch die Brust in's Auge

So kann man es auch sehen. Ich finde es nur toll: Das es geht.

Ich sehe aber gerade gar nicht warum du das so tust. Ich bin gerade mit den Delphi Bindings beschäftigt und das läuft wunderbar unter Lazarus

Ach, wirklich? Hast du schon was, was ich ausprobieren könnte?

Ich habe nur das Starter Kit... Es war auch nur ein Experiment. Für mich ist das eine Art Spiel-Wiese(Vielleicht bin ich etwas Alt dafür), andere Spielen "Baller"-Spiele, ich Spiele sowas. Finde ich viel Spannender.

Die Timeline setzt Delphi Bindings für nächste Woche an. Ich denke das kann ich einhalten.

Ich freue mich darauf. Ich dachte, dass du dich eher dass die Delphi-Bindings nur unter Delphi laufen werden, aber schön das sie auch unter Lazarus/FPC laufen. Ich hoffe auch unter Linux.

pluto, ich bin gerade noch am rumreißen, morgen oder so hab ich wahrscheinlich was das ich dir zum Testen geben kann.

Bezüglich Delphi/Lazarus/FPC: Wir wollen da eine breite Abdeckung auf Basis von Object Pascal haben. Im Moment verwendet ich FPC mit -Mobjfpc Option. Derzeitiges Ziel ist, dass die Bindings mit der kommerziellen Delphi IDE von Embarcadero funktionieren sowie mit FPC auf Linux, Windows und Mac OS (unter der Annahme das es FPC für Mac OS gibt).

Linux, Windows und Mac OS (unter der Annahme das es FPC für Mac OS gibt).

Also, nach meinen Wissenstand gibt es FPC für Mac OS. Einige haben es dort sogar im Einsatz. Es gibt es sogar auf Android oder auf DOS Ebene.

FPC läuft auf sehr, sehr vielen Plattformen. Viel mehr als Lazarus.

Hier mal eine Liste: http://wiki.freepascal.org/Platform_list/de

Jetzt hab ich ein Problem. Mit -Mobjfpc muss ich den @-Operator verwenden um die Adresse einer Methode zu bekommen:

stepper.OnPositionReached := @ReachedSteps;

Mit -Mdelphi darf ich den @-Operator nicht verwenden. Weiss da jemand eine elegante Lösung für?

Nachtrag: Wahrscheinlich ist die einfachste Lösung einfach fpc -Mdelphi zu benutzen.

Mit -Mdelphi darf ich den @-Operator nicht verwenden. Weiss da jemand eine elegante Lösung für?

Es gibt eine sehr einfache Lösung dafür: Komplier Dirktiven:

stepper.OnPositionReached := {$IFDEF FPC}@{$ENDIF}ReachedSteps;

Müsste hoffe ich so gehen.

Richtig, das geht, sieht dann aber in den Examples recht hässlich aus

Ich würde dem daher fpc -Mdelphi vorziehen wollen.

Richtig, das geht, sieht dann aber in den Examples recht hässlich aus

 

Ich würde dem daher fpc -Mdelphi vorziehen wollen.

Mag sein, dass es nicht schön aussieht, aber wer schaut sich schon den Code genauer an?

Außerdem ist das eine gängige Praxis unter FPC/Lazarus. Schau dir mal SynEdit an.

Aber der Delphi Modus geht natürlich auch. Ist dann aber nicht mehr Standard FPC.

Aber, Hauptsache es läuft *G*

Naja, Standard FPC ist es eh nicht, weil's Object Pascal ist und -Mobjfpc braucht

Aber du hast mich überzeugt.

Okay, hier Preview 1 der Delphi Bindings. Example.pas ist das typische Enumerate Beispiel. test.pas registriert einen Callback für die Position eines Rotary Potis.

fpc test.pas

reicht zu kompilieren.

delphi_preview1.zip

Erster Test-Bricht:

Komplieren geht, aber sobald ich den "Rotary Potis" drehe, kommt eine AV

An unhandled exception occurred at $0000000000452F99 :

Exception : Could not add device 9Hh, timeout

  $0000000000452F99

  $0000000000413958

ich werde es mir mal genauer ansehen.

Edit01: Vielleicht sollte ich die UID anpassen?

Edit02: Klappt nun bestens.

Edit03: Habe mir den Code mal genauer angesehen, macht einen recht guten Eindruck.

Okay, hier Preview 1 der Delphi Bindings. Example.pas ist das typische Enumerate Beispiel. test.pas registriert einen Callback für die Position eines Rotary Potis.

 

Code: [select]

fpc test.pas

reicht zu kompilieren. delphi_preview1.zip (7.6 kB - downloaded 16 times.)

Ein paar Anmerkungen zur Preview 1:

Im LEConverter würde ich statt array of byte den deklarierten Typen TByteArray verwenden.

Falls die Brick-Klassen und Prozeduren später ableitbar sein sollen, müssen im Vorfahr hinter jeder Prozedur das Keyword virtual oder dynamic angegeben werden. So ist das zumnindest in Delphi 7.

Falls die Brick-Klassen und Prozeduren später ableitbar sein sollen, müssen im Vorfahr hinter jeder Prozedur das Keyword virtual oder dynamic angegeben werden. So ist das zumnindest in Delphi 7.

In FPC/Lazarus ist das nicht anders. dynamic ist mir jetzt zwar neu, aber virtual muss angegeben werden, damit man die Methoden überschreiben kann oder halt virtual und abstract, je nach dem.

dynamic für Speicheroptimierung, virtual Geschw.optimiert. I.d.R. virtual.

Hallo, ich habe mir unter Windows 7 Starter die aktuelle Version von Lazarus/FreePascal installiert und folgende Probleme mit den Beispielen:

- Unit Errors existiert nicht

Den Quelltext für die Unit fand ich nur in den Unix/Linux-Zweigen von FPC. Ich habe den Verweis auf die Unit im IPConnection.pas gelöscht und die fehlende Funktion strerror(socketerror) durch ein IntToStr(socketerror) ersetzt.

- HOST = 'localhost'

Ergab beim fpconnect den socketerror = 10049 (ungültige Adresse?)

- HOST = '192.168.0.12'

Ergibt beim fpconnect  den socketerror = 10060 (Timeout ?):

Der BrickViewer läuft problemlos und auch das C#-Beispiel bringt die erwarteten Resultate.

Ein paar Anmerkungen zur Preview 1:

Im LEConverter würde ich statt array of byte den deklarierten Typen TByteArray verwenden.

Kann ich da so nicht tun. Da ich den type Block der TByteArray definiert nicht vor den interface Block verschieben kann. Das gibt einen Compileerror. Außerdem stelle ich gerade fest, dass ich nicht

function LEConvertInt16ArrayFrom(...): array of smallint;

hinschreiben kann. Ich muss für array of smallint erst einen Typ definieren. Was ich aber hier wieder nicht kann, weil der type Block nach dem interface Block stehen muss. Das zwingt mich also dazu die LEConvert Funktionen unnötigerweise in einer Klasse zu definieren.

Ähnliches gilt für array [0..9] of smallint, das kann ich nicht mal als Funktionsparameter so verwenden auch dass braucht erst wieder einen eigenen Typ.

Delphi/Object Pascal ist bisher die Sprache die mir persönlich am wenigsten gefällt von allen Sprachen für die ich bisher Bindings gemacht habe. Vor allem wegen dieser Sperenzchen mit den Typen

Falls die Brick-Klassen und Prozeduren später ableitbar sein sollen, müssen im Vorfahr hinter jeder Prozedur das Keyword virtual oder dynamic angegeben werden. So ist das zumnindest in Delphi 7.

Kann ich tun.

- Unit Errors existiert nicht

Den Quelltext für die Unit fand ich nur in den Unix/Linux-Zweigen von FPC. Ich habe den Verweis auf die Unit im IPConnection.pas gelöscht und die fehlende Funktion strerror(socketerror) durch ein IntToStr(socketerror) ersetzt.

Preview 1 hatte ich nicht mit FPC auf Windows getestet, das ist mittlerweile korrigiert.

- HOST = 'localhost'

Ergab beim fpconnect den socketerror = 10049 (ungültige Adresse?)

 

- HOST = '192.168.0.12'

Ergibt beim fpconnect  den socketerror = 10060 (Timeout ?):

Ich war fälschlicherweise davon ausgegangen, dass StrToHostAddr auch einen DNS Lookup macht. Was es aber nicht tut, das ist mittlerweile auch korrigiert.

Es wird heute oder morgen Preview 2 geben. Diese ist dann schon vom Generator erzeugt.

Kann ich da so nicht tun. Da ich den type Block der TByteArray definiert nicht vor den interface Block verschieben kann. Das gibt einen Compileerror.

Verstehe ich nicht, in D7 deklariert man zu Beginn der Unit i.d.R. die Typen, die später benutzt werden. Siehe meinen Prototypen der Delphi-Bindings. Warum sollte das noch restriktiver in FPC sein ?

Im Prototypen hatte ich die meisten Typen in BaseData, also in eine seperate Unit verschoben. Ev. sammelst Du die Typen gemeinsam in einer Unit.

Im Allgemeinen hatte ich mit den Restriktionen durch Delphi wenig zu kämpfen; Ausnahme vielleicht die Device-Klasse in eine eigene Unit zu verlagern, aber auch das klappte.

In diesem Forum werden recht professionell auch andere Pascal-Compiler Probleme behandelt:

http://www.delphipraxis.net/forum.php

Woher kennt Dein Compiler eigentlich den Typen TByteArray z.B. in der IpConnection ?

Das Problem liegt daran, dass ich LEConvertInt8To ohne Klasse definiert habe. Der Prototyp für solche Funktionen muss in den interface Block. FPC will nun dass der interface Block der erste in einer Unit ist noch vor dem type und uses block

interface
  procedure LEConvertInt8To(const value: shortint; const offset: longint; var data: array of byte);

uses
  ...

type
  ...

Und jetzt nehme ich das zurück, denn ich habe beim Schreiben diese Post herausgefunden, dass der Prototype auch im type Block sein kann. Alles gut

Warum sollte das noch restriktiver in FPC sein ?

Geht hier genauso. FPC verarbeitet ja Object Pascal.

Das Problem liegt daran, dass ich LEConvertInt8To ohne Klasse definiert habe.

Brauchst du auch nicht. Muss nur ein Datentyp dafür erstellen für dein Array of Smallint.

z.b. in etwa so: am Anfang deiner Unit, nach dem ersten Type: TSmallIntArray = array of Smallint

Und jetzt nehme ich das zurück, denn ich habe beim Schreiben diese Post herausgefunden, dass der Prototype auch im type Block sein kann. Alles gut

So schnell lassen sich Probleme lösen.... Bin schon auf die neue Preview gespannt.

Pascal ist sehr unterschiedlich zu den Sprachen, die ihr bisher unterstützt.

edit01:

Woher kennt Dein Compiler eigentlich den Typen TByteArray z.B. in der IpConnection ?

Von Haus aus, kennt FPC schon einige Datentypen wie TByteArray und einige weitere.Ist das bei Delphi nicht so?

Doch, den TByteArray gibt es schon. Ich würde i.d.R. aber immer nur eigene Typen deklarieren und nur diese (Ausnahme natürl. wenn einfache Standard-Typen reichen) in den Prozeduren verwenden. Falls der Typ doch mal geändert wird, muss nicht der gesamte Code durchpflügt werden.