Wie könnte ein Super-Master Brick aussehen?

Ein extra Flash-Speicher-Brick ist nicht vorgesehen und wird es auch definitiv nicht geben (alleine aus technischen Gründen). Was wir mit hoher Wahrscheinlichkeit machen werden ist eine "SD Card Extension", mit der man auf SD Karten loggen kann. Das ist sobald wir ein On Device Programming Interface haben offensichtlich sinnvoll.

Was ist der Grund, warum es ein Speicher-Brick nicht geben wird? Es muss auch nicht ein Flash-Speicher sein. Es würde reichen, wenn man Programme von der SD-Card liest und dann in den Speicher einliest. Zusätzlich könnte man dann dort noch Variablen usw. ablegen, auch als eine Art "Shared-Memory", auf das man von allen Clients aus zugreifen kann. Ich halte das für wesentlich sinnvoller als nur ein "SD-Card Brick". Dies würde vieles ermöglichen bzw. vereinfachen.

Bei nur 100KB stellt sich mir sowieso die Frage, ob sich da On Device Programming lohnt. Ich vermute, dass damit dann nichts "großes/komplexes" realisierbar ist. Gibt es Abschätzungen, wie groß z.B. ein Python- oder C-Programm (in Lines of Code) maximal sein darf? Im Moment habe ich das Gefühl, dass On Device Programming nur mit größerem (Haupt-)Speicher Sinn macht.

Ich würde die "Ob"-Frage gar nicht mehr stellen, dafür ist die Nachfrage dafür viel zu groß. Und machbar ist es ja auch, halt eingeschränkt in mancher Hinsicht (Java nicht so gut etc.), aber ausreichend für die meisten Anwendungen.

Mehr Sinn würde es vermutlich machen ein Gehäuse anzubieten in dem man ein Raspberry PI und Bricks befestigen kann. Dazu dann vielleicht noch Kabel um das Raspberry PI über die Step-Down Power Supply zu versorgen und mit einem Brick-Stapel zu verbinden. Könnte dann eins von den neuen Kits sein die wir planen: "Starter Kit: Raspberry PI" .

Hehe, das wollt ich auch schon bauen Sogar recht einfach in der Umsetzung, es gibt ja den Pibow, da müsste man bloß eine Austausch-Bodenplatte basteln, die seitlich unter dem Pi rausragt und dort Platz für einen Stack bietet.

Zum SD-Karten-Logger: Sehr schön, den hätte ich mir auch als nächstes gewünscht.

Was ist der Grund, warum es ein Speicher-Brick nicht geben wird? Es muss auch nicht ein Flash-Speicher sein.

Die Pinne die man braucht um Flash-Speicher anzuschließen liegen nicht auf dem Brick Stecker und sie sind auch einfach nicht über.

Es würde reichen, wenn man Programme von der SD-Card liest und dann in den Speicher einliest.

Was soll das denn bringen? Dann kann ich ihn  ja auch direkt in den Flash laden.

Zusätzlich könnte man dann dort noch Variablen usw. ablegen, auch als eine Art "Shared-Memory", auf das man von allen Clients aus zugreifen kann.

Eine SD Karte ist nicht geeignet um dort Variablen abzulegen , da reden wir dann von Nachrichten pro Minute anstatt Nachrichten pro ms.

Bei nur 100KB stellt sich mir sowieso die Frage, ob sich da On Device Programming lohnt. Ich vermute, dass damit dann nichts "großes/komplexes" realisierbar ist. Gibt es Abschätzungen, wie groß z.B. ein Python- oder C-Programm (in Lines of Code) maximal sein darf? Im Moment habe ich das Gefühl, dass On Device Programming nur mit größerem (Haupt-)Speicher Sinn macht.

100KB ist mehr als genug um zum Mond und wieder zurück zu fliegen.

Wieviele Zeilen C Code das sind kommt natürlich darauf an was in dem Code steht. Wenn ich den Code der im Moment auf dem Master Brick läuft diesbezüglich skaliere sind es 25000 Zeilen.

Eine SD Karte ist nicht geeignet um dort Variablen abzulegen , da reden wir dann von Nachrichten pro Minute anstatt Nachrichten pro ms.

Da haben wir uns wohl missverstanden. Die Variablen sollten natürlich nicht auf der SD-Card liegen. Unter "Speicher"-Brick verstehe ich ein RAM, Main Memory, Hauptspeicher. Damit dürfte dann auch klar sein, warum ich da kein Flash will bzw. brauche.

Also: Die Programme liegen auf der SD-Card und werden dann in den "RAM-Speicher" Brick geladen (kann natürlich auch alles auf einem Brick integriert sein, was ich auch bevorzugen würde). Ausgeführt werden die Programme im RAM, ebenso können dort Variablen etc. abgelegt werden. Dieser RAM ist völlig unabhängig vom Speicher in dem die Firmware liegt.

Ehrlich gesagt halte ich das auch für besser, da ich mit meinem Programm nicht mit der Firmware ins Gehege kommen will (weder organisatorisch noch technisch auf dem Brick).

Also im Prinzip wie auf einem Raspberry PI. Das Ding lädt die Programme auch von einer SD-Card in den RAM und führt sie von dort aus. Ich hoffe, das wurde jetzt klar, wie ich das meine.

100KB ist mehr als genug um zum Mond und wieder zurück zu fliegen.

Die Programme waren aber auch weder in C noch in Python geschrieben

Wieviele Zeilen C Code das sind kommt natürlich darauf an was in dem Code steht. Wenn ich den Code der im Moment auf dem Master Brick läuft diesbezüglich skaliere sind es 25000 Zeilen.

Wie sieht es im Vergleich dazu mit Python aus?

Also wenn ich das richtig sehe, sind wir vom autarken Lauf des MasterBricks schon wieder bei einem neuen Modul. Da auch schon weiter unten die Kosten/Nutzen Frage gestellt wurde, möchte ich fragen, was gegen den erwähnten RasPi spricht?

Der ist nicht so viel größer, kurze Kabel gibt es, er kann relativ einfach mitversorgt werden und bietet alles, was hier gefordert wird, vom SD-Kartenleser angefangen, bis hin zur nahezu freien Auswahl an Programmiersprachen. Er ist sogar einfach an einen Monitor anzuschliessen und ne Tastatur hat man auch gleich dran. Und vor allem dürfte er preislich in der gleichen Liga, wie eine Speicher Brick Extension liegen. Nur er kann nicht direkt aufgesteckt werden..... optisch nicht ganz so schön anzuschauen, das gebe ich zu.

 

Da haben wir uns wohl missverstanden. Die Variablen sollten natürlich nicht auf der SD-Card liegen. Unter "Speicher"-Brick verstehe ich ein RAM, Main Memory, Hauptspeicher. Damit dürfte dann auch klar sein, warum ich da kein Flash will bzw. brauche.

Also: Die Programme liegen auf der SD-Card und werden dann in den "RAM-Speicher" Brick geladen (kann natürlich auch alles auf einem Brick integriert sein, was ich auch bevorzugen würde). Ausgeführt werden die Programme im RAM, ebenso können dort Variablen etc. abgelegt werden. Dieser RAM ist völlig unabhängig vom Speicher in dem die Firmware liegt.

Wir haben uns schon richtig verstanden. RAM haben wir vielleicht 16KB über. Sprich alles was du in den RAM laden willst kannst du auch vorher in den Flash schieben anstatt auf externe Hardware .

Wenn du meinst wir sollen zusätzlichen externen RAM anschließen: Das geht technisch nicht.

Wie schon gesagt, zusätzliche externe Hardware für On Device Programming macht keinen Sinn. Wenn soviel Speicher benötigt wird kann man das Raspberry PI benutzen.

Bisher wurde hier aber auch noch kein Projekt genannt was nicht auf den Master Brick passen würde .

Ich denke auch, dass wir wegen der eh schon nicht ganz einfachen Entscheidungsfindung in diesem Thread beim Thema OnDevice (ohhe Zusatzhardware) bleiben sollten. Der Rest wurde ja schon ausreichend diskutiert. Wenn wir wieder bei den Grundfragen anfangen, kommen wir nicht weiter.

@Borg: Es ist Mittag, jetzt seid ihr wieder für Python? 

Bisher wurde hier aber auch noch kein Projekt genannt was nicht auf den Master Brick passen würde

Das stimmt nur bedingt. Wenn Du hart am Metall coden kannst, dann ja. Dann brauchst Du nur kleine oder keine Libraries. Sobald Du aber mit einer 'komfortablen' umgebung arbeiten willst, brauchst du libraries (=platz) oder interpreter (viel platz) und der code wird viel länger. 100 KB ist viel, wenn du mit einem 6502 prozessor arbeitest (mehr, als der addressieren kannst), absolut nichts wenn du mit modernen entwicklungsumbegungen arbeitest. Was natürlich der Ausgangspunkt dieser diskussion ist

So wie ich das jetzt verstanden habe, bin ich immer mehr auf den Paspberry Pi neugierig geworden. Braucht es für die Integration irgend was bestimmtes, oder wird der einfach mit usb an den master angeschlossen, der Pi mit strom versorg und alles in einen schuhkarton geworfen?

-ch

Braucht es für die Integration irgend was bestimmtes, oder wird der einfach mit usb an den master angeschlossen, der Pi mit strom versorg und alles in einen schuhkarton geworfen?

Jap. Den verwendest du wie einen gewöhnlichen PC. Also einfach den TF-Stack per USB anschließen. Dann muss du nur noch die Stromversorgung für beides bereitstellen. Je nachdem, wie du das lösen willst, reicht da eine Quelle oder du versorgst die getrennt. Was nicht wirklich geht ist, dass du nur den Pi mit Strom versorgst und versuchst, den TF-Stack nur über USB zu versorgen. Dafür liefert der Pi zu wenig Strom. Vor allem bei größeren Stacks, wenn du LCDs verwendest oder so, reicht das nicht

Bisher wurde hier aber auch noch kein Projekt genannt was nicht auf den Master Brick passen würde .

Naja, so würde ich das nicht sehen. Für Java sind die 100KB ja wohl zu klein und wenn man dann auch noch das komplette Java haben will sowieso.

Mich würde aber auch interessieren, bei was ich mit On Device Programming Vorteile habe gegenüber einer Lösung mit z.B. dem Raspi. Klar ist es schicker, wenn man keinen zusätzlichen Rechner braucht, aber im Moment stellt es sich für mich so dar, dass ich damit dann mit einigen Einschränkungen leben muss. Also: Was konkret kann man damit machen (mit den momentanen Einschränkungen), das Riesenvorteile gegenüber den momentanen Möglichkeiten hat?

Wenn du meinst wir sollen zusätzlichen externen RAM anschließen: Das geht technisch nicht.

Keine Speicherwereiterung möglich? Das finde ich jetzt schwach 

Als ich das auf meine Wunschliste gesetzt habe, hieß es, dass es möglich sei.

Ich würde eher fragen, was man damit nicht machen kann (wenn man es genau nimmt). Wenn du eine hochgezüchtete, komfortable Umgebung haben möchtest, dann ist es das "WIE MACHEN", was dich einschränkt...

Aber um zu was Konkretem zu kommen:

Du kannst als sinnvolle OnDevice Lösung z.B. Raumklimaüberwachung realisieren: Du misst Temperatur, Luftfeuchtigkeit und gibst es auf einem LCD-Bricklet aus. Als Zusatzfeature schaltest du bei Unterschreiten eines bestimmten Grenzwertes eine Heizung ein.

Für ein solches Szenario ist es sehr schön, wenn du auf einen PC verzichten kannst (auch auf einen Raspberry Pi). Einfach, weil der unnötig Platz und Strom wegnimmt und außerdem auch Anschaffungskosten hat. Wenn du diese Funktionalität ausschließlich mit dem TF-Bausteinen realisieren kannst, die dann nur noch Strom bekommen brauchen, dann vereinfacht das vieles.

Zur Speichererweiterung: Ich kenne zwar die Wunschliste nicht genau, aber ich vermute, dass mit dem "Möglichen" so etwas wie der SD-Karten Leser gemeint war? Dass das nicht geht, finde ich auch nicht gerade "schwach"... Das liegt am Designprinzip der TF-Bausteine, und das ist nunmal nicht mit Fokus auf sowas entworfen worden. Aber warum auch? Braucht man ja offensichtlich nicht.

Man bräuchte es höchstens, um Java OnDevice verwenden zu können. Aber das ist gar nicht die Hauptintention von TF.

Zur Frage wofür On Device Programming sinnvoll ist:

* autonome Wetterstation

* autonome Robotersteuerung

* So simple Sachen wie: Servo hochklappen wenn Spannung über einen Schwellwert geht etc

* "Notfallbehandlung" wenn die USB/WIFI Verbindung weg ist

* CNC Fräsen ansteuern (PC schickt sowas wie "Vektoren" die man auf dem Brick zwischenspeichert und in Echtzeit abarbeitet)

Da gibt es schon viele Anwendungszwecke. Das meiste kann man natürlich auch über einen PC machen, klar. Dieser PC kann auch ein Raspberry PI sein . Unsere Argumentation wenn jemand On Device haben wollte war ja bisher ja auch immer "nimm doch das Raspberry PI/BeagleBoard".

Nichtsdestotrotz kann ich auch den zusätzlichen Wunsch nach einem On Device Programming Interface nachvollziehen.

Du kannst als sinnvolle OnDevice Lösung z.B. Raumklimaüberwachung realisieren:

Dieses Beispiel überzeugt mich nicht, da ich sowas im Moment mit einem Raspi mache. OnDevice hat hierbei meiner Meinung nach keine Vorteile, außer eben dass es schicker ist.

Mir fällt nur ein Beispiel ein, wo es Vorteile bringt, und zwar bei der Steuerung (autonomer) Flugdrohnen. Hierbei muss in aller Regel auf das Gewicht und schnelle Kommunikationswege geachtet werden. Aber sonst?

Zur Speichererweiterung: Ich kenne zwar die Wunschliste nicht genau, aber ich vermute, dass mit dem "Möglichen" so etwas wie der SD-Karten Leser gemeint war?

Sagen wir mal so: Vielleicht haben die mich da ja missverstanden. Gemeint habe ich auf jeden Fall nicht den SD-Karten Leser.

Warum so ein RAM-Brick aber nicht machbar ist (aber ein SD-Card Brick schon) verstehe ich trotzdem nicht ...

Weil RAM viiiiiiiel schneller reagiern muss und breiter angebunden wird.

@Wozu: Stromverbrauch

Von den Beispielen überzeugt mich nur dieses:

* "Notfallbehandlung" wenn die USB/WIFI Verbindung weg ist

Alles andere geht mit dem Raspi auch, evtl. sogar besser.

Nur: Wer hat schon oder möchte mit TF eine Anwendung bauen, die so eine Notfallbehandlung braucht? Anders gefragt: Lohnt sich der Aufwand mit den momentanen Einschränkungen? Nicht falsch verstehen, ich finde OnDevice klasse, aber ich denke, dass es mit den Einschränkungen sich nicht lohnt, viel Aufwand reinzustecken bzw. es sinnvollere Dinge gibt, die gemacht werden sollten.

Es geht nicht darum, das Machbare zu erweitern. Es geht darum, die Arten, etwas Machbares zu machen, zu erweitern.

Der Wunsch nach OnDevice in der Art, wie wir das hier diskutieren, kommt schon lange. Es gehört mit zu den am meisten nachgefragten Features bei TF. Dementsprechend lohnt sich der Aufwand, auch in Relation mit den eher geringen Einschränkungen. Bei OnDevice kein ausgewachsenes Java verwenden zu können, zählt für mich nicht als ernsthafte Einschränkung.

Und eigentlich hatte sich die Ob-Frage schon lange geklärt. Es geht nur noch darum, den besten Weg für die Art der Umsetzung zu finden.

Weil RAM viiiiiiiel schneller reagiern muss und breiter angebunden wird.

Klar sollte RAM schneller reagieren als eine SD-Card, aber wenn der ein bißchen langsamer ist als der interne Flash-Speicher, könnte ich problemlos damit leben. Ich bin kein Hardware-Jogi, aber technisch machbar sollte das doch sein.

@Wozu: Stromverbrauch

Ein Raspi Model B braucht meines Wissens 3,5 Watt und ein Model A nur 1 Watt. Das ist also nicht das "Burner"-Argument 

Das ist ein ziemliches Burner-Argument, wenn du zum Betrieb einen Akku verwendest...

Und ne SD-Karte ist nicht ein bisschen langsamer. Darauf würdest du mit Sicherheit nicht leben wollen. Geschwindigkeitsunterschied: RAM ist um den Faktor 1000 schneller.

Diese Diskussion führt aber eh zu nichts. Das ist von TF schon ausgeschlossen worden.

Es geht nicht darum, das Machbare zu erweitern. Es geht darum, die Arten, etwas Machbares zu machen, zu erweitern.

Der Wunsch nach OnDevice in der Art, wie wir das hier diskutieren, kommt schon lange. Es gehört mit zu den am meisten nachgefragten Features bei TF.

Wie gesagt, ich finde OnDevice ja auch klasse. Und ja, es ist super, wenn man etwas auf verschiedene (möglichst viele) Arten machen kann. Die Frage bleibt trotzdem, ob der Aufwand in einem passenden Verhältnis zum Nutzen steht. Für mich stellt es sich im Moment so dar, als ob die OnDevice-Fähigkeit ein sehr großen Aufwand bei der Realisierung hätte. Dagegen sehe ich keinen wirklichen Mehrwert.

Und ne SD-Karte ist nicht ein bisschen langsamer. Darauf würdest du mit Sicherheit nicht leben wollen. Geschwindigkeitsunterschied: RAM ist um den Faktor 1000 schneller.

Ich habe ja auch gesagt ein bißchen langsamer als der interne Flash-Speicher (oder RAM) und nicht SD-Karte.

Okay, gehen wir mal anders ran:

Hardwaretechnisch sieht es folgendermaßen aus: Wir haben einen Master-Brick, auf dem ein ARM-Controller hockt. Der ARM-Controller ist vergleichbar mit dem Prozessor eines normalen PCs, der Master Brick ist das Mainboard. Der Controller an sich kann zusätzlichen Flash-Speicher ansprechen, genau wie beim PC auf dem Mainboard RAM-Plätze vorhanden sind. Das Problem ist folgendes: Genau wie bei einem normalen PC ist das aber nicht nach außen (= bei den Bricks auf die Stack-Stecker) geführt, sondern nur auf dem Board des Bricks selber verfügbar. Nach außen im Stack verfügbar ist die serielle Schnittstelle, SPI etc. Bei dem Vergleich zum PC wäre das dort USB, der Druckerport usw., eben alles was außen am PC verfügbar ist.

Wird klar, wo hier technisch das Problem liegt? Du willst ja auch nicht deinen Arbeitsspeicher an den USB-Port hängen müssen, wo der ja schon bei externen Festplatten langsam ist...

 

Wie gesagt, ich finde OnDevice ja auch klasse. Und ja, es ist super, wenn man etwas auf verschiedene (möglichst viele) Arten machen kann. Die Frage bleibt trotzdem, ob der Aufwand in einem passenden Verhältnis zum Nutzen steht. Für mich stellt es sich im Moment so dar, als ob die OnDevice-Fähigkeit ein sehr großen Aufwand bei der Realisierung hätte. Dagegen sehe ich keinen wirklichen Mehrwert.

 

Ok, wenn du den Mehrwert nicht siehst, dann kann ich nur noch versuchen, dich mit dem Mehrheitsargument zu überzeugen.    Die meisten Leute sehen den Mehrwert.

Ich habe ja auch gesagt ein bißchen langsamer als der interne Flash-Speicher (oder RAM) und nicht SD-Karte.

Sorry, da hatte ich dich dann wohl falsch verstanden.

Aber so insgesamt sind wir so langsam völlig weg von der Diskussion C, Python oder (es wird Abend) TinkerBasic. Kommen wir doch dahin zurück. 

@benatweb:

Danke für die Erklärung, jetzt wird es klarer, was ihr meint.

Vielleicht ist es noch nicht so klar geworden: Die Performance eines RAM-Bricks ist für mich nicht so wichtig. Und: Hat Microsoft nicht mit Windows 7 eingeführt, dass man den Speicher mit USB-Sticks erweitern kann? Das würde also völlig reichen.

Außerdem: Was spricht dagegen, einen neuen Master-Brick zu machen, der mehr Speicher hat oder zumindest die Möglichkeit hat, einen RAM-Brick "schnell" anzuschließen?

Ok, wenn du den Mehrwert nicht siehst, dann kann ich nur noch versuchen, dich mit dem Mehrheitsargument zu überzeugen.

Wie war das mit den Fliegen und der Sch... 

Wenn es wirklich soviele wollen, dann müssten hier doch die Killerargumente am laufenden Band kommen. Hmmm, bisher nicht.

Und nochmals: Ich finde OnDevice toll. Wenn es nur ein Aufwand von wenigen Stunden oder Tagen ist, dies zu realisieren, dann go for it. Wenn es allerdings mehrere Wochen sind, dann sollten meiner Meinung nach die Prioritäten anders gesetzt werden.

Mehr Sinn würde es vermutlich machen ein Gehäuse anzubieten in dem man ein Raspberry PI und Bricks befestigen kann. Dazu dann vielleicht noch Kabel um das Raspberry PI über die Step-Down Power Supply zu versorgen und mit einem Brick-Stapel zu verbinden. Könnte dann eins von den neuen Kits sein die wir planen: "Starter Kit: Raspberry PI"

Was haltet ihr von einer Raspberry PI Adapterplatine? Statt einem Gehaeuse ein mechanisch und elektrischer Adapter?

Zum Thema RAM: Habt ihr schonmal ueberlegt das Programm direkt von/aus einem EEPROM laufen zu lassen? Quasi von einem belibiegen Bricklet. Hat die CPU ggf. einen transparenten Modus so dass sie fuer Programme direkt auf ein I2C EEPROM zugreifen kann ohne dass man I2C Kommandos "manuell" nutzen muss? Reicht die Geschwindigkeit? Sinngemaess: "Seriell angebundes Programm ROM"

Ich kann mich leider nicht mehr daran erinnern, aber ich habe eine Schaltung gesehen, wo das Programm aus einem seriellen EEPROM lief. Prueft das dochmal.

Der Loetkolben

Mal abgesehen von der Adapterplatine:

Warum wollt ihr die ganze Zeit Hardware-Erweiterungen? Es geht alles auch so. Braucht man gar nicht. Und selbst, wenn es mit der vorhandenen Hardware "nur" mit C geht, geht es...

Es geht hier letztlich nur um eine Anpassung der jetzigen Firmware dergestalt, dass man den PC wegfallen lassen kann. Auch den Pi.... Ohne weitere Hardware. Es geht nur um die Frage: Passiert das in C oder geht das auch vertretbar mit Python.

Und wenn eine Menge Leute konkrete Vorstellungen hat, was sie machen will und warum sie dafür OnDevice gerne hätte, dann würde ich diese Leute nicht als Fliegen auf der Sch**** sehen.  Und diese Leute sehen es als wichtig genug an, dass man dafür auch mehr als ein paar Tage investiert. Wie allein diese Diskussion schon zeigt. Und wenn man was hat, was Leute wollen, dann kaufen die Leute das. Und das liegt ganz im Interesse von TF. (Allerdings verkaufen die vermutlich zur Not auch an Fliegen  )

EDIT:

@TF: Falls ihr das anders seht und ihr doch nach Hardware-Erweiterungen Ausschau haltet, dann korrigiert mich bitte. Aber bis zuletzt habt ihr ja auch noch das Gegenteil gesagt