fischertechnik community forum

Hallo,

ich würde gerne einen bestimmten Sensor über i2c am Txt betreiben (bno055). Dazu möchte ich den Txt per Code, also außerhalb von RoboPro programmieren. Dieser Sensor reagiert allerdings sehr empfindlich darauf, wenn der i2c Master kein clock stretching unterstützt und kann dadurch kaputt gehen. Dementsprechend ist das für mich eine sehr kritische Anforderung.

Unterstützt der Txt Controller i2c clock stretching und falls nicht, gibt es Pläne das über ein zukünftiges Update bereitzustellen?

Grüße,
hatch

Hallo hatch,

clock stretching wird zur Zeit nicht unterstützt und bisher ist auch nicht absehbar, ob es in naher Zukunft implementiert wird. Als Alternative zum BNO055 könntest du den BMX055 in Betracht ziehen, da dieser kein clock stretching benötigt. Die Data Fusion, die im BNO055 integriert ist, könntest du mit einer Library, die Bosch anbietet, selber implementieren.

Viele Grüße
Markus

The tests I've conducted for I²C on the Robotics TXT with a logic analyser show clock stretching works, but with one serious flaw.

• The I²C slave pulls the SCL clock line low, starting clock stretching.
• The I²C master, i.e. Robotics TXT, waits.
• The I²C slave releases the SCL clock line, ending clock stretching.
• The I²C master, i.e. Robotics TXT, takes 1 second (> 955 ms) to resume communication.

I've performed the same tests on the RoboTX. The RoboTX is much faster in resuming the communication, between 64 μs and 344 ms, thus allowing an operational clock stretching.

Now, I don't have access to either the schematics or the drivers, so I don't know the technical explanation for that.

• Is the I²C managed by the Cortex-A8 MPU (i.e. Micro-Processor Unit, running on Linux) or the Cortex-M3 MCU (i.e. Micro-Controller Unit)?
• Is the I²C driver interrupt-based or does it rely on polling?

If the I²C port is managed by the Cortex-A8 MPU, I wouldn't be surprised by the long delay, as Linux isn't a real-time (i.e. time deterministic) operating system. Most modern industrial SoCs (i.e. System on Chip, combining MPU+MCU), have dedicated MCUs or PRUs (i.e. Programmable Realtime Unit) to manage GPIOs and ports.

Hello Rei Vilo,

the I²C bus is managed by the Cortex-A8 and not by the Cortex-M3. It was implemented in this way to minimize the communication between the MCU and the MPU for control purposes. We use the I²C driver of the standard Linux kernel (i2c_dev) in the userspace. I do not know if it works with interrupts or with pollings, but if I get this info, I will let you know.

Best regards,
Markus