Unterstützung von i2c clock stretching beim TXT controller?

Hier habt Ihr die Möglichkeit direkt mit dem fischertechnik Team in Kontakt zu treten
Here you have the Possibility to get in direct contact with the fischertechnik-Team

Moderator: fischertechnik Mitarbeiter

Forumsregeln
Bitte beachte die Forumsregeln!

In dieser Unterkategorie können nur fischertechnik-Mitarbeiter und Moderatoren antworten!
Antworten
hatch
Beiträge: 5
Registriert: 12 Jan 2016, 22:47

Unterstützung von i2c clock stretching beim TXT controller?

Beitrag von hatch » 23 Jan 2016, 22:47

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

Markus Burkhardt
Beiträge: 171
Registriert: 12 Jan 2016, 09:13

Re: Unterstützung von i2c clock stretching beim TXT controll

Beitrag von Markus Burkhardt » 25 Jan 2016, 11:23

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

Rei Vilo
Beiträge: 93
Registriert: 19 Dez 2015, 15:39

Re: Unterstützung von i2c clock stretching beim TXT controll

Beitrag von Rei Vilo » 27 Jan 2016, 14:13

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.

Markus Burkhardt
Beiträge: 171
Registriert: 12 Jan 2016, 09:13

Re: Unterstützung von i2c clock stretching beim TXT controll

Beitrag von Markus Burkhardt » 27 Jan 2016, 15:30

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

Antworten