Jetzt versuche ich (am liebsten auf möglichst einfache Weise), zunächst einmal die I2C-Kommunikation zwischen dem TXT4 und einem Arduino UNO herzustellen. Für den Test habe ich die I2C-level-shifters, einen Druckknopf und einen Potentiometer auf einer kleinen Experimentierplatine aufgebaut. Die Idee ist nun, in ROBO Pro Coding eine I2C Anfrage zu stellen und z. B. den Potentiometer auszulesen und damit einen Servo anzusteuern.
- IMG_2136.jpeg (1.49 MiB) 76 mal betrachtet
Ich brauche die CRC8-Prüfung und das Unit-Byte in der Anfrage der ursprünglichen I2Cwrapper-Firmware.ino zunächst nicht und versuche, das Hinzufügen von „eigener Hardware“ zur bestehenden I2Cwrapper-Bibliothek (was offenbar über die Precompiler-Direktive „MF_STAGE“ geregelt wird) noch etwas aufzuschieben. Außerdem hatte ich gehofft, dass ich die gesamte State-Machine-Architektur von I2Cwrapper nicht benötigen würde. Deshalb habe ich die (alte) AccelStepperI2C-„Slave“-Firmware auf das Wesentliche reduziert und auf den UNO geladen. Für meine Puffer habe ich eine abgespeckte Version von SimpleBuffer (ohne CRC-Prüfung und Unit-Byte) verwendet.
Bisher bekomme ich meine Versuche jedoch nicht zuverlässig zum Laufen. Ich versuche nun herauszufinden, ob dies daran liegt, dass mein technischer Ansatz vielleicht zu naiv ist. Ich stoße nämlich auf ein vermutlich recht grundlegendes Timing-Problem.
Das Problem ist nun, dass in dem Moment, in dem die Werte (der Potentiometerwert) der Anfrage zurückgefordert werden, diese noch nicht verfügbar sind. Dadurch hinkt der bufferOut also immer eine Anfrage des TXT4 hinterher. Die angeforderten Werte erscheinen zu spät im bufferOut und bleiben dort bis zur nächsten Anfrage stehen. Dies liegt daran, dass das requestEvent des TXT4 bereits eintrifft, bevor in der Hauptschleife der Befehl interpretiert, der Potentiometer ausgelesen und der zurückzugebende Wert (als zwei Bytes) in den bufferOut geschrieben wurde.
Im Idealfall sollte der TXT4 diesen Rückgabewert ignorieren und den Wert erneut abfragen? Ich sehe, dass der I2C-Wrapper über eine Funktion „autoAdjustI2Cdelay“ verfügt und einen „tainted“-Status für den „bufferOut“ usw. hat. Meine konkrete Frage lautet nun: Ist das alles notwendig, oder wurde bereits getestet, ein eigenes „Target“ (vorzugsweise ein Arduino UNO) über I2C vom TXT4 aus abzufragen? Oder wie lässt sich der bestehende I2C-Wrapper hierfür möglichst übersichtlich nutzen?
Vermutlich muss ich dann eine eigene XXX_firmware.h-Datei mit der Befehlsinterpretation dafür erstellen? Ich verstehe jedoch die Funktionsweise und Interpretation der „MF_STAGE“-Precompiler-Direktive hierfür noch nicht gut genug. Außerdem erscheint mir die gesamte Klasse für meine Anwendung überdimensioniert? Ich versuche schließlich, einen Endpunkt/Slave/Target zu erstellen, der ausschließlich vom TXT4 abgefragt werden kann. An diesem „Target“ sind keine anderen Sensoren usw. angeschlossen, die über I2C abgefragt oder angesteuert werden müssen.
Hat jemand (Jan selbst?) eine Idee, wie ich den „Handshake“ vom TXT4 auf I2C-Ebene hinbekomme, wenn die zurückzusendenden Daten nicht sofort (oder offensichtlich zu spät) verfügbar sind?
