ArcaneDraconum Geschrieben October 2, 2012 at 09:31 Share Geschrieben October 2, 2012 at 09:31 Hallo zusammen, ich schaue immer mal wieder gespannt auf die Timeline. Diese wird auch nach und nach ganz brav abgearbeitet. ABER..... am unteren Ende kommt nix dazu. Ja sind Euch schon die Ideen ausgegangen? Oder habt Ihr kein Lagerplatz für neue Bricklets? Wird es auch neue Brick-Typen geben? Extensions? Es geht ja um keine konkreten Veröffentlichungsdaten, sondern einfach auch darum, für welche Typen Ihr Euch entschieden habt. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben October 2, 2012 at 12:20 Share Geschrieben October 2, 2012 at 12:20 Ja sind Euch schon die Ideen ausgegangen? Das kann ich mir nun am wenigsten vorstellen, zumindest werden wir "fleißigen" User diesbezgl. für Nachschub sorgen Und wenns keine neue Hardware gibt, haben wir Zeit zum Durchatmen und freuen uns auf ev. die ersten Gehäuse für Brick-Stacks oder das umgesetzte Konzept des OnDeviceProgramming Auch so, ein Power-Brick incl.Akku oder ein StepUp-PowerSupply wäre prima Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
gagahhag Geschrieben October 2, 2012 at 12:30 Share Geschrieben October 2, 2012 at 12:30 Und wenns keine neue Hardware gibt, haben wir Zeit zum Durchatmen... Oder auch einfach Zeit zum Sparen, damit man sich die neuen Sachen dann mal kaufen kann Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben October 2, 2012 at 12:33 Autor Share Geschrieben October 2, 2012 at 12:33 Es gibt da ja einen Riesenthread - so als Ideensammlung. Das sollte auch mal mehr ein Anspornmail sein, an die Timeline was anzuhängen. Also eine Selektion der Ideen. Oder auch einfach Zeit zum Sparen, damit man sich die neuen Sachen dann mal kaufen kann Man muss ja nicht jedes Bricklet in der Sammlung haben. Aber ein Sammelalbum wäre mal ne nette Idee. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
gagahhag Geschrieben October 2, 2012 at 12:37 Share Geschrieben October 2, 2012 at 12:37 Man muss ja nicht jedes Bricklet in der Sammlung haben. Aber ein Sammelalbum wäre mal ne nette Idee. So mit Sticker der Brick/lets zum reinkleben und der jeweiligen API? Wobei die API als PDF wäre auch nicht schlecht ... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben October 2, 2012 at 17:50 Share Geschrieben October 2, 2012 at 17:50 Wir sind uns noch nicht zu 100% sicher, aber wir werden nach current/gps/industrial bricklets/ethernet extension evtl einmal einen Strich ziehen und das Protokoll umändern. Die Frage ist wie groß das Chaos da werden würde. Ich würde gerne die Stack ID aus dem Protokoll entfernen und dafür direkt die UID benutzen. Nachrichten werden dann nicht mehr durch das System geroutet sondern an alle verteilt und die Empfänger von Nachrichten gucken nach ob die Nachricht für sie ist. Nachteil: Mehr Daten zu übertragen (1 Byte vs 8 Byte). Vorteil: Robusteres System. Viele Probleme die wir haben kommen durch die starre Verteilung der stack id zustande. Da wir einmal ganz am Anfang wenn das erste mal eine Verbindung aufgebaut wird die Stack IDs erstellen, muss das System danach starr bleiben. Beispiel: In einem Netzwerk aus RS485 Knoten startet ein Stack aufgrund von EMV Problemen neu. Nun Muss der Master des RS485 Netzwerks neugestartet werden, da eine neue Enumerierung durchzuführen ist. Bei einem direkten ansprechen über die UID gäbe es hier kein Problem. Ähnliche Probleme gibt es beim wechseln von Batterien usw. Ein weiterer Vorteil: brickd könnte auf 25 Zeilen Code verkürzt werden (einfach eine Zuordnung von UIDs zu USB Ports, mehr wird nicht mehr benötigt). Desweiteren würde ich noch ein weiteres Byte für Message Optionen hinzufügen, dort könnte man z.B. ein Bit auf high setzen um bei einem Setter zu sagen, dass es eine Rückantwort geben soll (Sicherstellung das ein Setter auch wirklich angekommen ist). Problem an der Geschichte: Wir hätten dann einen plötzlichen Versionssprung für Brickd und alle Brick und Bricklet Bindings, welcher inkompatibel zu allen vorherigen Versionen ist. Hinzu kommt, dass wir hier von einigen Bricklets tausende fertig verpackt und geflasht liegen haben. Die können wir unmöglich nochmal auspacken und neu flashen. Das würde also ein totales Versionschaos geben... Was meint ihr dazu? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben October 2, 2012 at 20:15 Share Geschrieben October 2, 2012 at 20:15 Also erst mal danke fuer den Vorschlag mitwirken zu duerfen. Letzteres sollte doch kein Problem sein. Das trifft doch eigentlich jede Woche zu oder? Sobald die Firmware geaendert wird, sind bereits geflashte Bricks nicht mehr aktuell. Zettel mit FW Version dabei und gut ist. Vielleicht solltest du aber noch einen Brainstorming Thread aufmachen. Ich wuerde gerne nochmal die (W)LAN Verschluesselung aufgreifen. Wenn ich mich recht erinnere hatte wir einen halbwegs brauchbaren Kompromiss gefunden, so dass nicht jeder im WLAN oder via Internet die Stacks manipulieren kann. Vielleicht kann man das alte und neue Protokolle 6 Monate gemeinsam pflegen um nicht bei allen Projecten der User ein Chaos auszuloesen. Das Thema reset und hangup ist wirklich ein Elend. Soweit meine Anmerkungen. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben October 2, 2012 at 21:38 Share Geschrieben October 2, 2012 at 21:38 Letzteres sollte doch kein Problem sein. Das trifft doch eigentlich jede Woche zu oder? Sobald die Firmware geaendert wird, sind bereits geflashte Bricks nicht mehr aktuell. Zettel mit FW Version dabei und gut ist. Das ist schon ein bisschen was anderes, ein Dual Relay das ein Plugin ohne Monoflop hat kann ich ohne weiteres mit einem neuen Master verwenden (oder andersrum). Wir hätten dann natürlich den Zustand, dass neue Bricks und Bricklets die wir verschicken vollkommen unbenutzbar zusammen sind im Auslieferungszustand. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Holy Geschrieben October 2, 2012 at 22:36 Share Geschrieben October 2, 2012 at 22:36 Wir hätten dann natürlich den Zustand, dass neue Bricks und Bricklets die wir verschicken vollkommen unbenutzbar zusammen sind im Auslieferungszustand. Die angedachte Änderung klingt sehr sinnvoll aber ich denke diesen beschriebenen Zustand muss man unbedingt vermeiden. Für versierte Nutzer alles kein Problem aber für Neueinsteiger sehr abschreckend. Warten das alle Altbestände raus sind wird wohl kaum gehen da ja sicher von irgend einem Brick/Bricklet immer eine größere Charge da sein wird. Evtl. im Shop die Möglichkeit aktiv Brick/Bricklets mit alter FW zu bestellen mit einem kleinen Rabatt oder sowas. Dann kann sich jeder, unter Wissen des Aufwands/Probleme, aktiv dafür entscheiden und der Standardweg ist einfach neue Hardware mit aktueller Firmware. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
gagahhag Geschrieben October 2, 2012 at 22:46 Share Geschrieben October 2, 2012 at 22:46 Ich schätze jedoch, dass jederman der bei Tinkerforge etwas bestellt, in irgend einer Art ein 'Bastler' ist und mit einem beigelegten Zettel/Anleitung fähig sein sollte, die Hardware zum Laufen zu kriegen? Wobei man auch im Shop mittels "Achtung, alte Firmware, vor dem benutzen bitte flashen" darauf hinweisen kann, inkl. Link zu einer Anleitung. Grundsätzlich testet man doch zuerst seine Sachen mittels Brickv, um zu sehen, ob das Teil funktioniert und kann es eigentlich auch gleich flashen. Wobei hier eine Versions-Anzeige im Brickv sein könnte, welche neben der geflashten auch die aktuelle Version anzeigt (welche direkt von Tinkerforge geladen wird :. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
M4ST3R Geschrieben October 2, 2012 at 23:17 Share Geschrieben October 2, 2012 at 23:17 Glaube die generelle Überarbeitung ist sinnvoll. Auch das Enumerate wurde schon diskutiert bzw. die UID müsste bei Device verfügbar sein Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben October 3, 2012 at 05:59 Autor Share Geschrieben October 3, 2012 at 05:59 Also ich persönlich sehe auch kein Problem mit der Flasherei. Ich habe hier einen "Teststack", an den neue Bricklets ersteinmal rangehängt werden. Ich ändere grundsätzlich die UID auf etwas systematisches. Ne neue Firmware zusätzlich noch zu flashen wäre also kein Problem. Und besser einen richtigen Cut und eine Anleitung für Neueinsteiger, also irgendein Übergangsgemurkse. Ich muss sagen, ich freu mich schon darauf.... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Holy Geschrieben October 3, 2012 at 06:52 Share Geschrieben October 3, 2012 at 06:52 Das ist ja genau der Punkt! Für uns alles kein Problem. Nur ein Neueinsteiger wird mit "Einfach" auf der Startseite gelockt und hätte dann erstmal ne tolle Anleitung und nicht zu einander kompatible Hardware vor sich liegen. Erscheint mir schwierig. Zu dem Cut hast du vollkommen recht. Lieber gescheit umstellen als alte Zöpfe ewig mitzunehmen und vermurkste Lösungen zu bauen nur damit die alte API noch geht. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Malik Geschrieben October 3, 2012 at 11:06 Share Geschrieben October 3, 2012 at 11:06 Ich glaube ich wäre ganz schön sauer gewesen wenn meine ersten TF-Teile nicht miteinander geredet hätten. Das "Baukasten-Prinzip" ist doch gerade das Alleinstellungsmerkmal von Tinkerforge. Nach meiner unmaßgeblichen Meinung: - ist die Änderung des Protokolls sinvoll - dürfen Anfänger nicht verärgert werden - daher ist ein clean cut gefährlich Vielleicht kann man zum Abverkauf der schon verpackten Teile zweigleisig fahren. Wie Holy schon geschrieben hat könnte bei der Bestellung eine Wahlmöglichkeit angeboten werden: "FW Version 1: vollkompatibel" oder "FW Version 2: eventuell müssen bereits vorhandene Bricks/Bricklets neu geflasht werden". Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben October 3, 2012 at 11:31 Share Geschrieben October 3, 2012 at 11:31 Ähnliche Probleme gibt es beim wechseln von Batterien usw. Ein weiterer Vorteil: brickd könnte auf 25 Zeilen Code verkürzt werden (einfach eine Zuordnung von UIDs zu USB Ports, mehr wird nicht mehr benötigt). Meinst du der brickD wird um 25 Z. verkürzt oder bleiben nur noch 25 Z. Code gesamt übrig ? Desweiteren würde ich noch ein weiteres Byte für Message Optionen hinzufügen, dort könnte man z.B. ein Bit auf high setzen um bei einem Setter zu sagen, dass es eine Rückantwort geben soll (Sicherstellung das ein Setter auch wirklich angekommen ist). So eine Änderung der API muss zwangsläufig in unseren Anwendungen angepasst werden. Problem an der Geschichte: Wir hätten dann einen plötzlichen Versionssprung für Brickd und alle Brick und Bricklet Bindings, welcher inkompatibel zu allen vorherigen Versionen ist. Hinzu kommt, dass wir hier von einigen Bricklets tausende fertig verpackt und geflasht liegen haben. Die können wir unmöglich nochmal auspacken und neu flashen. Das würde also ein totales Versionschaos geben... Hmmh, bedeutet ev. mehr Stress für Euch als für uns, wir könnten nur soviel helfen, indem wir gebetsmühlenartig auf das FW-Upgrade hinweisen. Voraussetzung für diesen Versionssprung müsste man den BrickV soweit verbessern, dass das FW-Update vollautomatisch mit anschl. Reset ist. Fragen von Neueinsteiger wird es auch ohne Neudesign immer geben. Ein Beipackzettel in die Auslieferungen zu legen, mit dem Hinweis die veraltete Hardware upgraden, ist m.E. ein guter Gedanke und wird bei anderen Herstellern auch gemacht. Das Chaos wird aber mit der Zeit weniger. Was bedeutet das für unsere bestehenden Anwendungen, reißt das wenige oder viele Baustellen auf ? Oder wie stark wird dann die neue API/Bindings nach außen verändert sein ? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Loetkolben Geschrieben October 3, 2012 at 12:06 Share Geschrieben October 3, 2012 at 12:06 Denkt doch mal einen Schritt weiter, und zwar zu dem Zeitpunkt wenn alle Bricks/Bricklets mit alter FW ausverkauft sind. Was macht dann ein User der noch einen "alten" Stack betreibt und nun zur Erweiterung ein Bricklet kauft? Das wird nicht bei ihm laufen und woher soll er wissen warum es nicht geht? Entweder er muss den Stack komplett upgraden oder das Bricklet runterflashen. Also muss auch hier eine Info/Zettel mit rein, dass dies nun ein Bricklet ist mit neuer FW. Wie lange soll das nach dem Ausverkauf der alten gemacht werden? Grundsaetzlich gehoert die Info rein, dass man die FW nach dem Kauf pruefen soll. Wie schon in einem andren Thread angesprochen koennte hier der Brickviewer helfen. Der Loetkolben Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben October 3, 2012 at 12:25 Share Geschrieben October 3, 2012 at 12:25 Was bedeutet das für unsere bestehenden Anwendungen, reißt das wenige oder viele Baustellen auf ? Oder wie stark wird dann die neue API/Bindings nach außen verändert sein ? Die API wird gleich bleiben. Solche Optionen wie "Antwort für Setter" sind einfach zusätzliche Optionen die gesetzt werden können (Default ist kompatibel zu älteren Versionen). Da sehe ich keine Probleme. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben October 3, 2012 at 14:48 Share Geschrieben October 3, 2012 at 14:48 Hmmm... mir fällt auch gerade nix geschicktes für das Umstiegsproblem ein. Ich bin aber auch stark für die Überarbeitung des Protokolls, da ich auch das Gefühl hatte ihr tragt schon viele "Altlasten" mit euch rum. Außerdem habe ich einmal den brickd anpassen wollen und mich vor lauter Routing-Tabellen-Magie ängstlich zusammengekauert. Was toll wäre, ist wenn das Protokoll erweiterbar wäre. Die einfachste Form ist halt ein Byte am Ende das angibt wie viele Bytes noch für die kommende Extension folgen. Aber das ist jetzt villt schon zu weit gedacht, deswegen führe ich das nicht weiter aus ^^ Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben October 3, 2012 at 16:40 Share Geschrieben October 3, 2012 at 16:40 Mein letzter Post war etwas wirr glaube ich, deswegen jetzt nochmal mit Struktur: Thema: Erweiterbarkeit Motivation Das neue Protokoll wird besser als das alte, aber auch inkompatibel dazu sein. Deswegen kommen jetzt bestimmt noch einige Wünsche für das neue Protokoll auf. Viele dieser Wünsche werden sicherlich erfüllt, andere möglicherweise nicht. Wenn dann etwas Zeit vergeht wird man merken, dass auch am neuen Protokoll noch etwas fehlt. Aus diesem Grund sollte man bereits jetzt darüber nachdenken, wie man das Protokoll kompatibel erweitern kann. Wenn man es richtig anstellt erhält man 2 Gewinne: 1. Das Protokoll ist ein wenig zukunftssicherer, weil es "nachrüstbar" wird 2. Spezialwünsche einiger Nutzer, die nicht für die allgemeinheit geeignet sind, lassen sich auch über Protokollerweiterungen realisieren Mein Minimalvorschlag Das neue Protokoll wird ja denke ich wie das alte "Paketorientiert" sein, das heißt ich schicke eine Binärnachricht mit bestimmter Größe durch die Gegend. Mein Vorschlag: Am Ende des regulären Paketes kommt ein Byte (im Folgenden EXT_SIZE genannt). Dieses Byte bestimmt die Größe der folgenden Protokollerweiterung. Wenn die EXT_SIZE gleich 0 ist, dann bedeutet das, dass das Paket abgeschlossen ist und nichts mehr folgt. Wenn der Wert von EXT_SIZE größer 0 ist, dann folgen noch eben so viele Bytes wie von EXT_SIZE angegeben, sowie ein weiteres EXT_SIZE. Dieses ist nun wiederum 0, wenn keine weitere Erweiterung folgt oder gibt die Größe der nächsten Erweiterung an. Behandlung Ein Brick/Bricklet/Teilnehmer der gar keine Extensions kennt oder versteht kann diese einfach überlesen und sich nicht selbst um sie kümmern. Er kann sie sogar weiterleiten, ohne sie zu verstehen (z.B. ein Master-Brick per Extension). Das gewährleistet grundsätzlich abwärtskompatibilität. Beispiel Zum besseren Verständnis ein Beispiel: Später möchte man CRC-Prüfungen des Paketinhaltes durchführen. Das heißt der Sender soll eine Prüfsumme für eine Nachricht berechnen, damit der Empfänger prüfen kann, ob die Nachricht unverfälscht ankam. Der Sender fügt hierzu eine Extension an seine Nachricht, in dieser Extension legt er die Prüfsumme des Paketinhaltes ab. Der Empfänger kann diese Prüfsumme mit der selbst berechneten Prüfsumme vergleichen. Auslassungen Mein Vorschlag lässt absichtlich einen Teil aus: Der Inhalt der Extension. Man muss sich (später) zumindest auf eine grobe Struktur einigen. zum Beispiel: Am Anfang der Extension kommt ein Byte das anzeigt, um was für eine Art von Extension es sich handelt (CRC, Passwort, Krypto, was-auch-immer), erst danach der eigentliche Inhalt. Hoffe das ist jetzt nochmal etwas klarer als mein letzter Post. ^^ Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.