Nic

Halb so schlimm, also ich musste bei RED an das hier denken http://en.wikipedia.org/wiki/Red_Digital_Cinema_Camera_Company, aber ich glaube das liegt an den persönlichen Vorlieben

Ok, und dann gibt es sowas wie ne "Autoexec" wo ich festlege welche App überhaupt und in welcher Reihenfolge ausgeführt wird. D.h. beim Starten des RED im Kiosk-Modus soll zuerst App2, dann App3 usw.... Und die gleichzeitige Benutzung von Chibi-Funk-Stacks ist gewährleistet ? D.h. kann ich auf den Master/Red Stack noch eine ChibiExt. für den Chibi-Master draufsetzen ?

Was würde das genau heißen ? Muss hierzu das Zielverzeichnis bekannt sein ? Oder muss ich quasi als Admin das betreffende Zielverz. wählen ? Was bedeutet das für Mehrfachinstallationen oder geht immer nur 1 Application ? Kann ich mir das am RED so wie einen Autostart-Bereich vorstellen wo ich die oder nur das Programm reinschiebe ? Wenn ich soeinen Brick/RedStack über den MasterBrick USB an den normalen PC anschließe, kann ich weiterhin den Stack mit Viewer etc. benutzen wie bisher ? Oder müsste ich immer den RED abstecken ?

Sorry, aber Ihr solltet die Umfrage auch in English verfassen, bzw. im internationalen Forum vorstellen. Ev. als Extract oder Summe der bisherigen Diskussion.

Nehmen wir Variante 1: Wie erfolgt die Stromversorgung ? Immer über die Board2Board also auch über USB 5v, oder braucht es da eine StepDownSupply oder ähnliches ? und Also könnte man die Entwicklung in der IDE auch gleich auf dem RED direkt machen ohne Hochladen bzw. Deployen ? Varainte 1: Was wäre da die ungefähre Bauhöhe ? So hoch wie der Stepper ?

Ist schon klar, aber AuronX schlägt vor die HDMI wegzulassen, wie kann dem Benutzer dann das GUI vermittelt werden ?! Kiosk-Modus: http://de.wikipedia.org/wiki/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 ?

Dann sind aber nur Consolen-Anwendungen möglich ?

Es sind keine Script oder Batch sondern vollwertige Programme.

Hört sich alles prima an, besonders der Name RED Brick . Wenn also der Endbenutzer nicht sieht, ob oder welches OS dahintersteckt, kann ich mir die Arbeitsweise des RED-Brick also quasi als Kiosk-Modus vorstellen ? Aber ich müsste das auf dem Brick entsprechend einstellen, dass der RED nicht den Desktop sondern meine Application startet ? Ist dann administrativer Aufwand nötig ? Hört sich für mich nach einem embedded RaspPi an ? Welcher Vorteil ergibt sich gegenüber dem normalen RaspPi bzgl. Performance, Robustheit etc.. ? Wie sieht es aus mit der Verwendung von Touchscreens ? Maus, Tastatur alles über den USB-Host ? Bin gespannt was die anderen meinen ?... Hallo ?... OnDevice ist da...

Kann noch nicht ganz folgen: Also alles das was unter Linux-(RaspPi) läuft, egal ob in Java, Phyton oder C++ geschreiben wäre lauffähig ? Applicationen, mittels Delphi-Bindings wären nur soweit lauffähig, dass sie keine Windows-bezogene API verwenden ? Also Free Pascal Compiler/Lazarus kompatibel ? Was ist denn wenn meine Application UI/GUI-Interaktionen hat ? Wird deren Darstellung visualisiert ? Oder sprechen wir hier von den reinen Consolen-Anwendungen ?

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

In der Hoffnung dass mein Beitrag nicht gleich gelöscht wird mal gleich ein paar Fragen hinterhergeschoben: Es wird in den TF-Stack einfach ein Mini-Host verlagert, auf dem die offiziellen Java-Bindings laufen ? Blackbox meint mir als User ist es dann egal ob da ein Linux System läuft ? D.h. ich brauche keine bestimmte IDE um dann eigene Programme zu schreiben ? Was heißt Programme hochschieben ? Wie sehen die aus wenn mir das Betriebssystem als Blackbox egal ist ? Ich lass erstmal ein UI,Frontend, Gui etc. außen vor. Wie können wir aber Zusammenhänge zw. den Bricklets konzipieren/festlegen/programmieren oder scripten. Z.b. das der Callback eines Hall-Sensors einen Motor stoppt und so weiter ? Ev. bin ich zu sehr Linux-Laie, aber wie würde man sich dieses Linux vorstellen, mehr das Linux vom Rasp-PI oder eher ein Embedded-Linux, also ohne Multitasking-Overhead ?

Habe das Topic nur per Zufall entdeckt Also das gleiche würde ich mir auch für den Stepper- und Servo-Brick wünschen, hier gibt es den gleichen Effekt.

Wo "leben" diese Websockets ? Im Browser oder Server ? Bräuchte ich nur die clientseitige App ? Achso wenn ich die anderen Posts richtig lese, ist das im Browser via Javascript eine Websocket-Verbindung zum BrickD, der dazu angepasst werden müsste.

Jo, die Diskussion geht hier recht einseitig in Richtung Javascript clientseitig im Browser oder wenn ichs richtig verstehe mittels eines Webservers oder Webservice als Standalone Service/Server. Mal so nebenbei, werden Callbacks via Webservice oder Webserver unterstützt

Da würde ich spontan für dieses Basic entscheiden: Der TFT-Maximite hat einen Basic-Interpreter. http://geoffg.net/tft-maximite.html

Vielleicht klappt etwas Talkum-Pulver (Tafelkreide) als Gleitmittel auf der LED-Platinenunterseite. Alternativ einen passenden transparenten Schrumpfschlauch nehmen, je nach Schlauchdicke bleibt noch gewisse Restflexibilität. Alternativ Flüssiggummi mit Pinsel auftragen als Ersatz zum Silikonschlauch: PlastiDip Transparent http://www.plastidip.de.com/produkte/plasti-dip-flussiggummi/

Genau. Prima und danke für das erneute Angebot

Achso, an luxor erinnere ich mich auch. Aber das er ev. Sonderanfertigungen für die Community macht, ist doch sehr frei interpretiert Das waren Einzelstücke um die CAD 3D Modelle zu testen. Na soviel Möglichkeiten die TF Teile falsch herum zusammenzustecken gibt es ja nun nich. Wie gesagt ein Kit wäre prima, ev auch fix und fertich zusammengebaut, aber dann kostet eben Geld

Wurde hier in diesem Thread wie auch im letzten Jahr mindestens "1x pro Monat" nachgefragt . Sowas scheint aber Entwicklungsgelder zu benötigen und lässt sich nicht mal so übers Knie brechen. Hinzu kommt vermutl. auch die Ausrichtung des Sortiments bzw. Korrelation mit Prioritäten/Nachfragen anderer Teile. Oh, da habe ich was übersehen , kannst Du mal angegeben wer und wann das war.

Ich würde prinzipiell bei der TF-Architektur bleiben, d.h. nichts Proprietäres nur um Stromdaten zurückzufunken etc. sondern so eine Transceiver Einheit sollte auch für alle anderen Bricks und Bricklets zwecks bidirektionaler Kommunikation zur Verfügung stehen. Man sollte aber so ein Funkstack auch unabhängig vom 220v Netz betreiben dürfen eben wie einen klassischen Stack, auch außerhalb Wohngrenzen. Wo wir wieder beim Chibi wären Ich frage mich gerade ob das RemoteSwitch so leistungsfähig sein kann wie das alte Chibi, sprich ob es das Protokoll 2.0 auch vollständig unterstützen könnte ? Vielleicht äußert sich TF mal dazu ?

Ja, is so ? aber ich benutze seit knapp 1.5y 6 Chibis-Ext. in div.Projekten InOutdoor, und kann diese oft kolportierten Gründe nicht nachvollziehen. Mir ist auch nur 1 Fall eines Users bekannt wo die Freq. mit anderen Geräten störte. Ansonsten bin ich hier schon eine gefühlte Ewigkeit im Forum und meine ein überwiegend, positives Feedback anderer User zu lesen.

Damit ich es richtig verstehe, Du meinst das in der Super-Funksteckdose integriert und mit einem Transceiver a la Chibi-Ext. ? Ich auch , wenn überhaupt sowas in Planung ist , aber dann bitte als Kit. Hmh, und wann ?

Keine Ahnung ob das die Ursache ist, aber schließe die Bricklets nur so an die Ports, dass das Segment4x7 nur an Port A oder B hängt. Siehe http://www.tinkerforge.com/de/doc/Hardware/Bricklets/Segment_Display_4x7.html#bekannte-fehler-probleme ganz unten. Wenn das Problem immer noch da ist, mal nur jedes Bricklet alleine am Master anschliessen.

Hi Ishraq, welcome home to the TF world. Good to have a new member to empower the team and this Tinker community. I think new bindings for pearl is a good starting point.