Jump to content

Recommended Posts

Geschrieben

Das mit der SD-Karte kann ich noch nachvollziehen, das mit dem RAM nicht. Ich brauche auch keinen Porsche als Stadtauto, nur weil das eine schicke Sache ist. Ich denke, dass das wenn überhaupt nur schwer machbar wäre, zu aufwendig und teuer, und überhaupt keinen Nutzen hätte als "wenn ich wollte könnte ich". Genau wie der Porsche.

 

 

Und zu Netzwerk auf dem Super-Master, damit der Stack kleiner bleibt: Das wird echt schwer auf 4x4 unterzubringen. Halte ich für nicht machbar. Und wenn wir aus 4x4 ausbrechen, gibt es schon wieder kaum ein Argument für einen Super-Master, weil der definitiv teurer als ein Pi Modell A ist und die gleiche Funktionalität liefert.

In meinen Augen ist 4x4 also notwendige Bedingung für die Sinnhaftigkeit. Was bekommt man auf 4x4 unter? Eigentlich nur einen stärkeren Master, evtl noch die SD-Karte. Rest muss modular bleiben.

  • Replies 73
  • Created
  • Letzte Antwort

Top Posters In This Topic

Top Posters In This Topic

Geschrieben

Nochmal zur SD-Card: Es wäre dann auch einfacher, komplette Pakete für bestimmte Anwendungen zu verkaufen.

Ein einfaches Beispiel wäre die Wetterstation. Man könnte die erforderliche Hardware sowie die fertig konfigurierte Software auf SD-Card anbieten. Der Endanwender muss dann nur noch die Bricks und Bricklets zusammenstecken, die SD-Card reinschieben und fertig. Damit würden dann auch weniger "Technik-Affine" Leute zu möglichen Kunden, da nichts mehr programmiert werden muss. Das kann man dann natürlich für alle möglichen Anwendungen anbieten (wenn man die Hardware schon hat, würde ein Download eines Images schon reichen).

 

Ich brauche auch keinen Porsche als Stadtauto, nur weil das eine schicke Sache ist.

 

Hmm, dass das gerade von Dir kommt, wundert mich jetzt schon ???

Geschrieben
Ein fertiges Programm, was man mit dem Brick-Viewer nur drauf flasht, tut das Gleiche. Ist auch nicht schwerer.

 

Da liegen in meinen Augen Welten dazwischen. Das fängt schon damit an, dass man für den Brick-Viewer einen Rechner braucht. Mit einer fertigen SD-Card könnten dann auch Leute TF nutzen, die keinen PC haben, sondern z.B. nur ein iPad.

Außerdem: Das Flashen kann schiefgehen. Wenn eine SD-Card falsch beschrieben wird, ist das weit weniger dramatisch.

 

Zum RAM: Wie gesagt, wenn auf dem Grundbaustein schon genügend RAM vorhanden ist, dann hat die Erweiterbarkeit keine Priorität. Trotzdem würde das die Flexibiltät erhöhen und die Module auch für zukünftige Anforderungen rüsten. Mit einem Porsche kann eben in der Stadt und auf der Autobahn Spaß haben.

Geschrieben

Der Porsche ist auch unverhältnismäßig teuer.

 

 

Zum Flashen: Die TF-Bricks sind durch das Flashen, zumindest wenn ein Post von Borg oder Batti letztens stimmt, unkaputtbar.  AUch in der Doku steht, dass der Bootloader unangetastet bleibt. Alles andere kannst du eh löschen, der Bootloader übernimmt die notwendigen minimalen Aufgaben.

Die Anzahl der TF-Benutzer, die nur ein Ipad und sonst keinen Rechner zum Flashen zur Verfügung haben, halte ich für vernachlässigbar.

Geschrieben
Die Anzahl der TF-Benutzer, die nur ein Ipad und sonst keinen Rechner zum Flashen zur Verfügung haben, halte ich für vernachlässigbar.

 

Im Moment stimme ich dir da zu, aber es geht ja auch darum, weitere Kunden zu gewinnen. Im Moment ist TF sehr auf Techies mit Programmierkenntnissen ausgelegt. Es gibt aber viele, die einen PC haben, aber nicht mehr können als ein Programm starten (ich würde sogar behaupten, dass das die Mehrheit ist). Aber auch diese können Interesse an z.B. einer "flexiblen" Wetterstation oder Raumklimaüberwachung haben. Mit fertigen Lösungen kann man die auf jeden Fall leichter gewinnen. Flashen ist da ein absolutes "No Go".

Aber selbst bei Leuten mit guten PC-Kenntnissen aber ohne Programmierkenntnisse funktioniert TF im Moment nicht. Ich habe z.B. einen Freund, der sich sehr gut mit PCs auskennt und sogar Programmierkenntnisse hat. Als ich ihm von TF vorgeschwärmt habe, war seine erste Frage, ob man sich die Programme fertig runterladen kann. Für ihn ist TF im Moment keine Option. Ich denke, Flashen wäre für ihn jetzt kein Problem, aber begeistert wäre er sicher nicht.

Wenn es absolut nicht anders geht, dann soll es eben Flashen sein. Aber nur, wenn absolut 1000%ig sichergestellt ist, dass die Firmware dadurch nicht beschädigt werden kann. Ansonsten ist es ein KO-Kriterium.

Aber wozu soll ich ein Programm flashen, wenn ich es einfacher über die SD-Card laden kann? Beim Flashen muss ich immer meinen Brick "abbauen", an meinen PC anschließen, Flashen und wieder aufbauen. Das ist teilweise nicht nur lästig, sondern auch aufwändig. Bei einer SD-Card ist das im ein Vielfaches einfacher. Von daher halte ich Flashen nur für eine Option, wenn es absolut nicht anders geht. Dass es anders geht, zeigt ja Raspi.

Geschrieben

Die Anzahl der Nutzer die keinen PC haben, nicht programmieren wollen ABER TF nutzen halte ich für vernachlässigbar.

 

Was ist das für eine Zielgruppe? Nichts programmieren oder selbst anpassen aber ne Basterlösung wählen? Gibt es das? Glaube so jemand würde sich einfach ne fertige Wetterstation kaufen. Eine die villt sogar wasserdicht ist.

 

P.S.: Das beschreiben einer SD-Karte, so dass sie danach bootbar ist ist übrigens auch gar nicht soo trivial... da kann man merh falsch amchen als beim flashen

Geschrieben

Das waren ja auch nur 2 Beispiele. Es gibt da ja viele Anwendungen und ganz offensichtlich schreckt die momentane Anwendbarkeit selbst Bastler ab.

Das Beschreiben der SD-Card halte ich aus den schon genannten Gründen trotzdem für sehr viel besser als Flashen. Und wie gesagt: Man kann die SD-Cards dann ja auch fertig anbieten, dann ist dieses Problem weg. Für alle anderen bietet es eben mehr Komfort und ist einfacher.

Geschrieben
Es gibt da ja viele Anwendungen und ganz offensichtlich schreckt die momentane Anwendbarkeit selbst Bastler ab.
Das kann ich jetzt mal so gar nicht nachvollziehen. Worauf basiert denn diese These. Ich denke eher, das genaue Gegenteil ist der Fall.
Geschrieben

Ich Kommentiere das Gezanke einfach mal nicht ;D.

 

Also ich ziehe folgenden Schluss aus den Anforderungen die ich bisher gesehen habe: Es handelt sich bei dem gewünschten "Super-Master Brick" in der Tat um ein Linux Brick.

 

@Equinox: Das bedeutet unter anderem automatisch, dass wir ein Image über die SD Karte einspielen, wie bei allen kleinen Linux Boards üblich.

 

Jetzt ist unser Linux Brick aber natürlich kein gewöhnliches Linux Board, wir wollen ja Sensoren auslesen, regeln und steuern. D.h. wir brauchen kein HDMI, Sound und diesen ganzen Schnickschnack (würde eh nicht auf 4x4cm passen).

 

Bleibt eigentlich nur noch die Frage nach der Leistung. Das Linux Board von der Elektor läuft mit 180MHz, ist also eine echte Krücke :)! Das wäre das absolute Minimum was man überhaupt noch mit Linux betreiben könnte. Damit würde sich z.B. mit hoher Wahrscheinlichkeit kein Quadcopter steuern lassen.

 

Direkt per On Device mit C auf den Bricks ginge das aber sehr wahrscheinlich schon. Ist natürlich dann eine lustige Situation.

 

Wenn wir jetzt mit der Leistung hoch gehen, in Richtung RPI oder darüber, dann gehen wir mit dem Verkaufspreis allerdings leider auch schnell weit über die 100€ hinaus.

 

Die Frage die ich mich stelle: Gibt es da irgendwo ein passendes Maß an Leistung wo das Preis-/Leistungsverhältnis Sinn macht? Und macht das auch in 1,5 Jahren noch Sinn?

Geschrieben

Das war schon genug Kommentar  ;D Schön, dass wir mal wieder beim Kern des Topics sind.

Deine Schlussfolgerung teile ich, die Frage am Ende beantworte ich für mich persönlich mit "Nein, das macht nicht wirklich Sinn".

Damit ziehe ich mich mal vorerst aus der Diskussion zurück. Das "Gezanke" vernebelt den anderen die Sicht auf die Dinge  :-X

Geschrieben

Also ich bin nach wie vor der Meinung: Ein Master wie jetzt mit deutlich mehr Leistung und Speicher, damit man ordentlich Programme unterbringen kann.

Wie es Borg schon sagt, dass was hier alles diskutiert wird deckt der RasPi ab. Und zu diesem Preis wird es nicht gehen. Ich denke der Superbrick kostet schon mehr. Dazu die Step Down und eine Extension, dafür bekommt man schon kleine Boards die deutlich mehr können. Im Endeffekt sind wir hier im Embedded Bereich - da muß kein Serverbetriebssystem drauf laufen müssen. Das fehlt irgendwie als letztes nocht auf der Wunschliste: Das Webinterface.

Das halte ich weder für sinnvoll, noch für bezahlbar.

Geschrieben
Bleibt eigentlich nur noch die Frage nach der Leistung.

 

Bei 180MHz würde er also immer am Anschlag laufen, das ist dann natürlich nicht sinnvoll. Der Raspi hat meines Wissens 700MHz. Da der Super-Master vmtl. weniger tun/können muss als ein Raspi, kann er meiner Meinung nach darunter liegen. Ich sag jetzt einfach mal, dass 500MHz OK wären.

Das fehlt irgendwie als letztes nocht auf der Wunschliste: Das Webinterface.

 

Das finde ich eine super Idee!

Geschrieben

Der RasPi erlaubt inzwischen auch das Übertakten..... da geht noch mehr.

 

Also ich bin der Meinung, wer einen Datenlogger braucht, oder gerade eine Webgeschichte, sollte eher zu einem "externen" Gerät wie den RasPi, SheevaPlug etc. greifen.

Ich würde hinter einer autarken Lösung etwas vermuten, dass man möglichst klein einbauen möchte, es soll aber selbstständig arbeiten. Da wäre ein Firmwarupdate via WLAN / Ethernet etc. eine feine Sache. Jedenfalls nicht so wie bisher, dass man ein USB-Kabel anstecken muss und zwei Knöpchen drücken. Das bedeutet in der Regel: Ausbauen, Updaten, Einbauen. Das macht man nicht so gerne und - zumindest meine - Eigenkonstruktionen fangen dann irgendwann an an den Verschraubungen auszuleiern und zu wackeln.

Geschrieben
Da wäre ein Firmwarupdate via WLAN / Ethernet etc. eine feine Sache.

 

Genau meine Meinung! Ich würde nur "Firmware" durch "Software" ersetzen (falls es mal ein BS auf SD-Card gibt). Ich finde den momentanen Prozess für die Firmware-Updates auch "suboptimal".

Geschrieben

Ich glaube, dass ein Linux-Board technisch (bezogen auf Größe und Kosten) nicht machbar ist. Dazu kommt, wenn ich eins brauche, verwende ich ganz klar den raspi.

 

Was allerdings cool wäre ist ein Arduino-ähnliches Mikrokontroller-Board. Sprich ein Masterbrick mit mehr Prozessorleistung und mehr RAM. Die C-Bindings (ohne IPConnection) sollten am Board bereit liegen (flashbar). Über eine IDE meiner Wahl soll der geschriebene Code ebenfalls auf den Super-Master geflashed werden können.

Geschrieben
Über eine IDE meiner Wahl soll der geschriebene Code ebenfalls auf den Super-Master geflashed werden können.

 

Das könnte man lesen als: "Es sollte ein Commandline-Tool geben, um das flashen durchzuführen". Das würde ich sofort unterschreiben, es sollte auch ohne Brickv gehen. Allerdings komme ich damit glaube ich auch auf ein neues Thema. Ich eröffne mal einen zweiten Thread.

Geschrieben
Was allerdings cool wäre ist ein Arduino-ähnliches Mikrokontroller-Board.

 

Halte ich grundsäzlich für nicht schlecht, aber wäre das nicht eher eine Master-Extension, d.h. ein eigener Brick (oder vielleicht Bricklet), das auf den (Super-) Master aufgesteckt bzw. angeschlossen wird?

Geschrieben

Was allerdings cool wäre ist ein Arduino-ähnliches Mikrokontroller-Board. Sprich ein Masterbrick mit mehr Prozessorleistung und mehr RAM. Die C-Bindings (ohne IPConnection) sollten am Board bereit liegen (flashbar). Über eine IDE meiner Wahl soll der geschriebene Code ebenfalls auf den Super-Master geflashed werden können.

 

Also wir sollen einen Arduino Due Klon machen?

 

Ich glaube das passt nicht so in unser Konzept. Es geht ja bei uns gerade dadrum nicht löten zu müssen.

Geschrieben

Nein kein Klon, sondern einen Brick der meinen Code ausführt. Also so wie jetzt, nur leistungsstärker. Natürlich sollen dann auch die "Bindings" vorhanden sein mit denen ich alle anderen angschlossenen Brick/lets ansprechen kann.

Geschrieben

Ah, dann hab ich das falsch verstanden.

 

Ich denke mit 64MHz sam3s den wir auf dem Master verwenden schon an der oberen Leistungsgrenze von Microcontrollern. Bist du sicher, dass du mehr Leistung brauchst?

Geschrieben

@TF: Ich will nur einen Brick auf welchen ich ein Programm ablegen kann (Maschinencode) welche dann innen eine Schleife abarbeitet.

// Daten init.
:loop
// Programm
goto loop;
:exit
// Brickprogramm endet

Ich brauche kein OS oder sonst was, "einfach" ins Programm starten, genügt mir.

Was ich brauchen kann ist ein SD Karten Slot (Textdaten schreiben) etwas Ram und ein paar Register\ min 2 Zählregister und Interrupts\Callbacks zum freien definieren. Und dann eine C Api welche mir das Bytes schupsen in Assembler abnimmt. Dies sollte auf einen Brick passen oder?

 

Anwendungsbereich:

- Logger für Wetterdaten

- Steuerung für CNC-Fräsen usw

 

Für alles mehr an Anforderungen habe ich einen RaspPI dort kann ich in Java so viel an Ram belegen wie es sonst kein Brick je können wird und dass mit FTP und HTTP wie ich will... und falls der PI nicht ausrecht dann klemme ich meine Bicks wieder am Laptop\PC an!

Geschrieben

Ok, der duo hat mit 84MHz nur etwas mehr. Das reicht natürlich. Es wäre jedoch schön wenn der gesamte Paket-Transfer am Super-Master versteckt bleibt, und man so wie bei den Bindings mit Setter, Getter und Callbacks arbeiten kann. Dann wären wir wohl wieder beim on-device Thema...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.


×
×
  • Neu erstellen...