Die äußere FOR-Schleife ist auskommentiert.
Oder meinst Du die while-Schleife?
Die äußere FOR-Schleife ist auskommentiert.
Oder meinst Du die while-Schleife?
Welche Rolle spielt das jetzt? Der entscheidende Punkt ist, dass die innere for-Schleife mehrfach hintereinander ausgeführt wird, und mir mein obiges Szenario durchaus plausibel erscheint (*). Wenn du dir so sicher bist, dass das nicht sein kann, solltest du das schon genau begründen. Auch deshalb, weil sich aus diesem "genau begründen" neue Anhaltspunkte ergeben könnten.
Und warum zum Teufel weist du diese Möglichkeit gleich zurück und fängst das Diskutieren an, statt es einfach mal auszuprobieren? Wenn es eine funktionierende und eine nicht funktionierende Variante gibt, und es einen konkreten Unterschied zwischen beiden gibt, dann ist dieser Unterschied doch wohl mal einen genaueren Blick wert, und sei es auch nur, um eine weitere mögliche Fehlerquelle sicher auszuschließen.
(*): Ich kenne allerdings deine Sensoren nicht, und habe auch keine Lust mich damit auch noch zu beschäftigen, um zu analysieren, was das Nichtausführen des Code-Teils genau impliziert.
MfG
Stefan
sorry, ich sitze hier im Job und kann es im Moment nicht ausprobieren. Das werde ich heute abend natürlich machen. Meine Absicht war das Thema vorher schon genauer einzukreisen.
Also mein Verständnis des Ablaufes mit der inneren FOR Schleife ist so:
i=0, der erste Sensor wird ausgelesen, Antwort ok, Wert wird auf LCD ausgegeben.
i=1, der zweite Sensor wird ausgelesen, Antwort kann nicht sein, Wert wird nicht auf LCD ausgegeben, Schleife wird abgebrochen, die Sensoren werden nicht neu gestartet und der weitere Code wird ausgeführt.
Mein Verständnis des Codes ohne innere FOR-Schleife ist so:
i=0, der erste Sensor wird ausgelesen, Antwort ok, Wert wird auf LCD ausgegeben.
i=1, der zweite Sensor wird ausgelesen, Antwort ok, Wert wird auf LCD ausgegeben.
i=2, der dritte Sensor wird ausgelesen, Antwort ok, Wert wird auf LCD ausgegeben.
Anschließend wird eine neue Messung der Sensoren mit einem general I2C Kommando an Adresse 0x00 neu gestartet.
Da im Fehlerfall oben schon bei i=1 die Schleife abgebrochen wird, kommt es nicht mehr zum Neustart der Messung.
Und meine Frage wäre dann (wie schon oben), warum du dir so sicher bist, dass es nicht genau deshalb beim Sensorauslesen zum Fehler kommt, weil schon im vorigen Durchlauf die Sensoren eben nicht neu gestartet wurden (weil dort das i2c_start für Sensor 3 (i=2) gescheitert ist).
Apropos: mich würde mal interessieren, wie du das "Schleife wird abgebrochen" genau feststellst/schlussfolgerst. Woher weißt du, dass die Schleife abbricht, und nicht einfach nur das i2c_start fehlschlägt?i=0, der erste Sensor wird ausgelesen, Antwort ok, Wert wird auf LCD ausgegeben.
i=1, der zweite Sensor wird ausgelesen, Antwort kann nicht sein, Wert wird nicht auf LCD ausgegeben, Schleife wird abgebrochen, die Sensoren werden nicht neu gestartet und der weitere Code wird ausgeführt.
MfG
Stefan
Weil es schon beim ersten Ausführen der Schleife auftritt. Dies erkennt man daran, dass nach dem Reset zuerst die Sensoren über I2C general Command an Adresse 0x00 gestartet werden. Danach wird die Schleife das erste Mal ausgeführt, Antwort ist mit 0x0F im erwarteten Bereich, dieser Wert ist auch auf dem LCD zu sehen. Bei i=1 wird der zweite Sensor adressiert, die Antwort ist 0x02 (was nicht erwartet wird, da der US Sensor so dicht gar nicht messen kann), dieser Wert wird auf dem LCD nicht mehr ausgegeben. Als nächstes wird das Sensorboard2 addressiert und ausgelesen. Das ist jedenfalls auf dem I2C Bus und auf dem LCD zu sehen.
Zur Info: Der Logik Analyser wird mit der SDA Leitung auf negative Flanke getriggert und der Baustein wird aus dem Reset losgelassen.
Dass die Schleife abgebrochen wird, merke ich daran, dass gar nicht mehr versucht wird, mit i=2 den 3. Sensor abzufragen. Ein entsprechendes I2C Read Kommando an Adresse 0xE4 (bzw. 0xE5, da es ein read ist) wird vom I2C Master nicht mehr ausgegeben.
Geändert von uffi (18.03.2011 um 14:31 Uhr)
Darf ich daraus schließen, dass du LA-Protokolle von jeweils der kompletten I2C-Kommunikation hast? Poste die bitte mal (auch wenn ich nicht so der I2C-Experte bin). Und baue doch mal ein paar Marker in den Code ein, die dann auch auf dem LA zu sehen sind. Z.B. in der For-Schleife als erstes einen Port-Pin auf High und als letztes wieder auf Low setzen (um zu sehen, ob die Schleife über einen unzulässigen Pfad verlassen wird). Und nach der Schleife den Wert von i ausgeben lassen.
Wenn die Schleife tatsächlich abgebrochen wird, sehe ich nur die Möglichkeit eines Fehlers im I2C-Code oder dass i irgendwo korrumpiert wird.
Ergänzung: oder im LCD-Code natürlich![]()
Geändert von sternst (18.03.2011 um 14:59 Uhr)
MfG
Stefan
o.k. stelle ich am Wochenende ein.
Lesezeichen