[Umfrage] Standalone/OnDevice Lösung

[batti]

Bezüglich des Releases haben wir noch keinen offiziellen Termin.

Wir fangen jetzt mit der Entwicklung des Prototypen an. Das wichtigste wird dann sein diesen stabil zum laufen zu bringen. Wenn das geschafft ist muss der SPI Treiber für den Stapelbetrieb geschrieben werden und Brickd erweitert werden. Ist dies vollbracht, dann könnte eine Art "Developer Version" veröffentlicht werden, die noch nicht das Webinterface etc. bietet. Zeitlich möchte ich mich hier nicht festlegen. Wir werden euch über den Blog auf dem Laufenden halten.

[Plenz]

Ich warte schon lange sehnsüchtig auf eine Standalone-Lösung, aber was in dieser Umfrage vorgestellt wird, ist für mich mit Kanonen auf Spatzen geschossen.

 

Ich habe schon so komplizierte Sachen wie die Auswertung eines GPS-Empfängers und Ausgabe der Ergebnisse auf einer LCD-Anzeige und Simulation eines Funkuhr-Zeitsignals auf einer simplen C-Control realisiert - alles ohne Linux, HDMI, Ethernet etc. Und für meine TF-Sachen brauche ich auch nicht mehr: Messwerte von Brick(let)s auslesen, verarbeiten, andere Brick(let)s ansteuern. Und diese Aufgabe würde ich gern von meinem Notebook in den Brickstapel verlagern, damit alles kompakter ist, weniger Strom braucht und vor allem damit der Mess- und Steuervorgang viel öfter pro Sekunde wiederholt werden kann, als es USB erlaubt.

 

Optimalerweise hätte ich gern eine Software, mit der ich solche Aufgaben lösen kann, ohne dass ich mich lange in die Firmware der Einzelteile einarbeiten muss. Das resultierende Programm wird in einen Brick geschrieben, und fertig - so wie bei der C-Control.

 

Als nächstes würde ich den RPi ins Auge fassen, eben wegen des günstigen Preises. Ich habe hier erwähnt gesehen, dass man damit Brick(let)s ansteuern könnte - ist das irgendwo genauer dokumentiert?

 

Als letztes käme dann die Variante mit 99 Euro in Frage, aber eigentlich würde mir auch diese schon echt weh tun, da müsste ich mich fragen, was rechtfertigt diesen Preis? Doppelte Geschwindigkeit gegenüber dem RPi? Das wäre für mich kein Argument. Die Vergleichsbasis ist für mich USB: z.B. beim IO-16 maximal 400 Abfragen pro Sekunde und ganz besonders all die Verzögerungen, bis so eine Abfrage vom Notebook registriert, ausgewertet und beantwortet wurde. Wie schnell würde das mit einem RPi gehen, und wäre das nicht bereits so unglaublich schnell, dass eine doppelte Geschwindigkeit keine spürbare Verbesserung mehr wäre?

 

[borg]

Ich habe schon so komplizierte Sachen wie die Auswertung eines GPS-Empfängers und Ausgabe der Ergebnisse auf einer LCD-Anzeige und Simulation eines Funkuhr-Zeitsignals auf einer simplen C-Control realisiert - alles ohne Linux, HDMI, Ethernet etc. Und für meine TF-Sachen brauche ich auch nicht mehr: Messwerte von Brick(let)s auslesen, verarbeiten, andere Brick(let)s ansteuern. Und diese Aufgabe würde ich gern von meinem Notebook in den Brickstapel verlagern, damit alles kompakter ist, weniger Strom braucht und vor allem damit der Mess- und Steuervorgang viel öfter pro Sekunde wiederholt werden kann, als es USB erlaubt.

 

Optimalerweise hätte ich gern eine Software, mit der ich solche Aufgaben lösen kann, ohne dass ich mich lange in die Firmware der Einzelteile einarbeiten muss. Das resultierende Programm wird in einen Brick geschrieben, und fertig - so wie bei der C-Control.

Das kann ich nachvollziehen, aber wir wollen ja gerade Leute ansprechend die nicht unbedingt low-level C schreiben können und auch nicht lernen wollen. Wir haben eine C API ja in betracht gezogen, allerdings haben wir uns auf Grund der überwältigenden Anzahl von Anfragen Java/Python/C# etc. im Stack auszuführen dagegen entschieden.

 

Als nächstes würde ich den RPi ins Auge fassen, eben wegen des günstigen Preises. Ich habe hier erwähnt gesehen, dass man damit Brick(let)s ansteuern könnte - ist das irgendwo genauer dokumentiert?

Wir haben hier eine kleine Anleitung: http://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html

 

Als letztes käme dann die Variante mit 99 Euro in Frage, aber eigentlich würde mir auch diese schon echt weh tun, da müsste ich mich fragen, was rechtfertigt diesen Preis? Doppelte Geschwindigkeit gegenüber dem RPi? Das wäre für mich kein Argument. Die Vergleichsbasis ist für mich USB: z.B. beim IO-16 maximal 400 Abfragen pro Sekunde und ganz besonders all die Verzögerungen, bis so eine Abfrage vom Notebook registriert, ausgewertet und beantwortet wurde. Wie schnell würde das mit einem RPi gehen, und wäre das nicht bereits so unglaublich schnell, dass eine doppelte Geschwindigkeit keine spürbare Verbesserung mehr wäre?

Das RPi ist ein Linux Board mit dem man Bricks/Bricklets ansprechen kann, das RED Brick ist ein Brick mit dem man Hochsprachen einfach im Stack ausführen kann.

 

So muss man den vergleich vielleicht betrachten. Je nach Anwendung und Wissensstand mag das RPi genauso gut geeignet und günstiger sein. Aber das ist ja auch nicht schlimm .

[AuronX]

und vor allem damit der Mess- und Steuervorgang viel öfter pro Sekunde wiederholt werden kann, als es USB erlaubt.

 

Wie du vielleicht gelesen hast (oder auch nciht, ist etwas begraben glaube ich) kann diese spezielle Kanone nicht mehr als 1000 Messages pro Sekunde...

 

ich würde sagen nimm den Pi, wenn du im RED keinen Vorteil siehst

 

edit: falsche zahl korrigiert ^^

[jan]

nicht mehr als 100 Messages pro Sekunde

nicht mehr als 1000/sec

[Nic]

Beim RasPi werden die Bricks/Bricklets direkt am USB Port angeschlossen, also werden die 1000/sec (theoretisch) je nach Host-Betriebssystem-"Bremsen" erreicht.

 

Beim RED-Brick erfolgt aber die Kommunikation zw. Host-PC und Bricks/Bricklets über die Board2Board-Connectoren bzw. über das SPI-Interf. wozu aber noch die Treiber geschrieben werden müssen, d.h. die 1000/sec sollten dann im Idealfall auch praktisch erreicht werden !?

 

Es dann zusammen 3 Varianten des OnDevice-Progr. möglich:

1) C-Coding direct auf den 32-Bit ARMs der Bricks wie schon einige Freaks in der Vergangenheit gemeldet haben

2) Hochsprachen auf dem raspPi, Kommun. via USB

3) Hochsprachen auf dem RED, Kommun. via SPI

[AuronX]

Ist die Kommunikation über SPI wirklich so viel besser als USB? Kann ich mir nicht vorstellen.

 

@TF: Habt ihr da eine Erwartungshaltung zu?

[Equinox]

Hallo,

 

einen Wunsch habe ich noch für die OnDevice-Lösung (egal für welche Variante ihr euch entscheidet): Bitte sorgt dafür, dass man alle Bricks und Bricklets (also auch die Master Bricks) ohne USB flashen kann, d.h., dass man die Firmware auch über WiFi. bzw. Ethernet updaten kann, ohne den Stapel "abzubauen".

Meint ihr, dass das geht?

[batti]

Ist die Kommunikation über SPI wirklich so viel besser als USB? Kann ich mir nicht vorstellen.

 

@TF: Habt ihr da eine Erwartungshaltung zu?

Die 1000 Nachrichten sind zum einen über die USB Schnittstelle begründet, die dann ja wegfallen würde, aber auch die ganze Software ist daraufhin designed (1ms Tick Task etc.). Daher wird auch die SPI Lösung nicht mehr Nachrichten erreichen können.

 

einen Wunsch habe ich noch für die OnDevice-Lösung (egal für welche Variante ihr euch entscheidet): Bitte sorgt dafür, dass man alle Bricks und Bricklets (also auch die Master Bricks) ohne USB flashen kann, d.h., dass man die Firmware auch über WiFi. bzw. Ethernet updaten kann, ohne den Stapel "abzubauen".

Meint ihr, dass das geht?

 

Das wird nicht gehen. Zumindest nicht das ein beliebiger Teilnehmer im Stapel geflasht werden kann. Da werden wir erstmal bei USB bleiben müssen.

 

[Nic]

Die 1000 Nachrichten sind zum einen über die USB Schnittstelle begründet

Wenn es ich es noch richtig in Erinnerung habe, durch das OS-eigene USB-Pooling. Aber sind die 1000/sec dann eher ein Benchmark in der Theorie ?

aber auch die ganze Software ist daraufhin designed

Ja, aber nur aufgrund der o.g. Prämisse. SPI würde aber für die Zukunft u.U. mehr Performance nach oben hin möglich machen, oder zumindest zuverlässiger als USB die 1000/sec Benchmark treffen ?

[borg]

1000 Nachrichten/Sekunde ist das Maximum was die USB Spezifikation zulässt für die USB Version und USB Class die wir nutzen.

 

Bzgl der SPI Performance können wir erst eine Aussage treffen wenn wir da wirklich einen Treiber für fertig haben. Die SPI Schnittstelle wird auf jeden Fall nicht mit anderen Teilnehmern geteilt (Maus, Tastatur, USB Festplatte etc), dadurch sollte sie in dem Sinne schon zuverlässiger sein vom Durchsatz her.

[Equinox]

Zitat

 

    einen Wunsch habe ich noch für die OnDevice-Lösung (egal für welche Variante ihr euch entscheidet): Bitte sorgt dafür, dass man alle Bricks und Bricklets (also auch die Master Bricks) ohne USB flashen kann, d.h., dass man die Firmware auch über WiFi. bzw. Ethernet updaten kann, ohne den Stapel "abzubauen".

    Meint ihr, dass das geht?

 

Das wird nicht gehen. Zumindest nicht das ein beliebiger Teilnehmer im Stapel geflasht werden kann. Da werden wir erstmal bei USB bleiben müssen.

 

Was meinst du mit "beliebiger Teilnehmer im Stapel"? Was würde denn gehen?

 

Geht es über den USB-Anschluss des RED, d.h. wenn ich ein USB-Kabel vom RED zum Master Brick anschließe? Das würde notfalls auch reichen.

[Nic]

Hmh, erstmal wichtiger wäre den Stack nicht immer zu demontieren, wenn geflasht wird. Gut möglich dass so ein embedded System später irgendwo schwer zugänglich verbaut ist. Über das "wie die FW den Devices zugeführt wird", wäre ich nicht so wählerisch.

[Loetkolben]

Hallo,

einen Wunsch habe ich noch für die OnDevice-Lösung (egal für welche Variante ihr euch entscheidet): Bitte sorgt dafür, dass man alle Bricks und Bricklets (also auch die Master Bricks) ohne USB flashen kann, d.h., dass man die Firmware auch über WiFi. bzw. Ethernet updaten kann, ohne den Stapel "abzubauen

 

Eigentlich wollte ich das Thema nicht wieder ansprechen, aber wenn Equinox es schon macht, dann schliesse ich mich an. 

 

Gerade bei remoooooote genutzter Hardware waere das eine Erleichterung. Das flashen per USB und Commandlineinterface ist schon prima, aber den "Knopf" muss der Anwender in der Ferne immer noch druecken.

 

Vielleicht kann man die RED Hardware so designen, dass man GPIO Pins (per Loetkolben) mit den anderen Bricks verbinden kann und somit das flashen moeglich macht.

 

 

Der Loetkolben

[mchott]

Gerade in meinem neuen Projekt arbeite ich wieder mit der Kombo Raspi+Master+...

 

Ich verstehe nicht so ganz genau, warum man auf dem RED-Brick ein Ethernet, WLAN oder dergleichen brauchen würde...dafür gibt es doch Bricks. Mir würde quasi ein Ersatz für den Raspi reichen. Auf dem läuft bei mir zwar leider ein PHP-Code (weil ich nichts richtiges kann), aber das läuft immer super.

 

Mir wäre ein "dummes" aber kleines System lieber, als eine Erweiterung, die so groß ist, wie mein Raspi, denn dann ist der günstiger.

 

Sorry...das war nur eine Meinung.

[batti]

Vielleicht kann man die RED Hardware so designen, dass man GPIO Pins (per Loetkolben) mit den anderen Bricks verbinden kann und somit das flashen moeglich macht.

Das Problem dabei ist, dass viele GPIO's im Stapel mit allen Teilnehmern verbunden sind. Um gezielt einen Teilnehmer flashen zu können muss ich diesen einzeln adressieren können. Dies ist bei unserer Hardware aber nicht möglich.

 

Das USB Host vom RED Brick ist ein ganz normaler USB Anschluss und kann auch genauso verwendet werden. D.h. das Flashen eines Bricks ist darüber auch möglich. Die Frage ist dann nur wie dieser in den Bootloader kommt.

[Equinox]

Hallo,

 

Das USB Host vom RED Brick ist ein ganz normaler USB Anschluss und kann auch genauso verwendet werden. D.h. das Flashen eines Bricks ist darüber auch möglich. Die Frage ist dann nur wie dieser in den Bootloader kommt.

 

So wie jetzt auch, oder? D.h. mit dem RED Brick muss ich zum Stapel gehen, diesen in den Bootloader-Modus versetzen und kann dann über den RED USB Host-Anschluss die Master Bricks flashen. Habe ich das richtig verstanden?

Anders gesagt: Man kann zwar nicht komplett von Remote (über WiFi) flashen, aber man spart sich zumindest den Abbau des Stapels, oder?

[batti]

Es ändert sich quasi nichts, nur dass der Rechner mechanisch mit im Stapel sitzt. Wenn Wifi im Stapel sitzt, dann muss der Stapel trotzdem auseinander genommen werden. Dies kann nur über eine neue Hardwareversion des Master Bricks gefixt werden.

[AuronX]

Wäre es nicht (für Lötfreunde) möglich, den Reset-Taster am Masterbrick des Stapels durch das RED-Brick auszulösen?

 

Ungefähr so (Achtung, ich weiß nciht was ich rede):

1. Reset-Knopf am Master ablöten

2. GPIO-Ausgänge die am RED übrig sind auf Kontakte des Reset-Knopf auflöten

3. per Software Reset auslösen

[Nic]

Es ändert sich quasi nichts, nur dass der Rechner mechanisch mit im Stapel sitzt. Wenn Wifi im Stapel sitzt, dann muss der Stapel trotzdem auseinander genommen werden. Dies kann nur über eine neue Hardwareversion des Master Bricks gefixt werden.

...was dann auch für alle anderen Bricks Stepper, Servo, DC zwecks FW Flashen bedeutet ? Mir ist immer noch nicht klar was das bedeutet, wenn ich die FW auf einem USB-Stick habe, der alternativ am USB-Host vom RED steckt ? Die FW könnte nicht autom. vom RED detektiert und an den passenden Brick gerootet werden ? Aber dann müsste der RED den Brick selber in den Bootloader schalten, was auch per SPI nicht geht ?

 

@AuronX: Der Erase müsste auch nach draußen geführt werden. Um den Brick in den BoLoader Modus zu bringen.

[P4trick]

Wie ist dsa eigentlich mit der Verfügbarkeit? Was schätzt ihr wie lange die Entwicklung dauert?

um März; Sommer oder eher Ende diesen- Anfang nächsten Jahres?

[batti]

Bei einer solchen Frage kann man sich weit aus dem Fenster lehnen. Wir haben ein so großes Projekt noch nicht gemacht, von daher ist es schwer abzuschätzen. Wir planen die Hardware (Linux Board) Mitte des Jahres fertig zu haben. Dann gibt es aber noch keine Unterstützung zum Hochladen von Programmen etc.

[The_Real_Black]

Kleine Frage zu dem OS, da ihr bereits geschrieben habt, dass ihr alle Bindings unterstützt (Java, C++), aber werdet ihr auch C# also Mono darauf direkt laufen lassen können?

Wenn ja läd man dann den Source auf den RED oder die Exe/dll?

 

[photron]

Sprachen die spezifisch für ein Betriebssystem oder eine Hardware Architektur kompiliert werden, müssen natürlich passend für das RED Brick kompiliert werden, bzw. können dann auf dem RED Brick kompiliert werden. Das wären z.B. C/C++ oder Delphi.

 

Java und auch C# verwenden aber Bytecode der nicht spezifisch für ein Betriebssystem oder eine Architektur ist. Das der C# Compiler .dll und .exe Dateien erzeugt heißt nicht, dass diese spezifisch für Windows wären. Eine unter Windows erstelle C# .exe Datei läuft unverändert unter Linux mit Mono.

[Plenz]

Als nächstes würde ich den RPi ins Auge fassen, eben wegen des günstigen Preises. Ich habe hier erwähnt gesehen, dass man damit Brick(let)s ansteuern könnte - ist das irgendwo genauer dokumentiert?

Wir haben hier eine kleine Anleitung: http://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html

 

Ich sehe, da war ich auf einem völlig falschen Dampfer. Ich hatte die Vorstellung, der RPi könnte Bricks direkt über die IO-Ports ansteuern. Was hier beschrieben wird, zeigt ja nur, wie man am anderen Ende des USB-Kabels einen RPi anschließt anstelle eines Notebooks.

 

Ich habe keine Vorstellung, wie lange es dauert, bis ein Signal von einem Bricklet durch eine lange Kette von Subroutinen gelaufen, in ein serielles Signal verwandelt, durchs Kabel geschickt, beim angeschlossenen Computer zwischen den Treibern herumgereicht ist und schließlich einen Interrupt ausgelöst hat, was dieser Computer noch alles für wichtiger hält, bevor er diesen Interrupt abarbeitet und wann das Signal endlich von meiner Steuersoftware verarbeitet wird. Aber wenn ich sehe, wann eine Handbewegung vor einer Webcam auf dem Bildschirm zu sehen ist oder wann ich einen Ton höre, wenn ein Microfon an eine USB-Soundbox angeschlossen ist, dann liegt die Verzögerung im dreistelligen Millisekundenbereich.

 

Dieser langen Weg wäre bei einer OnDevice-Lösung stark verkürzt, und ich hatte bei einer Steuerung durch einen RPi die Vorstellung für eine ähnlich straffe Signalverarbeitung.