borg

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

The question is: Where can we buy apropriate plates that are cheap enough so we can resell them properly priced in our shop ? These Tamiya plates are intendet for modelmaking and modelmaking stuff is always freaking expensive.

Kannst du nochmal mit Master Brick Firmware Version 1.4.4 testen?

Firmwares: Master Brick 1.4.4 Chibi Extension Initialisierungssequenz gefixt Download Firmwares: Master Brick

Firmwares: Master Brick 1.4.4 Fix Chibi Extension initialization sequence Download Firmwares: Master Brick

Wann kannst du die Adresse nicht speichern, wenn die Chibi Extension als zweite Extension im Stack ist? Oder gar nicht? Mit Pinne meinte ich die Kontakte der Platine-zu-Platine Verbinder. Durch den Stack laufen 4 Leitungen pro Extension, also in Summe 8 Leitungen. Jede Extension schließt die ersten 4 Leitungen an und shiftet nach oben hin die letzten 4 Leitungen auf die ersten 4. Nur dadurch können überhaupt 2 Extensions verwendet werden. Dafür muss der Master Brick wissen welche Extension gerade wo ist, dies war früher nicht implementiert und da scheint es bei Chibi bzgl. der Kommunikation mit dem EEPROM noch Fehler zu geben. Gucke ich mir nachher an.

Kannst du das nochmal mit Master Brick Firmware Version 1.4.3 probieren? Ich befürchte der AP Modus wurde nie richtig konfiguriert, weil da eine Verwechselung in den defines war . https://github.com/Tinkerforge/master-brick/commit/2941a7062052e62a0817ad87098c213c0172dba5

Firmwares: Master Brick 1.4.3 Vertauschung von Ad Hoc DHCP und AP Static IP gefixt Download Firmwares: Master Brick

Firmwares: Master Brick 1.4.3 Fix mixup between Ad Hoc DHCP and AP Static IP Download Firmwares: Master Brick

The Temperature Bricklet uses I2C, there is no analog value comming from there. See the datasheet of the TMP102: https://github.com/Tinkerforge/temperature-bricklet/raw/master/datasheets/tmp102.pdf Also: The supply voltage of the Arduino is 5V, the supply voltage of the TMP102 is 3.3V!

Nagut, überredet. Dann halt "Voltage/Current Bricklet" als Name und "Voltage Current Bricklet" als gespeicherten Namen auf dem Bricklet wegen der parsebarkeit .