Jump to content

Umfrage: Welche Programmiersprache als nächstes?


borg
 Share

Welche Programmiersprachen-Bindings sollen wir als nächstes erstellen?  

148 members have voted

  1. 1. Welche Programmiersprachen-Bindings sollen wir als nächstes erstellen?

    • PHP
    • Ruby
    • Perl
    • Delphi
    • Pascal
    • ActionScript (Flash)
    • Visual Basic
    • Lua
    • Matlab
    • LabView
    • Andere (Kommentar)


Recommended Posts

Wie ihr sicherlich mitbekommen habt geht die Weiterentwicklung ein wenig langsamer voran als geplant bei uns. Deswegen haben wir ab morgen einen neuen Mitarbeiter! :D

 

Seine erste Aufgabe wird es sein neue Programmiersprachen-Bindings zu erstellen und eine Dokumentation über die low level TCP/IP Kommunikation zu schreiben (damit man in Theorie jede Programmiersprache nutzen kann).

 

Die Frage ist jetzt natürlich: Welche Programmiersprachen soll er als erstes machen? Was hat die höchste Priorität?

 

Edit: Kleiner Disclamer: Wir behalten uns vor nicht die Reihenfolge die am Ende beim Poll rauskommt einzuhalten, wir Fragen hier ja nur einen kleinen Teil der Community (im Forum angemeldete deutschsprachige). Das Feedback was wir per Email etc. bekommen haben fließt zusätzlich noch ein.

Link to comment
Share on other sites

  • Replies 59
  • Created
  • Last Reply

Top Posters In This Topic

Hallo,

 

ich persönlich fänd es noch interessant, die TF-Produkte in der Shell (Unix/Linux Konsole...) verwenden zu können. Aber ich vermute mal, dass das nicht häufig verwendet werden würde, oder was meint die Allgemeinheit so dazu?

(Ich meine natürlich nicht, dass ich Beispielsweise einfach ein C-Programm habe, dem ich in der Konsole beim Programmaufruf Eingabeparameter übergebe...Das geht ja auch so bereits. Ich meine damit eine Funktionsweise wie von cat, grep etc.)

 

Ich würde mir das so vorstellen: Man startet einen Deamon, und sobald der läuft, kann man alle Funktionen einzeln aus der Konsole starten.

Im Prinzip wäre das nichts anderes, als das man für jede Funktion ein kleines C-Programm hat, das quasi nur eine Aufgabe realisiert. Und dann muss man noch die Verbindung schaffen zwischen Shell und den Programmen (Was an sich kein Problem ist. Damit man das aber auf jedem Rechner eingerichtet bekommt, wäre es gut, dafür dann auch noch ein Installationsskript zu schreiben.)

 

Ist i-wie deutlich geworden, was ich meine?

 

Edit:

 

Ich weiß, das passt jetzt nicht so 100%ig in diesen Thread...

 

 

Gruß,

Fabian

 

Link to comment
Share on other sites

Die Shell ist ja keine Programmiersprache in dem Sinne.

 

Hier kann man ja in C oder python jeweils ein kleines Progrämmchen schreiben, das entsprechend die Parameter (IP-Adresse, Port, UID) übergeben bekommt und dann etwas zurückmeldet (z.B. Temperatur)

 

Das wiederrum kann man dann in Monitoring-Systeme wie Nagios super einbauen.

 

 

gmu

Link to comment
Share on other sites

Mir ist schon bewusst, dass Shell-Sprachen Skriptsprachen und keine Programmiersprachen sind. Deswegen hatte ich schon darauf hingewiesen, dass das hier nicht so 100% rein passt.

 

Aber was du vorschlägst ist ziemlich ähnlich dem, was ich meinte. Für jede Funktion ein kleines Progrämmchen (dessen Inhalt quasi nur die Realisierung bzw. eigentlich nur Nutzung einer bereits implementierten Standard-Funktion ist). Aber das eigentliche Ziel war für mich, dass man dann die Brücke zur Shell (beispielsweise Bash) schlägt. Sinn: Man muss nicht jeder Miniprogramm einzeln umständlich aufrufen, sondern kann einfach den Shell-Befehl verwenden, der dann das eigentliche Progrämmchen aufruft. So in der Art eines Wrappers. Wisst ihr, wie ich das meine?

 

Eigentliches Produkt wäre also die Brücke zwischen der Shell und den Progrämmchen und dafür auch ein Installationsskript, welches diese "Brücke" installiert.

 

 

Link to comment
Share on other sites

@Shell:

Wie würden die Callbacks in der Shell funktionieren?

Und wie granular sollte das sein? Ich befürchte das es einfach zuviel wird wenn man aus jeder Funktion von jedem Brick/Bricklet einen Befehl macht.

 

Was ich mir vorstellen könnte ist sowas:

 

tf brick dc set_velocity 150

tf bricklet temperature get_temperature # Gibt Temperature auf stdout aus

etc.

 

Der einzige Befehl den die Shell dann kennen muss ist "tf".

 

Das wäre glaube ich vergleichsweise schnell generiert, damit könnte man aber dann natürlich nur die getter/setter abbilden

Link to comment
Share on other sites

Ich favorisiere immer noch eine direkte Einbindung in LabVIEW. Dies hätte gerade in Bereichen an Lehreinrichtungen, welche sonst wenig mit Programmieren zu tun haben, viele Vorteile und würde TinkerForge auch für diese Bereiche sehr interessant machen. Zudem ist LabVIEW im Bereich der Forschung und Lehre ohne hin an den Einrichtungen vorhanden (meist auch Matlab) und auch in der Industrie ist es sehr viel anzutreffen. Für private Anwendungen ist es meist zu teuer, darum dort eher seltener.

 

Mit einer solchen Einbindung, könnte sich die Hardware auch in Industrie, Lehre und Forschung etablieren ohne tiefgehende Programmierkenntnisse voraus zu setzen!

Link to comment
Share on other sites

Als erstes wären mal XML Kommentare in den C# Bindings nett, da die Hilfe im Visual Studo dadurch viel besser wäre. Mit guten Kommentaren könnte man sich einiges an Wiki wälzen sparen.

Back2Topic: Als Zielgruppe könntet ihr euch mit einen Grafischen Editor wie in einen anderen Thread bereits angeregt die Schüler und Studenten holen welche nicht Programmieren lernen. Es gibt einige welche von den Bricks begeistert sind aber nicht Entwicklen wollen\können diese könnten mit Klickibunti GUIs die Angst vor Softwareentwicklung genommen werden.

 

Link to comment
Share on other sites

Nifty,

 

inwiefern soll ein Webservice (WS) die Programmierung in jeder beliebigen Sparche unterstützen ?

Ein WS erfordert einen Host ? Welche Soft- oder Hardware soll das übernehmen ?

Und wie unterstützt der WS die Callbacks ?

Link to comment
Share on other sites

@Nifity,

wenn ich Olaf richtig verstanden habe - siehe Thread BrickD für Android - wird man spätestens zum WLAN Modul auf den BrickD verzichten.

 

Ist so ein Long Polling Call zuverlässig genug für Echtzeitverarbeitung von Daten ?

Und werden durch das Soap-Protokoll hier nicht unnötig ein Datenoverhead (Envelopes) geschaffen ?

Und macht sich das so gut bei der Performance ?

Link to comment
Share on other sites

Wäre es von den Entwicklern nicht möglich ne DLL zu erstellen, welche von allen anderen Sprachen angesprochen wird?

 

Finde die ganze Sache mit den Bricks sehr gut. Klein, praktisch, funktional. Als ich die einzelnen Module hier sah, sind mir spontan mehrere Anwendungsfälle auf der Arbeit und auch privat eingefallen. Bei dem Preis kann man die Teile auch für "Spielereien" anshaffen. Anwendungsfälle werden schon von allein kommen.

In meinem Fall, kann ich nur Visual Basic (6/.NET) Greife damit auch auf Hardwareteile, die aber noch lange nicht ausgeklügelt sind wie das System hier.

Link to comment
Share on other sites

Ist so ein Long Polling Call zuverlässig genug für Echtzeitverarbeitung von Daten ?

Und werden durch das Soap-Protokoll hier nicht unnötig ein Datenoverhead (Envelopes) geschaffen ?

 

Vermutlich würde niemand Echtzeit-verarbeitung mithilfe von Webservices machen und natürlich hat Soap overhead. Auf der Haben-Seite steht allerdings eine Plattformunabhängige Zugriffsmöglichkeit, insofern keine dumme Idee, da oft keine Echtzeit nötig ist (Wetterstationen, Lichtautomatik, etc.).

 

Es ist ja btw. schon strittig ob es ne gute Idee ist, Echtzeitverarbeitung unter Betriebssystemen wie Windows 7 oder Linux zu machen, beide bieten keine "hard realtime". Für sowas nutzt man dann eher Windows CE oder RT-Linux.

Link to comment
Share on other sites

Du kannst doch jetzt schon eine Qt-GUI mit den TF-Produkten verwenden. Beispielsweise könntest du doch in C++ programmieren, die GUI mit QT realisieren und im "Hintergrund" laufen die TF-Funktionen.

Oder was übersehe ich da? Sorry, falls ich da was Grundlegendes verchecke.

 

Link to comment
Share on other sites

jein,

also mit Qt kannst du ja weit mehr machen als lediglich ein GUI bauen. Interessant wäre z.B. für jeden Brick / Bricklet eine Klasse zu haben. Das würde das Handling stark vereinfachen, da man keine callbacks mehr braucht. Ist dann alles via Siganl Slot machbar. Wie gesagt mit der entsprechenden Doku könnte man das zur Not auch selbst machen.

Link to comment
Share on other sites

Mag ja sein, dass Win selbst (noch) nicht RT-fähig ist, z.B. für Delphi/C++ gibt es seit einigen Jahren Frameworks, die RT Fähigkeiten ermöglichen: http://www.kithara.de/

Dazu will ich sicher keinen Webservice nötigen, sondern die Bindings für Delphi nutzen.

Also wozu einen Webservice ? Kann man die Energie dafür nicht lieber in die Bindings für die 3 wichtigsten Programmiersprachen investieren ?

 

Andererseits kann man Kunden nicht immer dazu zwingen, Betriebssysteme zu verwenden, die für mich als Entw. praktischer sind.

 

Aber nur um den größten gem. Nenner für alle zu finden und pauschal ein Webservice zu nehmen, für die Ansteuerung von Hardware-Kompon. wie die Bricks und Bricklets ist einfach zu grenzwertig.

Und zur poppeligen Ansteuerung von Hausautomation oder Wetterstationen braucht es nicht unbedingt WinCE oder Linux.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...