Wie könnte ein Super-Master Brick aussehen?

[borg]

Ich kann mich da nur wiederholen: Die einzige "Hardwareerweiterung" die meiner Meinung nach Sinn machen würde, wäre ein Linux Brick (ein Raspberry PI im 4x4cm Format). Das wäre aber preislich leider nicht konkurrenzfähig. Vielleicht wenn wir irgendwann in 10000er oder 25000er Stückzahlen in China produzieren.

 

Einen weiteren Master Brick der einfach mehr Flash/RAM hat bringt nicht genug Vorteile. Ein "komplettes Java" oder "komplettes Python" mit der ganzen Standardbibliothek wird da nie drauf laufen. Dafür benötigt es nunmal ein "echtes" Betriebssystem (also Linux/Mac/Windows). Damit sind wir dann wieder beim Linux Brick .

[Equinox]

Warum wollt ihr die ganze Zeit Hardware-Erweiterungen? Es geht alles auch so.

 

Ich sehe das so: Bevor man viel Aufwand in eine Krückenlösung steckt, nur damit man OnDevice "irgendwie" eingeschränkt machen kann, halte ich es für viel sinnvoller, den Aufwand in eine richtige, gute Lösung zu stecken. Und wenn dazu ein neues Stück Hardware gehört, dann soll mir das recht sein. So wie es aussieht, macht es selbst bei der momentan verfügbaren Hardware Sinn, weitere Hardware zu entwickeln, nämlich den SD-Card Brick. Warum also nicht gleich einen "Super-Master"-Brick mit mehr Speicher und SD-Card-Slot entwickeln?

[FabianB]

Hinter dem Prinzip, was du vertrittst, stehe ich auch. Ich empfinde es halt nicht als Krückenlösung. Und ein Super-Master-Brick ist ein Bruder vom Raspberry Pi. Das haben wir -> brauchen wir nicht neu erfinden. Rechnet sich ja auch eh nicht.

Wer das mit dem Super-MAster machen will, kann jetzt schon den Pi nehmen. Es geht für mich eher darum, eine Lösung für die zu finden, die keinen Super-Master wollen/brauchen. Das sind einfach zwei verschiedene Zielgruppen. Die, die du vertrittst, ist aber schon bedient durch den Pi.

[AuronX]

1. Hardware-Diskussionen bitte woanders fortführen, die Python/C-Diskussion ist so schon komplex genug. Ich finde alle Wünsche toll, aber nicht in diesem Thread. Beitrag wurde verschoben, hier gehört die HW-Diskussion hin ^^

 

2. Dass OnDevice sinnvoll ist wissen hier genügend Leute, sieh es mal so:

Für deine Anwendungsfälle ist der Stromverbrauch egal genug, dass du dir um die 1-3 Watt des Raspberry Pi keine Sorgen machen musst. Da bin ich froh, dass es dir so geht. Andere hier müssen dadurch größere (schwerere) Akkus in ihre Rucksäcke stecken oder doppelt so oft in die Wildnis fahren um Batterien zu tauschen (oder doppelt so große Solar-Panels besorgen).

 

Wenn OnDevice für dich kein Thema ist, dann ist das gut, aber es ist definitiv kein "Fliegen auf Mist"-Thema, sondern eine echte Anforderung.

 

Ich verstehe deine Hardware-Wünsche auch noch nicht, aber deswegen behaupte ich nicht, dass sie unsinn sind und ich lasse mich (in einem anderen Thread) gerne erleuchten.

[Equinox]

Zu 1:

Ich bin mir nicht sicher, ob man das trennen kann/soll. Wenn OnDevice neue Hardware braucht, dann sollte das doch auch hier diskutiert werden.

 

Zu 2:

OnDevice ist für mich schon ein Thema, nur hätte ich es gerne eben "richtig" und gut. Bisher zumindest kam es in der Diskussion eher als Krückenlösung rüber.

 

Als einziges (einigermaßen nachvollziehbares) Argument kam bisher der Stromverbrauch. Du sprichst hier mobile Anwendungen an. Kannst du mal konkrete Beispiele dafür nennen, die auch praktisch von mehr als 20% der Nutzer umgesetzt werden? Und für die 1W für einen Raspi wirklich ein Problem ist?

[FabianB]

Ehrlich gesagt finde ich es langsam ein bisschen anstrengend. AuronX hat es jetzt doch schon recht deutlich gemacht.

Es ist ok, wenn du das alles anders siehst. Wir können das auch diskutieren, obwohl wir dich nicht von unserem Wunsch überzeugen müssen. Aber mach doch bitte einen neuen Thread dafür auf. Wir sehen das so, wie wir es schreiben und haben unsere Gründe dafür, das so zu wollen, wie es für dich als "Krückenlösung" erscheint.

Dementsprechend kannst du in einem anderen Thread über deine "richtige" und "gute" Lösung schreiben.

Wir wollen einfach was anderes als du möchtest.

 

Ich meine das wirklich nicht böse, aber diese Diskussion erinnert mich langsam an ein kindisches Hin-und-Her. Wir würden gerne beim Topic bleiben und da mal zu einem Ergebnis kommen.

[Loetkolben]

Als einziges (einigermaßen nachvollziehbares) Argument kam bisher der Stromverbrauch.

 

PRO OnDevice

 

2. Argument: Die Komplexitaet. Jedes Bauteil mehr macht Probleme. Insbesondere bei autonomen System sollte die komplexitaet und damit die Fehleranfaelligkeit moeglichst gering sein. Gerade weil der Raspberry ein richtiges OS hat kann er sich leichter aufhaengen als ein Embedded "Mini-OS", was nur fuer diese Speziaufgabe ausgelegt ist.

Weiterhin macht jedes Kabel und jede Steckerverbindung eine Baugruppe anfaelliger fuer Kontaktprobleme.

 

KISS

 

Der Loetkolben

[FabianB]

Also gut. Ich glaube, man kann diesen Thread auch genausogut schließen, zum eigentlichen Topic scheint es keine Argumente mehr zu geben.

 

 

Die TFler können sich ja jetzt überlegen, was aus ihrer Sicht am sinnvollsten ist und uns das Ergebnis dann mit weißem (Python) oder schwarzem © Rauch signalisieren. TinkerBasic wird dann pinker Rauch 

[Equinox]

Wir können das auch diskutieren, obwohl wir dich nicht von unserem Wunsch überzeugen müssen.

 

Es wäre aber schön, wenn ihr mich überzeugen könntet ...

 

Da außer mir wohl aber alle anderen eine Krückenlösung wollen und FabianB ein Ergebnis will, dann stimmen wir doch ab.

 

Abstimmungsmöglichkeiten (wie ich sie sehe, können auch erweitert werden):

• C auf momentaner Hardware
  
• Python auf momentaner Hardware
  
• "TinkerBasic" auf momentaner Hardware
  
• Keine Realisierung, bis "geeignete" Hardware vorhanden ist
   
  

 

Meine Reihenfolge:

[*]Keine Realisierung, bis "geeignete" Hardware vorhanden ist

[*]Python auf momentaner Hardware

[*]"TinkerBasic" auf momentaner Hardware

[*]C auf momentaner Hardware

[ArcaneDraconum]

Ich schließe mich dem an. Es ging ja ersteinmal darum Argumente für das eine, oder andere zu sammeln. Und was überhaupt gemacht werden soll.

 

Allerdings werden auch gleich neue Wünsche wach - und das finde ich auch gut. Die TF Hardware soll sich ja auch weiter entwickeln. Von daher finde ich so einen leidenschaftlichen Thread sehr schön

 

Ich möchte aber noch was zum Superbrick sagen, der so viel sparsamer als der Pi sein soll, aber viele Funktionen von diesem bietet. Genau das glaube ich nicht. Sobald da zusätzliche Bausteine drauf sitzen steigt auch der Stromverbrauch. Ich rechne den Pi mal auf 1 Watt hoch .... Wo liegt denn der Master jetzt?

[FabianB]

Leidentschaftliche geführte Threads finde ich auch gut, das zeugt in Interesse und einer aktiven Community. Ich finde hier ganz gut, dass die Diskussionen trotzdem ziemlich gesittet ablaufen. Es gibt Foren, da sitzen scheinbar nur Hater...

Wem/was genau schließt du dich an? Der Prioritätenliste von Equinox?

 

 

Meine sieht anders aus, wie man unschwer eraten kann 

 

 

1. Python (Wenn es im Vergleich zu der C-Variante die Funktionalität nicht zu extrem einschränkt)

2. C

3. TinkerBasic

 

 

Jeweils mit der vorhandenen Hardware.

Der Rest ist für mich uninteressant.

[ArcaneDraconum]

Eigentlich FabianB.

Ich denke die Entscheidung liegt bei TF. Wir haben mal Argumente gesammelt. Darum ging es ja.

Und klar geht es ersteinmal darum, es auf vorhandener Hardware zu realisieren.

 

Jede Einführung neuer Komponenten hat in letzter Zeit zu zahlreichen Firmwareupdates geführt. Keine Frage das ist alles sehr komplex und es kann nicht alles getestet werden. Wenn man gleichzeitig Hardware einführt und die Software mit neuen Funktionen ausstattet wird es u.U. Ziemlich nervig werden.

[borg]

Ich hab diesen Thread mal aus dem anderen herausgetrennt.

 

Wir werden ein On Device Programming Interface für die existierenden Bricks anbieten. Da brauchen wir nicht drüber diskutieren.

 

So ein Linux Brick oder Super-Master Brick ist natürlich auch eine Diskussion Wert. Anstatt darüber zu diskutieren ob es sinnvoller ist als ein On Device Programming Interface lasst uns darüber diskutieren wie so ein Super-Master Brick aussehen könnte.

 

Also: Was sollte ein Super-Master Brick können? Was unterscheidet es von einem Raspberry PI? Und was darf es kosten?

[ArcaneDraconum]

Naja spontan fällt mir ein. Er muss natürlich in den Stack passen. Aus Platzgründen würde ich keinen Kartenslot draufpacken, sondern reichlich Flash. Den Videoausgang würde ich auch für verzichtbar halten.

Im Prinzip haben wir Stromversorgung und Kommunikationsschnittstellen im Baukasten, aber der Preis ist dann hoch, denn ich halte €50 für den Brick schon für hoch, da ja wie gesagt noch Ausgaben dazu kommen. Wir sind also schon bei über €100 in der Summe.

[FabianB]

Also für dich wären die Kriterien

• leistungsstärker als der Masterbrick
  
• kleiner als der Raspberry Pi
  

maßgeblich? Was genau sollte der Baustein denn leisten können? Sollte da Java drauf laufen können?

[benatweb]

Bei elektor gibts ein Embedded-Linux-Board, das liegt von der Hardware schätze ich nicht allzu weit weg von einem (potentiellen) Linux-Brick. Kostet da 65€, nur natürlich überhaupt nicht im richtigen Formfaktor (der wär dann Pflicht, ansonsten gibts ja keinen Grund, keinen Raspberry zu nehmen). Schätze um die 100€, wenn nicht mehr dürfte so realistisch sein.

 

Ansonsten schließ ich mich den genannten Kriterien an, beim Raspberry bleibt es ja nicht, die Kabel drumherum brauchen ja auch noch jede Menge Platz, gerade weil sie in alle Richtungen abgehen.

[ArcaneDraconum]

Kleiner als der Pi.... Klar, da ich ja auf das 40 x 40 mm Raster der Bricks gehen würde. Und mehr Leistung sollte auch drin stecken.

Und nun sind wir wieder beim Stromverbrauch angekommen.

 

Auf die Programmiersprache würde ich mich jetzt nicht festlegen wollen. Aber tendenziell würde ich bei der Wahl von der On Device Programmierung bleiben. Und funktionell darauf aufbauen. Man will ja nicht von Grundauf neu programmieren, wenn man auf den Superbrick aufsteigt.

[Bralph]

Für mich wäre ein erweiterter Masterbrick als Datenlogger interessant. Zum einem um festzustellen was vor einem Absturz schief gelaufen ist, aber vor allem als Messdatenerfasser (am besten mit nicht flüchtigen, austauschbaren Speicher). Den Pi finde ich dafür überqualifiziert.

[Equinox]

Ich denke, die Anforderungen daran (wie ich sie mir vorstelle) habe ich schon genannt. Hier trotzdem nochmals die Zusammenfassung:

• Größe wie der aktuelle Master-Brick
  
• Mehr RAM
  
• SD-Card Slot
  
• RAM erweiterbar durch Aufstecken von "RAM"-Bricks
  
• Flash-Speicher getrennt von RAM
  
• "Mini"-Betriebssystem, sodass auch vollständige Java VM drauf laufen
  

Programme sollten über die SD-Card in den RAM geladen werden und dort ausgeführt werden können. Programme sollten also nicht(!) geflasht werden müssen, sondern einfach über die SD-Card geladen werden können.

Schön wäre auch, wenn man den RAM als "Shared-Memory" nutzen könnte, d.h. dass verschiedene Clients z.B. Werte von Variablen ablegen und auslesen können (String würden reichen).

Außerdem wäre es auch gut, wenn ein automatisches "Logging" von Events auf die SD-Card stattfinden würde. Evtl. auch noch eine Logging-API dazu, um nicht-automatisches Logging zu unterstützen.

Optional halte ich WLAN/Ethernet auf dem Brick.

Unnötig halte ich Sound- und Videoausgang.

[borg]

"Mini"-Betriebssystem, sodass auch vollständige Java VM drauf laufen

 

Unter einem Mini-Betriebssystem verstehen wir hier Windows/Mac OS/Linux/Solaris/Unix, richtig?

 

Wenn nicht, was meinst du damit und was ist eine vollständige Java VM? Ich glaube nämlich nicht das es eine vollständige Java VM gibt (inklusive Standardbibliothek) die außerhalb dieser Betriebssysteme läuft.

 

Warum ist steckbarer RAM wichtig?

[Equinox]

Mit "Mini"-Betriebssystem meine ich irgendein Minimal-Betriebssystem das man braucht, um die Anforderungen realiseren zu können. Mir ist völlig egal, ob das Linux/Windows/Android/Firefox OS oder sonst was ist, da ich hoffe, damit möglichst wenig in Berührung zu kommen. Es kann auch was Selsbtgestricktes sein, wenn das einfacher ist.

 

OK, vollständige VM ist übertrieben. Sämtliche GUI- und Sound-API braucht es nicht. Aber Dinge zur Interprozesskommunikation, Aufruf und zur Verfügung Stellung von Web-Services sollte schon gehen. Schön wäre auch, wenn SQL auf einer Derby-DB funktionieren würde (wenn das nicht geht, kann auch damit leben).

 

Steckbarer RAM: TF ist ja auf Modularität und Erweiterbarkeit ausgelegt. Wenn also der RAM nicht reicht, sollte man ihn ausbauen können. Wenn das "Grundmodell" natürlich schon z.B. 512 MB hat, dann hat der Wunsch keine Priorität.

[FabianB]

@Equinox:

Wäre WLan/Ethernet nicht überflüssig durch die entsprechenden Master-Extensions?

Zum RAM: Klar braucht man was mehr, wenn da ein OS drauf soll. Aber da nach dem allgemeinen Tenor gar nicht die Leistungsfähigkeit vom Raspberry erreicht werden muss, könnte doch auch eine sehr kleine Linux-Distribution reichen, die nicht viel Ballast um den Kernel mitbringt. (Mit Linux from Scratch könnte man sich auch was passendes kleines selber zusammenbauen)

 

Solch eine kleine Distribution braucht ja auch nicht so viel RAM. Damn Small Linux kommt mit 16 MB aus. Wenn man jetzt z.B. 64 MB oder 128 MB hätte, würde das nicht locker reichen? Welche Anwendung mit TF-Bausteinen könnte so viel RAM verbrauchen? Auf der anderen Seite ist RAM auch nicht mehr so teuer, dass man damit geizen müsste.

Unterm Strich jedenfalls halte ich erweiterbaren RAM für überflüssig. 1) Macht es die Hardware komplizierter und damit teuerer, 2) wofür.

 

 

Zum SD-Card Slot: Da wäre ich dafür, das eher bei dem schonmal angedachten Baustein für die SD-KArte zu lassen. Dann ists modularer usw.

[AuronX]

Davon abgesehen, dass ich ein RAM-Brick für technisch nicht möglich halte, bitte ich auch folgendes zu bedenken:

Jede Anforderung schlägt sich am Ende im Preis nieder.

 

Wenn sich jetzt herausstellt, dass das Ganze am Ende teurer wird als ein Raspberry Pi, aber aufgrund der Größe noch immer nicht so viel kann, dann werden sich einige sicherlich überlegen, ob es überhaupt Sinn macht dieses Super-Brick zu kaufen.

RAM ist m.E. nur in den typischen Größen nicht teuer, aber ich würde glatt behaupten, dass von den (massenhaft und billig) auf DIMMs und grafikkarten verbauten Chips schon ein einzelner kaum auf ein Brick passen würde.

[FabianB]

Um das von gerade nochmal zusammenzufassen:

Netzwerk, und SD-Karte wären nach den ursprünglichen Planungen schon ausgelagert und modular. Sound und Videoausgang war nach bisherigen Posts nicht notwendig. Insgesamt recht gut, weil das alles Platz, Kosten und Energie spart.

 

Hat den Vorteil, dass man den Super-Master ohne die Zusatzfunktionen nutzen kann, wenn man die nicht braucht, und umgekehrt diese Zusatzfeatures aber auch ohne den Super-Master.

Auf den müsste nur noch RAM, Prozessor und so.

 

Fasst man das alles zusammen, dann sieht das für mich aus wie ein Master-Brick nach bisherigem Vorbild, nur leistungsstärker.

 

 

Seht ihr das auch so oder habe ich was wesentliches vergessen? Einen dickeren Master zu bauen wäre schon wieder deutlich überschaubarer, als einen PI zu minimieren.

[Equinox]

Wäre WLan/Ethernet nicht überflüssig durch die entsprechenden Master-Extensions?

Deshalb habe ich ja auch "optional" gesagt. Ich würde es aber schön finden, wenn drauf wäre, damit die Stapel kleiner bleiben.

... könnte doch auch eine sehr kleine Linux-Distribution reichen, die nicht viel Ballast um den Kernel mitbringt. (Mit Linux from Scratch könnte man sich auch was passendes kleines selber zusammenbauen)

Genau mein Reden.

 

Zum RAM: Erweiterbarkeit ist eine schicke Sache (wie On Device Programming auch. Damit wäre das "Wozu" geklärt  )

 

Ein SD-Card-Slot auf dem Brick halte ich aber schon für sinnvoll und notwendig und zwar wegen:

• Wie sollen sonst die Programme in den RAM geladen werden? Ich möchte keinesfalls flashen.
  
• Eröffnet es die Möglichkeit, wie beim Raspi von dort das Betriebssystem zu booten. Damit könnte man dann auch verschiedene Betriebssysteme unterstützen. Man wäre nicht mehr auf die Firmware angewiesen (die dann in der Form sogar überflüssig würde)