Equinox

Stimmt, das Barometer-Bricklet hat auch einen Temperatursensor, aber nur für die Temperatur des Luftdrucksensors. Diese ist nicht so genau wie die Temperatur die vom Temperature-Bricklet gemessen wird.

Hallo, ich finde das auch eine sehr schöne Idee. Bei den Farben würde mir persönlich das transparente Acrylglas völlig reichen. Ich finde das sieht super aus. Allerdings wundere ich mich ein bißchen über die Bricklet-Auswahl: Was ist der Grund für das Ambient Light Bricklet? Ich hätte bei einem Wetter-Kit eher ein Temperature-Bricklet erwartet. Vielleicht könnt ihr ja beide Versionen anbieten? Das würde ich für sinnvoller halten, als mehrere Farben.

Dann wäre es ja keine eigene Neuentwicklung und man könnte "Synergie"-Effekte nutzen. Ich würde das super finden! Es wäre ja nicht nur WiFi, sondern auch über Ethernet. Und wenn das mit der SD-Card kombiniert wird, die ja praktisch von allen gebraucht wird, die OnDevice nutzen wollen (und das soll ja die Mehrheit sein), dann würde sich das schon lohnen.

Da kann ich ArcaneDraconum nur zustimmen. Für mich würde es auch reichen, wenn man den BrickV so erweitert, dass er auch über WLAN flashen kann und der MasterBrick nicht mehr von Hand in einen speziellen Flash-Modus versetzt werden muss.

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?

Hmmm, ich glaube wir reden aneinander vorbei. Die Frage war, ob die (vorgesehene) abgespeckte Version von Python/C dies unterstützt. Ich denke nicht, dass das Dinge sind, die in die TF-API sollten, wenn es schon "native" möglich ist. Sprich: Können die erwähnten Dinge mit den vorgesehenen (möglichen) Versionen von Python/C/TinkerBasic gemacht werden oder sind diese Möglichkeiten bei den Versionen dem "Abspecken" zum Opfer gefallen? Was sind genau die Dinge, die dem "Abspecken" zum Opfer gefallen sind?

Nicht über USB, sondern über WLAN. Vergessen habe ich noch das Anbieten von Web-Services.

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

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 finde ich eine super Idee!

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.

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.

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.

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). Hmm, dass das gerade von Dir kommt, wundert mich jetzt schon

Deshalb habe ich ja auch "optional" gesagt. Ich würde es aber schön finden, wenn drauf wäre, damit die Stapel kleiner bleiben. 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)

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.

Die Idee/Anfrage von Loetkolben finde gut. Speziell würde mich auch interessieren, was denn bei Python die Einschränkungen sind (bisher habe ich nur gelesen, dass es welche gibt, aber nicht welche). Ist es z.B. möglich, mit anderen "Clients" zu kommunizieren (gibt es z.B. Sockets, RPC, RMI, oder Ähnliches)? Oder kann man dann "nur" mit den angeschlossenen Bricks und Bricklets kommunizieren?

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.

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

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?

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?

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

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. Ich habe ja auch gesagt ein bißchen langsamer als der interne Flash-Speicher (oder RAM) und nicht SD-Karte.

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. Ein Raspi Model B braucht meines Wissens 3,5 Watt und ein Model A nur 1 Watt. Das ist also nicht das "Burner"-Argument

Von den Beispielen überzeugt mich nur dieses: 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.

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