@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

Gilt das ev. auch für die anderen Bricklets ?

Ich habe vor einer Woche einen neuen Master plus DualRelay erhalten, das Bricklet lässt sich aber nur an Port B und D betreiben, ansonsten wird im Viewer nur der Master angezeigt.

Und was sind NOPs ?

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?

Wie kommt man eigentlich darauf, dass das helfen könnte? Ist das ein bekannter Fehler im GCC für diese Plattform?

Na ja direkte Boshaftigkeit will ich nicht unterstellt haben.

 

Es wäre einfach schön, wenn Ihr Veränderungen vornehmt, dies durch einen Versionssprung zu dokumentieren. Dann gäbe es den ganzen Thread nicht, weil ich einfach zuerst die neuere FW eingespielt hätte. Mir ist auch klar, daß i.d.R. dadurch Fehler beseitigt werden. (Auch wenn gleichzeitig neue Funktionen dazu kommen).

Das ist jetzt keine Rüge (eher Rat und Bitte), aber Ihr macht uns und vor allem auch Euch das Leben dadurch leichter.

Einen Fehler mit dem Dual Relay können wir nicht reproduzieren. Welche FW Version nutzt du denn?

Die bei der Bestellung (16.10.2012) gültige FW auf Master und DualRelay. Die Nummern habe ich jetzt hier nicht. Mittlerweile habe ich den Master auf die 1.4.4 upgegraded, das DualRelay bisher ohne Upgrade.

@NIC: Nunja, so wie ich es sehe: Tritt ein unerwartetes Verhalten auf, sollte man alle beteiligten Bausteine vorsichtshalber neu flashen. Das ist bei den Bricklets ja relativ problemlos, da es ja auch remote bzw. im eingebastelten Zustand geht. Bei den Bricks sieht es aber noch anders aus....

 

@Borg: Hmmmm vielen Dank für den Link. Allerdings.... ich bin Chemiker... wenn ich bei der Firmware so einfach durchsteigen würde, würde ich den Master autark betreiben, ohne PC. Das Gebiet überlasse ich mal locker Euch. 

 

Aber andere Frage. Ein NOP verschafft einem ja auch etwas Zeit. Gibt es da Timingprobleme?

Wie kommt man eigentlich darauf, dass das helfen könnte? Ist das ein bekannter Fehler im GCC für diese Plattform?

 

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.

und bei den Bricklet Ports B und D

D.h. erst übers Upgarde der FW kann ich das DualDisplay an allen Ports benutzen.

Übrigens das mitbestellte AnalogOut zeigt das gleiche Verhalten.

Tritt ein unerwartetes Verhalten auf, sollte man alle beteiligten Bausteine vorsichtshalber neu flashen

Sorry, aber bei frisch bestellter Ware sehe ich das nicht so recht ein. Die Upgrade Orgien von Bricks und Bricklet sind m.E. in letzter Zeit zu häufig.

@Nic:  Im Prinzip stimme ich Dir da zu. Ich finde es manchmal auch etwas lästig. Das Ganze hat aber 2 Haken:

1. Teilweise wurde von den Usern hier eine neue Funktionalität gewünscht. Die kommt halt nur über Updates.

2. Auf dem WiFi-Brick wurde auch hier im Forum ordentlich Druck auf TF ausgeübt. Ich fürchte darunter hat etwas die Qualität gelitten. Gerade im Zusammenspiel mit anderen Extensions hakt es ja immer wieder. Das kann man nur durch ausgiebige Tests umgehen. Die kosten aber Zeit.

Der hier diskutierte Fehler ist mir auch sehr lange nicht aufgefallen, bzw. hat sich nicht ausgewirkt, weil mein Master unter der 1.2.4 gesegelt ist. Durch das WiFi ist ein Update nötig geworden und ab da hat's gehakt.

 

Allerdings neu ausgelieferte Bauteile sollten allerdings (problemlos) funktionieren.

 

 

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.

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 ich neue Funktionalität anfordere, bin für Update-Orgien bereit und helfe gerne mit um das Problem aus der Welt zu schaffen. Aber man könnte als Kunde schon erwarten wenn eine aktuelle Lieferung ins Haus kommt, diese eine Major-Version hat die stabil und lauffähig ist.

Wenn ich unbedingt die neuesten Feature haben möchte, muß ich zwangsläufig upgraden.

Wenn man sich ein neues Handy kauft updatet sich das auch sofort beim ersten einschalten.

So was kenne ich nicht, ich benutze immer noch mein altes Handy und habe damit weniger Stress Und autom.Update oder verselbstständige, eigenmächtige Betriebssysteme oder Software sind mir ein Graus...

diese eine Major-Version hat die stabil und lauffähig ist.

Wenn ich unbedingt die neuesten Feature haben möchte, muß ich zwangsläufig upgraden.

Wenn ich mich richtig erinnere ist auch dieser Gedanke schon bei Tinkerforge auf der grossen ToDo Liste.    Da wird sicherlich eine Loesung geben die Aufwand und Nutzen in Einklang bringen wird. Gerade bei den remote genutzen Stacks ist Stabilitaet wichtig!

 

Und autom.Update oder verselbstständige, eigenmächtige Betriebssysteme oder Software sind mir ein Graus...

Klare Zustimmung!

 

Der Loetkolben.

Bin auch dafür. Habe endlich meinen Raspi erhalten und ein wenig rumgespielt. Dazu meinen Testaufbau DC Brick, Buzzer und IO4 genommen. Dasselbe Problem, wie Loeti im anderen Thread. Ein paar mal die LED am IO4 an und aus gemacht, dannach war ein Gang zum Raspi notwendig um mal alles zurückzusetzen.

Ich hatte es mal auf das schwache Netzteil geschoben, aber nun ist alles klar. Ich werde wohl erst einmal mein IO4 downgraden...

@Nic: Ein Problem hat TF halt nur dann, wenn sich die stabile Version der FW die auf alle lagernden 4000 Bricklets aufgespielt wurde als fehlerhaft herausstellt. Ein Flashen beim Versenden wird vermutlich auch nicht möglich sein. Am Ende sollte der Bastler sich bewusst sein, dass er Bastelware in den Händen hält (deswegen ja auch Tinkerforge). Mein Handy ist keine Bastelware und ich wäre sehr böse, wenn dieses fehlerhaft geliefert wird

 

@borg: danke für die Erläuterung. Wegen Weihnachten: Also je nachdem wie sehr Weihnachten einen Einfluss auf eure Verkaufszahlen hat würde ich das entweder deutlich vor oder nach Weihnachten machen (mit dem neuen Protokoll), aber nicht währenddessen

Ich bin für nach Weihnachten, dann habt ihr unter dem Weihnachtsbaum noch Zeit für ausgiebige Integrationstests

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

@borg: Mach ich gerne. Wird aber Morgen werden.

So also alles getestet:

Der Raspi hat den Brickd 1.0.11, der DC Brick FW1.1.6, das IO4 (an Port B) 1.1.2.

Und wenn ich das Teil noch so stresse, es bleibt am Ball. Soweit ich es beurteilen kann, habt Ihr das Problem gelöst.

<Es darf geklatscht werden>

na dann... *applaus*

Ich denke der Thread ist nun abgehandelt - ich schliesse ihn wieder. Damit niemand denkt, das Thema sein noch unerledigt.