borg

Everything but the enumeration process should stay the same for someone that uses our bindings. It would (with the current and with the new protocol) be possible to implement Bindings that return a Future Object instead of the current blocking behavior. This would probably be quite hard to generate for some of the languages and it would likely be hard to understand for people that are just starting programming. If you want to try to implement something like that, your Bindings will need a queue for the Future Objects per function id. Answers to requests are guaranteed to come in the correct sequence. So you can add the data of the latest request to the current head of the queue and pop it. A newly generated Future Object will be put at the end of the queue, respectively. Does that make sense ?

Das ist ganz einfach: Alles was vom USB, Ethernet, WIFI, RS485 Master, Chibi Master und SPI Master Interface kommt geht in Richtung UID. Alles was von SPI Slave, RS485 Slave, Chibi Slave und Bricklet Interface kommt geht Richtung Wurzel.

Die Rückantwort hat auch die Adresse des antwortenden. Jop.

Die Sequenz-Number würde schon genutzt werden von den Bindings und auch für das Routing (d.h. eine Antwort auf eine Anfrage mit einer gewissen Sequenz-Number muss wieder die gleiche Sequenz-Number haben). Dies sollte im Moment nicht notwendig sein, gibt aber natürlich nochmal zusätzliche Robustheit. Ansonsten ist es schon so gedacht, dass alles was in dem Byte steht wo die Sequenz-Number mit drin steht, bei Antworten gleich ist wie bei Anfragen. D.h. das ganze Byte kann fürs Routing verwendet werden. Daher die Unterscheidung zwischen "Options" (Bei einer Antwort auf eine Anfrage bleiben diese gleich) und "Flags" (können bei einer Antwort gesetzt werden, z.B. Errors). Wenn du so möchtest ist die Sequenz-Number etwas das optional von den Bindings genutzt werden kann. Die Bricks kümmern sich nicht um die Sequenz-Number und geben sie bei Antworten einfach wieder zurück.

Der Flaschenhals ist natürlich nicht das USB Protokoll oder Ethernet. Der Flaschenhals sind die Buffer auf den Microcontrollern, die Zeit die wir benötigen um per SPI die Buffer der WIFI Extension auszulesen, um bei der Authentication auf dem Microcontroller den Hash zu bestimmen usw usw... Guck dir den Master Brick an: Dort werden einmal pro ms die Bricklet Plugins ausgeführt, die haben je 150us Zeit. Also sind schonmal 600us weg. D.h. wir haben noch 400us Zeit um im Zweifelsfall zwei Extensions , den Stack, USB und die Authentifizierung zu bearbeiten. Dort ist alles abhängig von der Paketgröße ! Das ist nicht weiter schlimm. Grundsätzlich Antworten Bricks im Moment ja immer in der richtigen Reihenfolge, d.h. die Sequenz Nummer ist im Moment gar nicht nötig. Wenn wir in Zukunft irgendwann einen Brick haben der echtes Multitasking kann, wird er kaum mehr als 16 Nachrichten gleichzeitig bearbeiten können.

Wenn du ein Brick/Bricklet tauscht, musst du im Code natürlich die UID tauschen, wie beim alten Protokoll. Alternativ basiert dein Code komplett auf den Antworten vom Enumerate Callback, dann muss nichts getauscht werden. Wenn du selber TCP/IP Pakete baust musst du natürlich auch selber "die Bits zusammenrechnen". Damit du das nicht machen musst bieten wir ja schließlich die ganzen Bindings . Das zusammenbauen der Option und Flags Bytes ist absolut trivial verglichen mit dem "Resolve UID to Stack ID" Prozess (der jetzt wegfällt). D.h. meiner Meinung nach wird es mit dem neuen Protokoll leichter selbst TCP/IP Bindings zu bauen. options = (sequenz << 0) | (return_expected << 4) | (authentication << 5) Fertig. Das Durchschnittliche Paket bei uns im System hat einen Payload der größe 3 Byte. D.h. die Nachricht war im Alten Protokoll 7 Byte groß, im neuen ist sie 11 Byte groß. 10 Byte mehr würde den Durchsatz halbieren, nur damit man sich den oben geschriebenen Code sparen kann wenn man selber das Protokoll auf TCP/IP Ebene implementiert ? Edit: Die nächsten Bindings die wir veröffentlichen werden übrigens Shell Bindings sein, das sollte für dich interessant sein! Das wird in etwas so aussehen: user@pc:~$ tfcall -u abc -f getTemperature 25.41 user@pc:~$ tfcall -u Nq41f -f setServoPosition -p 1,180 Oder allgemein: tfcall -u UID -f function [-p parameters] [-o options] Dadurch das man mit dem neuen Protokoll einfach Daten ins System schicken kann, ohne vorher eine Verbindung aufzubauen, ist das super einfach zu generieren .

Öh, ich antworte mal nicht zu jeder Frage einzeln, du hast da irgendwas falsch verstanden . Die Bindings nach außen hin werden exakt so bleiben sie momentan sind. Im Hintergrund fällt ein bisschen Gefummel weg, weil die Stack ID wegfällt. Die einzelnen Bits der Optionen setzt du natürlich nicht selber, da gibt es API für. Die IPConnection wird sowas haben wie (Pseudocode): ipcon.setAuthenticationKey(byte[96] key) ipcon.enableBlockingSetter() ipcon.disableBlockingSetter() Dazu dann evtl. den Vorschlag von AuronX, ansonsten könnt ihr euren Source Code weiterverwenden. Die Alten 64bit UIDs können auch weiterverwendet werden, die rechnen wir in der IPConnection einfach um. Das einzige was sich wirklich ändert ist der Enumerate Callback. Da gab es ja schon reichlich Beschwerden und Verbesserungsvorschläge, die wir eigentlich mit dem neuen Enumerate Callback alle umgesetzt haben sollten . Edit: Zu den Other Options: Die 7 "future use" bits können natürlich auch für Optionen genutzt werden. Desweiteren kann man natürlich mit einem bit auch noch weitere Optionen aktivieren, die dann unten beim Optional Data mit drinstehen. Da sind schon noch reichlich Bits frei .

Die Firmware für die Extensions ist mit auf den Master Bricks. In dem EEPROM einer Extension werden nur die Konfigurationen gehalten. Wir hatten damals geplant die Firmware der Extensions auch mit auf das EEPROM zu packen, leider passt das aber nicht annäherend. Für die Ethernet Extension hab ich z.B. gerade ein DHCP Client implementiert, diese Implementierung alleine ist schon größer als der Flash. Hinzu kommt, dass die Extensions sich Code teilen. Zum Beispiel gibt es eine brickd Implementierung auf dem Master Brick, die von WIFI Extension und Ethernet Extension gleichzeitig genutzt wird. Edit: Nur um das nochmal klarer zu schreiben: Die WIFI Extension hat einen Prozessor mit drauf (vergleichbar mit dem Raspberry PI), die Firmware für diesen Prozessor ist natürlich _nicht_ auf dem Master Brick. Aber diese Firmware spricht einfach TCP/IP und das Protokoll was wir darauf sprechen ist im Master Brick implementiert und natürlich an das neue Protokoll anpassbar. Ich hoffe das ist verständlich.

Exakt richtig!

Die Bricks haben einige interne Buffer in Größe der maximalen Paketgröße (für unterschiedlichste Dinge). Das Paket war damals insgesamt maximal 64 Byte groß (4 Byte header, 60 Byte Payload). Wir haben jetzt im neuen Format das Payload auf maximal 64 Byte erhöht und das drumherum ist in Summe maximal 16 Byte groß. D.h. die Buffer wachsen alle um 16 Byte. Das ist noch verträglich. Eine Messagegröße von 128 Byte (doppelter RAM-Verbrauch) wäre z.B. definitiv zuviel des guten! Master1: uid=a, connctedUID=1 Master2: uid=b, connctedUID=a Eine eigene UID für die Extensions würde das ganze nur verkomplizieren. Die Idee das man Bindings für die Extensions hat gefällt mir aber trotzdem. Ich stelle mir sowas vor: master = Master(UID_MASTER) # Make Master Brick object try { wifi = WIFIExtension(master) # Make WIFI Extension object for master } except(ExtensionNotAvailableException e) { ... } wifi.set_configuration(...) Das hat jetzt nichts mit dem Protokoll zu tun, müsste man den Generatoren halt beibringen. Ist natürlich ein bisschen Arbeit, aber jetzt wäre auf jeden Fall der richtige Zeitpunkt dafür.

? Ist das eine Implementation von uns oder eine aus der neuen API ? Von euch. Wir machen dann natürlich noch ein echtes Beispiel dafür. Was beduetet das für die Extensions ? Bleiben die davon unbeteiligt ? WIFI und Ethernet sind davon nicht betroffen. Bei Chibi und RS485 steht in der connctedUID die UID des Master Bricks im Master Chibi/RS485 stack. Damit kann man dann natürlich auch die Extension-Topologie herausfinden! Beschreibt eindeutig den Typ des Bricks oder Bricklets ? Einfach eine Zahl die den Brick/Bricklet identifiziert. Also z.B. Master Brick = 1001 Servo Brick = 1002 Stepper Brick = 1003 ... Ambient Light Bricklet = 2001 Temperature Bricklet = 2002 ... Was meinst du mit "inkompatibel by design"? Du wirst einen 1.x.y RS485 stack nicht zusammen mit einem 2.x.y RS485 stack verwenden können. Wie soll das gehen? Die alte Hardware kann natürlich weiterverwendet werden.

The description for the new protocol is online: nline: http://www.tinkerforge.com/doc/Protocol_20.html We would love to get some productive criticism .

So, die Beschreibung des neuen Protokolls ist online: http://www.tinkerforge.com/doc/Protocol_20.html Produktive Kritik ist erwünscht .

Cool. Ich hab mal deinen Eintrag geändert , der Link war kaputt.

In einem Stack muss unten immer ein Master Brick sein ! Der Master Brick ist der einzige Brick, der die Stack Kommunikation leiten kann.

Wenn du in der config.h von einem Brick diese beiden Zeilen einkommentierst: //#define LOGGING_SERIAL //#define LOGGING_LEVEL LOGGING_DEBUG und die Firmware neu compilierst und draufspielst, werden printf Ausgaben auf der seriellen Konsole über den Debug Brick ausgegeben. Hinweis: Es können keine zwei Bricks in einem Stack gleichzeitig im Debug Modus sein!

Ha, da sind wir gerade drüber am diskutieren . Was würdet ihr da eigentlich lieber haben wollen, K-Type (Thermocouple) oder PTC (PT100, PT1000, etc)? Alle Temperatursensoren auf einmal wird man nie unterstützen können (Spannungsmessung vs Widerstandsmessung, unterschiedliche Widerstände etc). Wir könnten uns ein Bricklet vorstellen mit dem man per Jumper zwischen PT100 und PT1000 umstellen kann und bis zu 3 von diesen anschließen kann. Das wäre dann ein Industrial Bricklet (Spannungsversorgung von außen, galvanisch getrennt). Was meint ihr dazu?

Ich würde AuronX recht geben. Wer kein PoE benutzen will kann einfach ein 5€ USB Netzteil am Master anschließen. Wer genaue 5V oder viel Leistung auf der 5V Schiene haben will kauft sich einen "echten" PoE Injektor für 17€. Finde ich beides von den Kosten her wirklich ertragbar !

Wir benutzen hier zum testen so PoE Injektoren. Wir testen im Moment mit diesen zweien: http://www.amazon.de/ALLNET-ALL0490-Switch-verwaltet-ALL0489V2/dp/B003N12Z0Q/ref=sr_1_1?ie=UTF8&qid=1351245401&sr=8-1 http://www.amazon.de/TP-Link-TL-PoE150S-Ethernet-Single-Port-Injector/dp/B001PS9E5I/ref=sr_1_1?s=ce-de&ie=UTF8&qid=1351245433&sr=1-1 die scheinen problemlos zu funktionieren.

Wir können überhaupt nicht einschätzen wann/wo/wie GCC diesen Alignment Fehler einbaut. Ich befürchte die Bricklet Context Größe zu fixen ist die einzige vernünftige Alternative. Wer bisher noch keine Probleme damit hatte oder die IO4 nicht an Port B oder D anschließt muss ja auch nicht updaten . @Loetkolben: Kannst du nochmal mit der neuen Master Version probieren?

@ArcaneDraconum: Kannst du bitte nochmal mit der neuen DC Brick Version probieren?

Firmwares: DC Brick 1.1.6, IMU Brick 1.0.10, Master Brick 1.4.6, Servo Brick 1.1.5, Stepper Brick 1.1.9 Bricklet Context Größe von 250 auf 256 geändert (über bricklib). Dies umgeht die Alignment Probleme die neue GCC Versionen bei unseren Bricklet Plugins haben. Download Firmwares: DC Brick, IMU Brick, Master Brick, Servo Brick, Stepper Brick

Firmwares: DC Brick 1.1.6, IMU Brick 1.0.9, Master Brick 1.4.6, Servo Brick 1.1.5, Stepper Brick 1.1.9 Change Bricklet Context size from 250 to 256 (through bricklib). This gets rid of the alignment issues with Bricklet Plugins in newer GCC versions. Download Firmwares: DC Brick, IMU Brick, Master Brick, Servo Brick, Stepper Brick

Bleibt alles kompatibel. Einzig die IO4 Bricklet Firmware 1.1.2 wird nicht mit den älteren Brick Firmwares funktionieren.

Shit. Ich krieg zuviel. Wenn ich das richtig sehe tritt das Problem wieder nur auf Port B und D auf, sprich wir haben immernoch Probleme mit dem Compiler... An der eigentlichen Funktionalität hat sich zwischen 1.1.0 und 1.1.2 ja auch gar nichts geändert. Ich kümmer mich drum, im Zweifelsfall müssen wir runter auf die alte GCC Version. Sorry! Edit: OK, wenn ich die Brick Context Größe auf 256 stelle (anstatt 250) ist das Problem definitiv behoben. Ich denke das ist der Weg den wir gehen sollten. D.h. es wird neue Brick Firmwares geben. Wenn ich da jetzt anfange und irgendwo NOPs einbaue um das Problem zu beheben funktioniert auf einmal etwas anderes nicht mehr... Das hat gar keinen Zweck.