Fehler im RoboPro I2C-Schreib-Element

[hamlet]

Hallo ft-Team,

Wenn man mit dem TX im Download-Mode ein 16bit Wort versucht zu schreiben, wird eines der beiden Bytes durch 0xff ersetzt.
Beispiel:

• TX-Controller mit RoboPro 4.1.1 und entsprechender FW V1.30
• Empfänger ist eine Pixy CMU-Cam5 (http://cmucam.org/projects/cmucam5/wiki)
• Kleines Hauptprogramm bestehend aus einem 1s-Warte-Element und danach 3 i2c Schreib-Elementen,
  • Adresse 0x14, 16bit Datum 0xfd00, LSB first, keine Unteradresse, Verbindung "Offen lassen"
  • Adresse 0x14, 8bit Datum 0x00, keine Unteradresse, Verbindung "Offen lassen"
  • Adresse 0x14, 8bit Datum 0xfd, keine Unteradresse, Bus freigegeben
• => Auf dem Bus sieht man die 0x14 Adresse, und dann folgende Bytefolge: 0xff, 0xfd, 0x00, 0xfd
• => Das Null Byte aus dem 16bit Wort ist durch 0xff ersetzt worden
• => Workaround: Bytes einzelnd schreiben

Beste Grüße

[hamlet]

Hallo,
noch ein Hinweis für die Fehlersuche:
Das Problem scheint genau dann aufzutreten, wenn man versucht ein 16 bit Wort, bei dem das höchstwertige Bit gesetzt ist, im Modus "16bit LSB zuerst" auf den i2c Bus zu schreiben. Also genau dann, wenn der "little endian" ARM die Byte-Reihenfolge drehen muss. Der Mode "MSB first" scheint OK zu sein.
Beispiel:
0x8000 LSB first --> 0xff 0x80 Autsch!
0x4000 LSB first --> 0x00 0x40 OK
0x8000 MSB first --> 0x80 0x00 OK
Das ist ein ziemlich hinterhältiger Fehler mit hohem Frustpotential für Nachwuchs-Ingenieure/Forscher, die gerade ihr Taschengeld in neue i2c HW investiert haben. Also bitte schnell fixen.
Beste Grüße,
Helmut

[Dirk Haizmann ft]

Hallo Hamlet,

DANKE für den Hinweis. Komische Geschichte

Wir kümmern uns...

ft