FabianB

Danke AuronX, du hast mir gerade das Tippen erspart.

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.

Die fertige SD-Karte zum Verkauf finde ich kein überzeugendes Argument. Ein fertiges Programm, was man mit dem Brick-Viewer nur drauf flasht, tut das Gleiche. Ist auch nicht schwerer.

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.

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? 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.

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?

Danke für die Thread-Trennung!! Meine Reihenfolge wäre wie gesagt: 1. Python (Wenn es im Vergleich zu der C-Variante die Funktionalität nicht zu extrem einschränkt) 2. C 3. TinkerBasic Wie realistisch schätzt ihr (TF) denn die Stemmbarkeit des Aufwands für den Fork von Py-on-a-Chip ein? Welche Prioritäten sind für euch noch wichtig? Nach dem, was wir so wissen, sind vermutlich hierzu die meisten Argumente für C/Python abgewägt worden.

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.

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

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.

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.

Hier ist das Start-Stop Skript (nicht von mir, von TF) #!/bin/sh ### BEGIN INIT INFO # Provides: brickd # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: brickd # Description: brick daemon ### END INIT INFO # brickd (Brick Daemon) # Copyright (C) 2011-2012 Olaf Lüke <olaf@tinkerforge.com> # # based on skeleton from Debian GNU/Linux # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public # License along with this program; if not, write to the # Free Software Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/bin/brickd NAME=brickd DESC="Brick Daemon" test -f $DAEMON || exit 0 set -e case "$1" in start) echo -n "Starting $DESC: " start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid --exec $DAEMON echo "$NAME." ;; stop) echo -n "Stopping $DESC: " start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid echo "$NAME." ;; restart|force-reload) echo -n "Restarting $DESC: " start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid sleep 1 start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid --exec $DAEMON echo "$NAME." ;; *) N=/etc/init.d/$NAME echo "Usage: $N {start|stop|restart|force-reload}" >&2 exit 1 ;; esac exit 0 Das solltest du eigentlich so übernehmen können (musst du nochmal kontrollieren, ich weiß nicht, ob beim selber kompilieren alles genauso angelegt wird. Eher nicht, vermute ich. Ich weiß es nicht. DU wirst die Dateien entsprechend an die Orte verschieben müssen, an die sie gehören). Kann dann als "brickd" in /etc/init.d/brickd eingetragen werden. Dazu natürlich in die Runlevel-Verzeichnisse /etc/rcX.d/K20brickd

Ups stimmt sorry, da war ich was vorschnell.

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

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. 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.

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. 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.

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.

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

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?

Kein Bastelprojekt, aber trotzdem interessant: Den BackTrack Nachfolger Kali-Linux gibt es auch für den Raspberry Pi: http://de.docs.kali.org/armel-armhf-de/installation-von-kali-arm-auf-einem-raspberry-pi

Diese Seite hier könnte auch helfen: Hier ist erklärt, wie brickd auf dem Raspberry Pi (auch armel) installiert wird: http://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html

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.

Sehr sinnvoll Klingt zielstrebig Habt ihr denn noch Argumente/Überlegungen, die wir hier noch nicht kennen? Ich habe so langsam das Gefühl, dass alle Argumente auf dem Tisch liegen. Ist es nicht letztlich nur noch eine Entscheidung, wie viel Aufwand ihr dafür betreiben wollt? TinkerBasic ist doch mehr oder weniger raus. C ist weniger Aufwand, Python mehr, wegen Py-on-Chip-Fork usw. Technische Unterschiede in der Qualität der Ergebnisse gibt es nur wenige, falls ich das richtig verstanden habe. Jeweils 1000N/s, nur wird bei Python nicht der gesamte Befehlssatz unterstützt.Höchstens das Speicherplatzproblem würde noch für C sprechen, oder? Angenommen, dass das keinen relevanten Unterschied macht, bleibt also abzuwägen, wie viel Aufwand eine Benutzerfreundliche Lösung wert ist. Und da Tinkerforges Hauptaugenmerk auf der Einfachheit liegt, spricht das eher für Python...