Ich möchte nochmal folgendes i2c-Problem in Erinnerung rufen: Fehler im RoboPro I2C-Schreib-Element
Ich hatte erhofft, dass dieses Problem mit der Überarbeitung der i2c-Funktionen für die 4.2.3 Firmware gelöst wird. Auf dem TX ist allerdings der i2c-Schreiben-Befehl im Modus "16bit LSB zuerst" auch mit RoboPro 4.2.3 fehlerhaft. Auf dem TXT tritt das Problem nicht auf.
Zudem wurde mit der RoboPro 4.2.3 folgende TXT-spezifische Einschränkung auch für den TX eingeführt:
Dies hat zur Folge, dass eine ganze Reihe von Treibern und Applikationen, z.B. alle RoboPro Programme für die Pixy CMU 5 Kamera, mit der 4.2.3 Version nicht mehr funktionieren. Diese Applikationen lesen kontinuierlich Daten im "Keep Open"-Mode und analysieren diese gleichzeitig. Das ist mit obiger Einschränkung nicht mehr möglich. Man muss nun für alle Lese-Operationen die "Keep Open"-Funktion deaktivieren, was die bislang schon geringe Übertragungsrate von maximal fünf 16bit-Worten pro Millisekunde beim TX weiter reduziert.aus ReleaseNotes.txt
- ROBOPro/TXT: Support for I2C with TXT (download and online)
Attention: cause of restrictions of the Linux drivers, there are restrictions on how "Keep Open" can be used with I2C.
Keep Open may be used for a number of writes followed by a number of reads in a direct program line without branches.
All other uses of Keep Open result in an error.
Auch der Versuch obige Einschränkung durch Einführung eines i2c-Lese-Puffers, der auf einem eigenen Thread mit einer Sequenz von "Keep Open"-Lesebefehlen gefüllt wird, zu umgehen, gestaltet sich schwierig. Es sind nämlich nicht nur Verzweigungen zwischen den Lesebefehlen verboten, sondern auch jeglicher Befehl, z.B. zum Inkrementieren der Lese-Puffer-Position, zwischen den "Keep Open"-Lese-Befehlen führt zum Fehler. Die Lese-Befehle müssen direkt aufeinander folgen.
Es wäre klasse, wenn diese Einschränkung des i2c-Moduls mit der nächsten RoboPro-Version behoben werden könnte, zumindest für den TX-Controller.
Beste Grüße,
Helmut
