Ich sehe auf dem Raspi 3 /dev/i2c-0 /dev/i2c-1 und /dev/i2c-10 /dev/i2c-11 0 und 1 sind 2 getrennte Busse. 10 und 11 scheinen mit i2cdetect viel langsamer Ergebnisse zu liefen? Gehören 0 und 10 bzw. 1 und 11 irgendwie zusammen?
Gast
#6626556
Soweit ich den Raspi kenne, hat die CPU nur 2 Hardware I2C Busse: -0 und -1 Siehe auch http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_I2C.html Keine Ahnung, was -10 und -11 sind. Hast du da einen Bitbang-Triber installiert? Auf meinen Raspis sind -10 und -11 jedenfalls nicht.
Gast
#6626566
War das nicht einfach nur ein anderes Pin-Muxing? Also prinzipiell der gleiche I2C Controller aber an anderen Pins?
$ i2cdetect -l i2c-1 i2c bcm2835 (i2c@7e804000) I2C adapter i2c-11 i2c bcm2835 (i2c@7e205000) I2C adapter i2c-0 i2c i2c-11-mux (chan_id 0) I2C adapter i2c-10 i2c i2c-11-mux (chan_id 1) I2C adapter Siehe auch hier: https://www.raspberrypi.org/forums/viewtopic.php?t=141517
Gast
#6626680
Nur nicht so viele Informationen auf einmal! Du nutzt also ein Device Tree Overlay um einen externen I2C Muxer(PCA954x) zu verwenden? Ich kenne die Dinger zwar nicht, aber zeig mal das Overlay. Wenn ich die Beschreibung zu z.B. i2c-mux-idle-disconnect lese:
1 | |
kann ich mir schon vorstellen dass das länger dauert wenn jedesmal auf das Register des PCA geschrieben werden muss.
Hallo, ich als armer Schlucker, der vom Raspberry Pi 4 beherscht wird und nicht umgekehrt: Ich habe das gleiche Problem, obwohl ich nichts davon wissentlich installiert habe. Weder in /boot/config.txt noch sonstwo.
In der /boot/config.txt genügt:
1 |
|
2 |
|
zum Aktivieren von I²C. (Keine Zeile mit "dtoverlay=".) Während beim (alten?) RPi3 davon nur /dev/i2c-1 entsteht, entstehen beim RPi4 zusätzlich die beiden gemultiplexten /dev/i2c-10 und -11. Kann man zwar ignorieren, aber mit aufgeräumt hat das nichts zu tun.
Da die gleiche Frage ohne Antwort: https://www.reddit.com/r/raspberry_pi/comments/svv0cg/how_to_disable_the_i2c_multiplexer/
Dabei ist mein eigentliches Problem nicht das Herumgammeln von zu vielen /dev/i2c* sondern dass beim RPi3 das BSR[1]->TOUT-Register auf 0 steht (= richtig für die Kommunikation mit AVR als I²C-Slave), beim RPi4 nicht (= ClockStretch-Bug).