i2c - Busproblem / Doppelbelegung von Adressen

[Philipp S. (phibedy)]

Heyho,
lange ist es her, dass ich mich mit Elektronik und in diesem Forum 
gespielt habe, nun ist es mal wieder so weit :)

Zu meinem Problem:
Board: Radxa Rock (Pro), ich teste es auf einem "nicht Pro", es soll 
später auf einem Pro laufen.
http://radxa.com/Rock/specification

Sensor: Beschleunigungs- und Magnetfeldsensor
http://www.pololu.com/product/2468/resources
Am Arduino läuft der Sensor wie er sollte.

Für i2cdetect -y (0 bis 4) bekomme ich diese Ausgabe

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
30: -- -- -- -- -- -- -- -- 38 39 3a 3b 3c 3d 3e 3f 
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
70: 70 71 72 73 74 75 76 77

1. Frage:
Bei Busnr. 1 und 2 Sind UU in der 50: Zeile enthalten, dies bedeutet, 
dass die Addressen momentan benutzt werden? Also zur Zeit der Anfrage? 
Mich wundert es, dass die UU immer an der gleichen Stelle auftreten und 
nie unterbrochen sind.

2. Frage:
Für

i2cdetect -y -r (0 bis 4)

Bekomme ich eine leere Liste, wenn ich jedoch den Sensor abstecke und 
wieder anschließe bekomme ich entweder bei der 36 oder bei der 76 (nicht 
sicher ob es die 76 war - habe den Sensor gerade nicht zur Hand)
den Wert angezeigt. Allerdings wenn ich

i2cdetect -y -r (0 bis 4)

 erneut aufrufe ist der Wert wieder "NULL".
2.1 Wie kann man sich so ein Verhalten erklären?
2.2 Bedeutet das, dass ich aus keiner intern angeschlossenen "Einheit" 
Werte lesen kann?

3. Frage:
Für

i2cdetect -y -q (0 bis 4)

Erhalte ich eine komplett gefüllte Liste, keine "--". Das würde 
bedeuten, dass ich mit der Methode an jeder Adresse ein Bauteil 
"beschreiben" konnte und somit an jeder Stelle eins ist und das Board 
voll ist obwohl nichts angesteckt ist?

4.Frage:
Welcher der drei Listen kann ich jetzt glauben bzw. herausfinden ob der 
Sensor erkannt wird?

5. Frage:
Mit dem Sensor soll ein Kameragestütztes Bewegungsprofil eines 
Quadrocopters erstellt werden, ist der Sensor dafür überhaupt geeignet?
Ich wollte ihn mit 1kHz auswerten.
Der Sensor lag noch rum, weswegen ich es einfach mal mit ihm 
ausprobieren wollte :)
Falls ich dazu einen anderen Sensor brauche, was wäre das für einer?

Danke schonmal für die Hilfe

liebe Grüße
Philipp

ps: Ich habe die Frage bereits auf Stackexchange gestellt, allerdings 
ohne Erfolg. Der Vollständigkeithalber hier der Link:
http://electronics.stackexchange.com/questions/139378/accelerometer-gyrometer-for-radxa-board-i2c-configurable-addresses-vs-spi

[chris (Gast)]

Warscheinlich ist der Bus zu schnell. Man sollte den Bus auf 50khz 
drosseln,
eventuell auch auf 10khz. Auch sollte Pin 4 und 5 des Sensors 
kurzgeschlossen sein, angenommen Vin ist 3.3V.
Oder man loetet auf dem Board rum.

[nicht"Gast" (Gast)]

Na ja,

das UU bedeutet erst mal, dass die Adresse bereicht anderweitig benutzt 
wird. Da kann sich auch ein Treiber drauf geklemmt haben.


Grüße,

[Philipp S. (phibedy)]

nicht"Gast" schrieb:
> Na ja,
>
> das UU bedeutet erst mal, dass die Adresse bereicht anderweitig benutzt
> wird. Da kann sich auch ein Treiber drauf geklemmt haben.
>
>
> Grüße,

Danke :)

chris schrieb:
> Warscheinlich ist der Bus zu schnell. Man sollte den Bus auf 50khz
> drosseln,
> eventuell auch auf 10khz. Auch sollte Pin 4 und 5 des Sensors
> kurzgeschlossen sein, angenommen Vin ist 3.3V.
> Oder man loetet auf dem Board rum.

Der Sensor unterstützt 100kHz und 400kHz,
auf dem Arduino läuft er mit 400 kHz,
Vin ist an 5V angeschlossen, Gnd and GND, SCA und SDA jeweils auch an 
den richtigen. Warum sollte man die kurzschließen?

Danke für die Hilfe :)

[chris (Gast)]

Normalerweise heißt cortex a9 3.3v.
Habe auch dazugeschrieben "angenommen vin ist 3.3v".
10k pull up und 3.3v kann keine 400k, zumindest nicht zuverlässig.
Wenn vin 3.3 v ist, mit dem ldo sind es danach noch angenommene 2.7v . 
dann wird es noch schlimmer.
Deshalb mein Hinweis mit dem Verbinden von vdd und vin, aber immer nur 
wenn vin 3.3v ist.
Verbessern konnte man es wenn man noch weitere 10k als pull up 
anschliesst . Haupt Verbesserung sollte aber die Reduzierung der 
Geschwindigkeit liefern. Sollte aber der i2c Port nicht 5v tolerant sein 
und die Sensorplatine wurde mit 5v betrieben könnte es auch denkbar sein 
dass die Pintreiber dadurch beeinflusst wurden.

[Paul F. (zwanni)]

Ich arbeite ebenfalls mit dem Rock Pro und habe mir aus mir nicht 
erfindlichen Gründen schon einmal den Bus zerstört, deshalb Vorsicht. 
Auf keinen Fall mit 5V betreiben, der Rock hat 3.3V Logik. Da auf dem 
Extension Header 5V ausgegeben werden ist das der leicht zu machenste 
Fehler. Die 3.3V musst du dir selbst erzeugen, oder mit Pegelumsetzer 
arbeiten.
Du schreibst immer "(0 bis 4)", der verwendbare I2C ist Bus 0 und der 
ist sonst nicht in Benutzung. Auf den anderen I2C-Bussen sind 
verschiedene "Geräte" aktiv.

i2cdetect -y -r 0

ist der richtige Befehl um Ergebnisse zu bekommen.

Ich habe schon mehrere Maxim chips sowie PCF8574 getestet und die laufen 
ohne Probleme. Warum der Bus bei meinem ersten Rock kaputt ging ist mir 
bis heute unklar. Ich habe weder irgendwann 5V drangehabt noch sonst 
einen Kurzschluss produziert. Kann mir nur vorstellen das ich mal die 
Spannung vor dem I2C abgezogen habe und der Chip sich dann Strom über 
die I2C Leitungen gezogen hat.

[Philipp S. (phibedy)]

Paul F. schrieb:
> Du schreibst immer "(0 bis 4)", der verwendbare I2C ist Bus 0 und der
> ist sonst nicht in Benutzung. Auf den anderen I2C-Bussen sind
> verschiedene "Geräte" aktiv.

Damit meinte ich, dass ich den Befehl mit 0,1,2,3 und 4 ausgeführt habe.
Laut Datenblatt sollte der Bus variieren und somit weiss ich nicht 
welcher er seien sollte, da die Busse bei jedem boot neu "gesetzt" 
werden oder täusche ich mich da?

Bei -r steht bei in der docu "not reccommended"
http://www.lm-sensors.org/wiki/man/i2cdetect

liebe Grüße

[Paul F. (zwanni)]

Der Radxa hat I2C Bus 0-4 das ist soweit korrekt. Diese sind fix und nur 
I2C 0 ist auf dem Extension Header abgreifbar. Du arbeitest also nur mit 
Bus 0. Daran ändert sich nichts. Bei den anderen kannst du lediglich 
schauen was für Hardware dort angeschlossen ist.

Bei deinem Modul gibt es einen Pin SA0 mit dem du die Addresse verändern 
kannst. Da du sagst das es mit dem Arduino geht gehe ich davon aus, dass 
du daran nichts ändern musst.

Wie schon geschrieben musst du mit "i2cdetect -y -r 0" scannen. Wenn 
deine Hardware noch funktioniert und richtig angeschlossen ist, wirst du 
genau eine Addresse angezeigt bekommen. Die ist ebenso immer gleich 
solang du sie nicht am Modul änderst.

Edit:
Ich korrigiere mich, dass Modul beinhaltet 2 getrennte Sensoren mit 
unterschiedlichen Addressen, also müsstest du 2 Addressen sehen und zwar 
0x6B und 0x1D.

[Philipp S. (phibedy)]

Super danke :)
Funktioniert jetzt soweit