borg

? 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

Hast du überprüft ob die UID passt?

Ah, ich das muss besser dokumentiert sein. der Power Mode wird nicht im EEPROM gespeichert. Beim start wird immer erst der Full Speed Modus verwendet. Dies ist leider notwendig, da es im Low Power Mode beim starten zu Timeouts kommen kann bei der initialen Enumerierung (falls ein großer Stapel verwendet wird). den Power Mode kann man entsprechend natürlich auch im laufenden Betrieb umstellen.

Kannst du die IO-4 Firmware einmal neu flashen?

Ich kann es auch nicht reproduzieren. Ich hab einen Stapel bestehend aus Master Brick mit WIFI Extension und 2x Analog In, 1x Temperature, 1x IO4 (siehe Anhang für FW Versionen). Hab mich auch einmal per Ad Hoc WIFI drauf verbunden, geht auch.

Ups. Ich hatte früh genug ein neues bestellt. Aber da wir heute auf der Elektor Live Messe ausgestellt haben, hab ich es verpennt es rechtzeitig einzuspielen . Hab das gerade schnell nachgeholt.