I2C-Kommunikationsgeschwindigkeit über Sensoren hinweg

Ich bin neugierig, wie schnell ich zwischen mehreren Sensoren kommunizieren kann. Ich habe ein Board mit einem digitalen Beschleunigungsmesser adxl345 und einem 3-Achsen-MEMS-Kreisel itg3200 auf I2C. Ich versuche, eine IMU zu bauen, die eine schnelle Abfrage beider Sensoren erfordert. Je schneller ich versuche abzufragen, desto mehr Fehlercodes erhalte ich. Wie kann ich die optimale Verzögerung berechnen, die für eine gleichzeitige Kommunikation erforderlich ist? Wie schnell kann I2C wirklich zwischen mehreren Sensoren kommunizieren?

PS. Ich bin auf einem Atmega128- Chip mit 16 MHz.

Was meinen Sie mit schneller : höherer I2C-Takt oder ein kürzeres Intervall zwischen den Abfragen? Und welche Art von Fehlern erhalten Sie, sind es Fehlercodes von den Geräten oder I2C-Kommunikationsfehler?
Sie sind I2C-Fehlercodes. Ja, ich interessiere mich für den kürzesten Abstand zwischen den Umfragen.

Antworten (1)

ICH 2 C ist ein getaktetes serielles Protokoll, was im Allgemeinen bedeutet, dass es sehr wenig gibt, was die Geschwindigkeit elektrisch begrenzt. Am meisten ICH 2 C Busse laufen mit 100 kHz oder 400 kHz, was die Fähigkeit der meisten IMUs zur Datenausgabe bei weitem übertrifft.

Zum Beispiel war ich in einem Robotik-Team, das eine Memsense-nIMU verwendete , und wenn Sie sich das Datenblatt ansehen, steht dort, dass die Bandbreite 50 Hz beträgt und 34 Bytes in einem Paket ausgibt. Damit könnte man theoretisch bis zu hochziehen 50 34 8 = 13 , 600 Bits pro Sekunde oder 13,6 Kbps. Der Chip, mit dem wir liefen, konnte bis zu 400 kHz laufen, sodass er einige davon auf dem Bus bei maximalem Datendurchsatz verarbeiten konnte.

Wenn Sie sich das Datenblatt für den von Ihnen bereitgestellten atmega128 ansehen, heißt es, dass die "TWI" - oder Zweidrahtschnittstelle auf 400 kHz begrenzt ist. Das Wissen um die ICH 2 C Protokoll sind dies 2 Takte für die Startbedingung, 1 Takt für die Stoppbedingung und 9 Takte für die Adresse und 9 Takte pro Byte. Wenn ich also die nIMU verwende, auf die ich zuvor verwiesen habe, ergibt dies eine virtuelle 34 B j T e S 9 C l Ö C k S P e R B j T e + 9 A D D R e S S C l Ö C k S + 2 S T A R T B ich T + 1 S T Ö P B ich T = 318 Uhren pro Paket. Dies bedeutet, dass es keine Begrenzung der Abtastrate gab, konnten wir lesen 400 , 000 / 318 = 1257 Pakete pro Sekunde. Da wir durch die Abtastung auf 50 Pakete pro Sekunde begrenzt sind, könnten wir stattdessen 25 IMUs haben, die Daten senden.

Wenn Sie sich das ITG-Datenblatt ansehen, müssen Sie etwas rechnen, um die maximale Abtastrate genau zu berechnen, aber ich denke, 125 Hz sieht nach einer guten Basislinie aus (siehe Abschnitt 8.2). Es gibt 3 16-Bit-Zahlen aus, was 48 Bits pro Abtastung ergibt. 48 125 = 6 , 000 Bits pro Sekunde. Auch im Bereich der 400 kHz haben Sie Zugriff. Mit dem adxl345 sieht es so aus, als ob die maximale Datenausgaberate 3.200 Bit pro Sekunde beträgt (glaube ich?).

So wie es aussieht, beträgt der kombinierte maximale Durchsatz der beiden von Ihnen ausgewählten Geräte 9.200 Bit pro Sekunde, und der atmega128 hat einen Durchsatz von ~ 400.000 Bit pro Sekunde. Ich denke nicht, dass Sie sich über die Fähigkeit Sorgen machen müssen ICH 2 C das System ins Stocken zu bringen.

Hübsch! Ich habe ähnliche Berechnungen durchgeführt, aber als ich beide Sensoren im Abstand von weniger als 5 ms abgefragt habe, habe ich angefangen, I2C-Statuscodefehler zu erhalten. Irgendwelche Ideen, warum das so war? 5 ms sollten ausreichend Zeit für beide Transaktionen sein.
Sie sollten also den INT-Pin auf Ihrem ITG verwenden, wenn Sie dies nicht bereits tun. Sehen Sie sich Abschnitt 8.4 an und richten Sie ihn so ein, dass RAW_RDY_EN eingestellt ist. Wenn Sie häufiger nach Daten fragen, wenn dieser Pin aktiv wird, erhalten Sie Fehler. Wenn dieser Interrupt weniger häufig auftritt, als Sie erwarten, überprüfen Sie die anderen Konfigurationswerte für das Gerät, es gibt viele verschiedene Dinge (siehe Abschnitt 8.2). Es gibt etwas Ähnliches (INT1 und INT2) für adxl345, das Sie herausfinden und verwenden sollten. Sie sollten nicht in regelmäßigen Abständen pollen, nutzen Sie die bereitgestellten Funktionen Ihres Chips!