Jump to content

IO4 verhindert Start


Recommended Posts

@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

Link zu diesem Kommentar
Share on other sites

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.

Link zu diesem Kommentar
Share on other sites

@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.  ;D

 

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

Link zu diesem Kommentar
Share on other sites

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.

Link zu diesem Kommentar
Share on other sites

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.

Link zu diesem Kommentar
Share on other sites

@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.

 

 

Link zu diesem Kommentar
Share on other sites

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 ;D. 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.

Link zu diesem Kommentar
Share on other sites

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 ;D Und autom.Update oder verselbstständige, eigenmächtige Betriebssysteme oder Software sind mir ein Graus...
Link zu diesem Kommentar
Share on other sites

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.

Link zu diesem Kommentar
Share on other sites

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...

Link zu diesem Kommentar
Share on other sites

@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 :D

 

@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 :D

Link zu diesem Kommentar
Share on other sites

Gast
This topic is now closed to further replies.
×
×
  • Neu erstellen...