borg

Ah! In dem Fall kommt der Stöpsel in die Mini USB Buchse vom RED Brick . Edit: Also hier nur zur Konfiguration! Der RED Brick taucht nicht als Brick am PC auf.

Das geht natürlich, ist aber schon eine komische vorgehensweise . Leider nicht. Variante 1 hat ja kein cortex-m3 mit drauf. Wir können aber die Bricklet Plugins nicht mit dem cortex-a8 ausführen den wir auf dem RED Brick verwenden werden. Das ist also nicht kompatibel. Wenn man Bricklet Stecker mit auf dem RED Brick haben will geht das nur über die vorgehensweise in Variante 3. Mehr als ein ein DDR RAM Chip passt vom Platz leider nicht drauf. Ein 1GB RAM IC ist unverhältnismäßig teuer. Den kann man evtl. später anfangen zu bestücken wenn die RAM Preise fallen .

Wie meinst du das? Du möchtest einen Master Brick der auf dem RED Brick steckt zusätzlich per USB an einem anderen PC anschließen? Das geht nicht. Du kannst dich von diesem PC aus aber direkt auf die IP des RED Brick verbinden, das ist also kein USB notwendig an der Stelle. Ein Brick Viewer auf dem RED Brick sieht die Bricks/Bricklets genauso als wären sie per USB angeschlossen, genau. Genau. Das wäre die vorgehensweise. Wenn man Ethernet mit DHCP benutzt wird man USB denke ich nicht brauchen.

In Variante 3 wäre ein SAM3S4C Microcontroller mit dem auf dem RED Brick. An diesem wäre alles genauso angeschlossen wie auch beim Master Brick, bis auf USB. USB wäre direkt mit dem RED Brick verbunden. Das wäre für uns natürlich wenig Entwicklungsaufwand. In Variante 1+2 müssten wir einen Linux Kernel Treiber schreiben der die SPI Kommunikation des Master Bricks übernimmt. Klar!

Was heißt das genau? Geht die WIFI Extension nur nicht zum Hochschieben der Programme oder grundsätzlich nicht? Auch nicht bei der Variante mit Master Brick? Bei der Variante mit Master Brick macht die WIFI Extension keinen Sinn. Der Master Brick ist ja per USB (intern über die Leiterplatte) mit dem RED Brick verbunden. In unserem aktuellen System kann man ja auch kein USB und WIFI gleichzeitig nutzen. Für Variante 1 können wir für die Ethernet Extension einen Linux Kernel Treiber schreiben. Das hab ich mir genauer angeguckt, das ist definitiv möglich. Wir können allerdings keinen Linux Kernel Treiber für die WIFI Extension schreiben. Das Interface des WIFI Moduls ist absolut nicht kompatibel mit den sonst üblicherweise verwendeten WIFI ICs. Es ist für uns unmöglich dafür einen Linux Kernel Treiber zu schreiben.

Als Nachtrag: Bei Ethernet in Variante 1 hätte man natürlich auch die Möglichkeit den kompletten Stack inkl. RED Brick über PoE zu versorgen. Dies wäre bei Variante 2 und 3 oder mit WIFI nicht möglich.

Stromversorgung wäre über Mini USB (5V) oder über Step-Down Power Supply möglich. Genauso wie bei dem Master Brick und Also könnte man die Entwicklung in der IDE auch gleich auf dem RED direkt machen ohne Hochladen bzw. Deployen ? Das wäre möglich. So hoch wie der Stepper Brick, genau.

Ist schon klar, aber AuronX schlägt vor die HDMI wegzulassen, wie kann dem Benutzer dann das GUI vermittelt werden ?! Ah sorry, das hab ich nicht kapiert. Ohne HDMI gibt es natürlich keine Grafikausgabe. Ah! Ja genau. Das Programm läuft in einer Art Kiosk-Modus . Aha, d.h. kein Umweg über USB an das Steuerprogramm im Betriebssystem. Direkterer Weg also doppelt so schnell als mit Host-PC, also doppelt so schnelle Callbacks pro Sec als mit USB ? Da ist ein Geschwindigkeitsvorteil möglich. Wir haben bisher aber den SPI Linux Treiber noch nicht vollständig fertiggestellt, da können wir also erst wirklich genaue aussagen machen wenn es soweit ist.

Für eine GUI Applikation kannst du alles verwenden was es auch unter Linux gibt. Zum Beispiel Qt, GTK, LCL (ähnlich zu VCL, Delphi), Swing und AWK (Java), etc.

Warum wir gerne Ethernet haben möchten haben wir ja beschrieben, aber wir haben ja auch in Variante 1 drauf verzichtet. HDMI und USB-Host Kosten nur soviel wie 2 Buchsen, also 3€ in Summe. Das ist es denke ich Wert.

Das wird auf jeden Fall möglich sein! Der Preisanteil ist nur die HDMI Buchse selbst. Der Prozessor den wir verwenden werden hat eine direkte HDMI ausgabe. Also sowas wie 1,50€.

Klar geht das. Ist halt nicht so hübsch. Ich denke da z.B. an die Möglichkeit über ein Tablet ein Programm auf dem RED Brick über das Webinterface zu schreiben. Wir würden das aber machen wenn ihr die Variante vorzieht. Irgendeine Konfigurationsmöglichkeit muss es sowieso über USB geben. Zum Beispiel könntest du ja ein Netzwerk mit festen IPs verwenden. Da muss man dann dem RED Brick natürlich erst eine IP zuweisen bevor man Ethernet nutzen kann.

Was bedeutet Kiosk-Modus? Es sollte eigentlich nur die anfängliche Konfiguration notwendig sein. Größe, direkt per Board to Board Stecker benutzbar, viel einfacher zu bedienen, Performance ist ca. Faktor 2 zum RPi. Ist alles möglich wenn du das möchtest. Du könntest das RED Brick ohne Probleme als kleinen Office-PC nutzen .

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.