borg

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.

Wir haben ein paar Schalter/Taster bei uns im Shop. Die kannst du alle zusammen mit dem IO4/IO16 Bricklet benutzen. Dazu musst du natürlich ein Käbelchen an die Schalter löten.

1) One possibility to kind of do this already is to use a Beagle Board or a Raspberry PI or similar. We discussed the possibility to make a "Linux Brick" with the standard 4x4cm size, but i fear that it would be hugely expensive compared to the cheap embedded linux boards now available. 2) In the near future we plan to offer an "on device programming interface", compatible to the arduino API. That means, you can then program the Bricks and Bricklets themself (you can do this already, but there isn't a nice API or documentation yet). 3) Another thing that we discussed already is a visual programming language, that you can use to generate some kind of state machine that can be transferred to and executed on Bricks and Bricklets. This would be very easy to use but only usable for smaller problems. We would very much like to have something like this in the future. Regarding your specific idea: The Brick that would control the other Bricks, would again be some kind of "Linux Brick". A Brick like this would cost us a fortune if we only produce it in our normal quantities (1000pcs). I doubt that people would be willing to pay 10x the amount as they do for a Raspberry PI for this. If we just use the normal Cortex M3 microcontroller, as on the other Bricks, we can also use the Master Brick itself to execute the code (as discussed in 3).

If there is a small PicoITX board on the PC, you could easily use a GSM USB stick. Like this thing: http://www.amazon.com/Sierra-Wireless-Lightning-305-aircard/dp/B0040DX9EW/ref=sr_1_1?ie=UTF8&qid=1350632203&sr=8-1&keywords=gsm+usb

Firmwares: Master Brick 1.4.5 Problem mit der Kombination RS485 + WIFI + Step-Down PS gefixt Download Firmwares: Master Brick

Firmwares: Master Brick 1.4.5 Fix Problem with RS485 + WIFI + Step Down PS combination Download Firmwares: Master Brick