borg

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.

MCS ist korrekt! http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&category_id=20&option=com_phpshop&Itemid=1 mal schauen, vielleicht schenken wir uns zu Weihnachten eine eigene VID, dann steht da auch "Tinkerforge" (2000$...). Wir haben uns gerade auch einen eigenen MAC Adressen Block für die Ethernet Extension gekauft .

Es ist ausgeschlossen, dass wir die Firmwares auf allem was wir fertig verpackt im Lager liegen haben auf dem neuesten Stand halten. Das ist organisatorisch einfach nicht möglich. Wenn man sich ein neues Handy kauft updatet sich das auch sofort beim ersten einschalten. Das ganze wird um Weihnachten rum wenn wir das neue Protokoll veröffentlichen noch schlimmer werden . Allerdings sollte es danach viel besser werden, wir machen die Änderung ja nicht grundlos! @Nic: Bei Der Analog Out und dem Dual Relay kann ich das Problem nicht reproduzieren.

Jedes Bricklet bekommt 250 Byte speicher zugewiesen (BrickContext). Der Speicherbereich wird dem Bricklet bei der Initialisierung übergeben und dort wird ein großes struct drin angelegt, welches alle Variablen hält die jemals in einem Bricklet Plugin benutzt werden. Da 250 Byte leider nicht glatt durch 32bit teilbar sind (ups, hier hätten wir 256 Byte nehmen sollen, lässt sich jetzt aber nicht mehr ändern ) muss der Compiler hier hergehen und bei den Bricklet Ports B und D entweder Padding einführen oder die Variablen zusammenstellen (also z.B. 16bit aus Adresse x laden und 16bit aus Adresse x+1). Bei ersterem gibt es einen Bug in der aktuellsten arm-none-eabi-gcc Version. Dort optimiert er (anscheinend) zu stark, falls man ein struct in einem ganzen Block auf einmal initialisiert (siehe die for-Schleife). Auf jedenfall lies es sich durch das rausziehen eines Teiles der Initialisierung fixen. Das NOP ist in Assembler geschrieben und sorgt dafür, dass der Compiler das auch wirklich so übersetzt und die zweite Schleife nicht wieder wegoptimieren kann. Rausfinden kann man sowas nur indem man den Fehler im Assembler Code findet nachdem etwas abstürzt. Ein Fehler dieser Art dauert Tage bis man ihn findet... Warum genau nun zwischenzeitlich eine Firmware auf dem Server lag, die mit der neuen Compilerversion und ohne dem Workaround compiliert wurde kann ich leider nicht mehr nachvollziehen. Hätte nicht passieren dürfen. @Nic: Probier mal auch die Dual Relay Firmware zu aktualisieren.

NOPs = No Operation (damit sagst du dem Microcontroller er soll einen Takt nichts machen). Dadurch erzwingst du den Compiler etwas anderen Code zu erzeugen und man kann damit evtl Fehler im Compiler übergehen. Einen Fehler mit dem Dual Relay können wir nicht reproduzieren. Welche FW Version nutzt du denn?

@ArcaneDraconum: Du hast vermutlich recht, wir hatten zwischenzeitlich Probleme mit neueren Compilerversionen. Wir mussten ein paar NOPs einbauen um einen Compilerfehler zu verhindern der vermutlich dein Verhalten erklären kann: https://github.com/Tinkerforge/io4-bricklet/commit/5585f0c94263a4bd4b329f2f50a33670bf330afc Sprich: Vermutlich war die IO4 1.1.1 Firmware für eine Zeitlang ohne die NOPs auf dem Server und danach mit. Da war aber keine Boshaftigkeit unsererseits beteiligt. Ich hab gerade einfach die Versionsnummer um eins erhöht und es nochmal hochgeladen: https://github.com/Tinkerforge/io4-bricklet/commit/e2cffae8f6d244a3f0faa85f28314f5e08d9d279