borg

Genau! Exakt. Was ist denn wenn meine Application UI/GUI-Interaktionen hat ? Wird deren Darstellung visualisiert ? Für eine GUI Applikation musst du schon etwas verwenden was es auch unter Linux gibt. Zum Beispiel Qt, GTK, LCL (ähnlich zu VCL, Delphi), Swing und AWK (Java), etc. Die Ausgabe auf einen Monitor erfolgt über HDMI. Es gibt auch kleine HDMI Mini-Monitore u.ä. die man dafür verwenden kann. Auch GUI, siehe oben.

Ja verstehe ich, aber gleich die Postings von rif und mir gnadenlos zu löschen ? Verschieben ins neue Thema wäre da etwas diplomatischer gewesen. Zumal ich hier immer noch OnDevice lese War ja nicht böse gemeint . Im anderen Thread würden die Beiträge ja nichts direkt beitragen und eher verwirren.

Objective-C ist abwärtskompatibel zu C. Man kann also die C/C++ Bindings verwenden. Das tun wir ja auch in unseren iOS Beispiel-Apps.

OnDevice/Standalone Diskussionen bitte hier fortführen: http://www.tinkerunity.org/forum/index.php/topic,2127.0.html Ich hab die Kommentare dazu mal gelöscht, dieser Thread ist für neue Bindings .

Bitte lest diesen Eintrag bis zum Ende bevor ihr abstimmt! Wir haben nun schon seit längerer Zeit festgelegt, wie wir eine Standalone/OnDevice Lösung anbieten wollen. Dazu haben wir eine riesige Menge Feedback gesammelt und ausgewertet und sind zum Schluss gekommen das wir einen Brick im Stack benötigen auf dem man die Programmiersprachen unserer normalen Bindings ausführen kann, sowie mit der Außenwelt kommunizieren kann. Die einzige Möglichkeit die wir sehen dies zu realisieren ist ein kleines Brick auf dem ein Linux läuft. An der Umsetzung dieses Bricks arbeiten wir nun schon eine ganze Zeit. Das neue Brick wird bei uns unter dem Codenamen "RED Brick" (Rapid Embedded Development Brick) entwickelt und wir haben es bis auf 3 mögliche Varianten heruntergebrochen die wir nun vorstellen wollen: Variante 1: Unterseite: Board to Board und Micro SD Karte Spezifikation: Single Core 1GHz, 512MB Größe 4x4cm Integriert sich in Stack wie ganz normaler Brick SPI Kommunikation im Stack durch Linux Kernel Linux Kernel unterstützt Ethernet Extension Verkaufspreis (inkl. MwSt): ~99€ Variante 2: Unterseite: Board to Board und Micro SD Karte Spezifikation: Single Core 1GHz, 512MB Größe ~4x6cm Integriert sich in Stack wie ganz normaler (etwas zu großer) Brick Inklusive Ethernet anschluss SPI Kommunikation im Stack durch Linux Kernel Verkaufspreis (inkl. MwSt): ~129€ Variante 3: Unterseite: Micro SD Karte, kein Board to Board! Spezifikation: Dual Core 1,5GHz, 512MB Größe ~5x8cm Inklusive Master Brick Dadurch inklusive 4x Bricklet-Stecker Inklusive Ethernet anschluss Inklusive Step-Down Power Supply SPI Kommunikation durch Master Brick, kein spezieller Linux Kernel notwendig (dadurch sind beliebige Distributionen usw möglich) Verkaufspreis (inkl. MwSt): ~179€ Hierbei handelt es sich im wesentlichen um Variante 2 bei der an dem Embedded-PC ein Master Brick direkt per USB angeschlossen wurde. Zusätzlich befindet sich eine Step-Down Powersupply auf dem Board, da dieses bei der Größe immer das unterste Board sein muss und somit keine Step-Down Powersupply mehr druntergesteckt werden kann. Allgemeine Informationen: Aus Nutzersicht ist das RED Brick eine "Blackbox". D.h. es werden _keine_ Linux Kenntnisse benötigt. Dazu würden wir gerne ein Webinterface bieten mit dem man Programme hochschieben kann, einstellen kann wann sie ausgeführt werden sollen, ob sie beim Start ausgeführt werden sollen, ob sie bei Absturz neugestartet werden sollen, usw. Hier planen wir sehr viele Einstell- und Diagnosemöglichkeiten (CPU Last, Logs etc)! Jetzt kommt die Krux: Dieses Webinterface ließe sich ganz einfach über einen Browser in Variante 2 und 3 abrufen. In Variante 1 müsste man dazu zusätzlich die Ethernet Extension oder ein WIFI Stick nutzen um Daten auf das RED Brick zu übertragen Konfigurations-Alternative 1: Im Brick Viewer könnte eine Konfiguration erstellt werden. Diese wird per USB Stick auf das RED Brick übertragen Konfigurations-Alternative 2: Über die Micro USB Schnittstelle wird das RED Brick mittels des Brick Viewers konfiguriert. Recht aufwändig unter den verschiedenen Plattformen zu implementieren Das Web Interface über Ethernet/WIFI hat auch den weiteren Vorteil das man es über Handys und Tablets benutzen könnte. Hinweise: Natürlich ist auch das RED Brick Open Source und es gibt für jemanden mit Anfänger-Linux Kenntnissen z.B. die Möglichkeit eine USB Webcam anzuschließen und auszulesen oder ein Videos über den HDMI Port zu streamen... Nachtrag/Anmerkungen: Parallel zum oben genannten Konfigurationsinterface(Web, USB-Stick) wird es eine Konfigurationsmöglichkeit per Mini USB geben müssen (Fallback) Alternativ zu Ethernet könnte man auch einen kleinen WIFI Stick in die USB Host Buchse stecken. Problem hierbei: Wie werden die Netzeinstellungen konfiguriert? Variante 2+3 unterstützen kein PoE, da keine zusätzliche Ethernet Extension nutzbar ist Eine Unterstützung der WIFI Extension ist nicht geplant, da auf kostengünstige standard WIFI Sticks zurückgegriffen werden kann Es ist geplant ein Linux Image zu bieten auf dem alle häufig genutzen Compiler (z.B. für C), VMs (für Java), Bibliotheken, etc. vorinstalliert sind. Der Standardnutzer muss also wirklich nur sein Programm hochladen und es wird auf dem RED Brick ausgeführt. Zusätzliche Libs können, unter mit notwendigen Linux Kenntnissen (SSH, APT-GET), nachinstalliert werden

Ich denke die Perl Bindings sind hinreichend nicht-kommerziell das O’Reilly da nichts gegen hat .

Der Master weiß nichts über seine Bricklets. Wenn er das würde, würde er ja auch jedesmal geupatet werden müssen wenn man irgendein Bricklet updatet und es würde eine unglaubliche Menge von Abhängigkeiten geben (Brick Version X.Y funktioniert mit Bricklets Version A.B und C.D und ...). Desweiteren sind alleine die Configs für die Bricklets (also die Beschreibung für die Bindings) 788KB groß, der Master Brick hat 256KB flash. Die Tatsache das die Bricks keine Bricklets kennen müssen macht unser System erst so dynamisch. Ohne wäre das alles uninteressant.

Die Bindings bieten aber ja wohl eine deutliche "angenehmere" API an. Und so ist es mit HTTP-Requests auch. Es ist doch einfacher einen simplen HTTP-Request abzusetzen (das kann man sogar komplett ohne Programmierung in jedem Browser) als sich die einzelnen Bits und Bytes für das TF-Protokoll zusammenzupfriemeln (das ich mir persönlich noch nicht einmal angeschaut habe). Das siehst du falsch. Der Master sieht sowas wie "FID=1, UID=xyz, length=20, data=[...]". Die Daten sind absolute Binärdaten, das könnte jetzt 20x uint8 sein, oder 5x uint32 oder nen string aus 20 Zeichen. Mehr Informationen sind nicht da. Natürlich könnte ich jetzt hergehen und die Daten in Base64 kodieren und als Antwort auf ein HTTP Get zurücksenden. Aber das wäre in keinster weise einfacher zu parsen als das was wir aktuell direkt auf den Sockets verschicken. Die Informationen die in den Bindings steckt, nämlich wie der Aufbau der Daten für eine gegebene FID ist, die hat der Master nicht.

Dieses "HTTP Request Protokoll" wäre dann aber nur unser ganz normales Protokoll mit mehr Boilerplate. Da sehe ich jetzt auch nicht den Vorteil. Jede Sprache die HTTP Requests absetzen kann, kann auch einen ganz normalen "TCP/IP Socket" nutzen.

Du hast die Entprellzeit für den Flankenzähler nicht eingestellt. Der Standardwert dafür ist 100ms, was 5Hz entspricht wenn die "high" und "low"-Zeiten je gleich lang sind. Streu mal an einer strategischen Stelle folgendes ein : // Eingang 0 (=bitmask 1), Steigende Flanke, Debounnce 5ms (max ~100Hz) idi4.setEdgeCountConfig(1, BrickletIndustrialDigitalIn4.EDGE_TYPE_RISING, (short)5); das "setDebouncePeriod" setzt nur die Entprellzeit für den InterruptListener.

12Hz sollte kein Problem sein, kannst du den Source Code den du benutzt um das auszulesen hier posten?

Um ganz ehrlich zu sein hatten wir das nicht richtig ausprobiert. Der Hersteller hat uns die angeboten und wir haben sie mit aufgenommen. Ich hatte einen kurzen 1m Strip durch einen der Schläuche (mit viel mühe) geschoben und es nie mit 5m probiert. Wir haben den Hersteller gefragt und er wusste auch nicht so recht wie das gehen soll . Wir haben jetzt vom Hersteller Silikonschläuche bekommen die bereits einen Faden durchgezogen haben. Ich würde jedem mit Problemen (also vermutlich jedem mit einem Strip > 2m) anbieten den neuen Silikonschlauch zu schicken. Dazu bitte eine Email mit Bestellnummer an olaf@tinkerforge.com schicken.

http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html#disconnect_probe

Das gucke ich mir gerade an. Dafür müssten wir einen kleinen Webserver sowie das Websocket Handshaking implementieren. Das Handshaking nutzt HTTP als Protokoll (deswegen einen Webserver) und es muss leider über Hashes ein Globally Unique Identifier berechnet werden (Sec-WebSocket-Key). Dabei teilt der Client dem Server dann mit welches Protokoll er sprich (in unserem Fall tfp) und dann danach könnte dann ganz normal TCP/IP gesprochen werden. So ist aktuell mein Verständnis . Klar.

Equinox hat das gut zusammengefasst. Ich hab mal ein bisschen rumgebastelt und folgendes gebaut: Einen kleinen Websocket-Server mit libwebsocket (http://libwebsockets.org/trac/libwebsockets) der ein Enumerate auf einem Brick aufrufen kann Eine kleine Webseite die Code beinhaltet die mit Websockets (per JavaScript) auf auf den Server zugreift und das Enumerate aufruft und die Rückgabe ausgibt. Das funktioniert einwandfrei. Mein Gedanke ist folgender: Brickd könnte auf einem weiteren Port einen Websocket öffnen auf dem über Websockets unser ganz normales Protokoll gesprochen wird. Dazu könnte man dann "echte" JavaScript Bindings machen. Dann könnten wir einen Online Brick Viewer anbieten den ihr aufrufen könntet der dann eine Webseite bei uns vom Server holt die sich lokal mit dem Brickd verbindet. Dabei liefern wir nur das HTML/JavaScript, wir kriegen nichts von den Daten mit, die bleiben komplett auf eurem Rechner. Damit hätten wir dann einen brickv den man nicht installieren muss der auf Handys/Tablets etc läuft. Was meint ihr, macht das Sinn?

Du hast das schon richtig verstanden. Node.js/JavaScript wäre ein weiteres Binding, genauso wie PHP.

das Disconnect schließt nicht die Verbindung des Brick Viewer. Allerdings kannst du z.B. mit deinem Programm die Callbacks umkonfigurieren, was dann auch den Brick Viewer beeinflusst. Oder umgekehrt wenn du den Brick Viewer beendest stellt er alle Callbacks aus was dein Programm beeinflussen kann.

Die IP die du beim Brick Viewer eingetragen hast ist aber zeigt aber auch auf einen Rechner an dem der Master Brick angeschlossen ist, ja?

Das Programmiermodell in node.js ist absolut asynchron. Dadurch sieht das JavaScript dort ganz anders aus als man es für den Browser schreiben würde. Hinzu kommt das die Bindings für node.js auf dem net package basieren (http://nodejs.org/api/net.html) müssen, welches im Browser nicht existiert. Da wird man also zumindest nicht den kompletten Code wiederverwenden können, evtl aber einen Teil. Dazu müsste ich mir das aber erst genauer angucken und einen Mockup schreiben.

Node.js ist ein Webserver den man mit JavaScript programmieren kann. Node.js läuft nicht im Browser, ein Großteil von Node.js ist in C++ geschrieben...

Genau, geschickter als JavaScript direkt zu nutzen. Also die Anwendung ist doch einen eigenen Webserver im eigenen LAN zu besitzen der Webseiten anzeigt? Ja aber gerade dieser Use Case ist doch schon perfekt abgedeckt? Wenn ich doch einen Webserver im eigenen LAN hab dann schließe ich da doch einfach die Bricks via USB oder Ethernet an, lese die Daten mit einer Programmiersprache meiner Wahl aus und zeige sie auf der Webseite an. Es macht doch nur Sinn den Code im Client (also im Browser) auszuführen wenn der Server selbst keinen Zugriff auf die Bricks hat. Ich handel mir doch sonst nur Probleme ein. Wenn ich mit meinem Handy von extern die Webseite aufrufe und der Code im Browser läuft dann muss ich die IP von mir zuhause kennen, der Port muss freigeschaltet sein, da gibt es offensichtliche Sicherheitsprobleme etc. Wenn die Bricks/Bricklets aber vom Server abgefragt werden und die Daten einfach auf der Webseite angezeigt werden kann ich von überall drauf zugreifen ohne auch nur irgendwelche Probleme zu erwarten. Oder nicht?

Mh. Vielleicht kenne ich mich bei den Webtechnologien einfach nicht gut genug aus um das zu verstehen . Ist es nicht viel geschickter die Verbindung zum Brick/Bricklet auf der Server Seite mit Python/Ruby/PHP aufzubauen und die eigentlichen Daten über REST/Websockets mit HTML5/JavaScript auf der Client Seite abzufragen? Wenn jeder Aufrufer einer Webseite selbst eine Verbindung zum Brick herstellt ist doch die USB Bandbreite super schnell aufgebraucht. Was ich sehen kann ist folgendes: Angenommen man würde Bindings für JavaScript mit den Chrome Sockets machen (http://developer.chrome.com/apps/socket.html), dann könnte man einen Online Brick Viewer entwerfen und man müsste keine Anwendung mehr installieren sondern könnte einfach eine Webseite (mit Chrome) bei uns aufrufen um sich seine lokalen Bricks/Bricklets anzusehen. Das hat aber natürlich den Nachteil das der Brick Viewer nur noch funktioniert wenn man auch Zugriff zum Internet hat, das ist auch komisch .

OK . Welche Sprache würdest du denn denn verwenden wollen um das JSON o.ä. auszulesen und in welcher Umgebung?

Ich verstehe die Logik nicht . Angenommen ein Master Brick könnte eine JSON API anbieten, wie würde dann etwas Standalone auf dem Brick laufen? Oder meinst du einfach das man direkt über TCP/IP mit dem Brick kommunizieren kann? Dafür haben wir doch schon die Ethernet Extension!

In der Tat, da war ein copy&paste Fehler . https://github.com/Tinkerforge/brickv/commit/e54131739309c076d1c18d4eb87ec44d34050b29 Ist dann im nächsten brickv Release gefixt.