Mehrere i2c Teilnehmer mit unterschiedlichen Geschwindigkeiten

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Guten Abend zusammen,

    ich versuche aktuell 2 Sensoren (Adafruit Ccs811, adafruit sht31-d - >i2c Geschwindigkeit 10k) und eine Infrarotkamera (melexis mlx90640->i2c Geschwindigkeit 100k) an einem Raspberry Pi 3b+ am I2c Bus auszulesen. Einzeln angeschlossen kann ich jeden auslesen, aber nicht zusammen.

    Gibt es hierfür eine Lösung?

    Einmal editiert, zuletzt von AlphaBrownie (11. Dezember 2018 um 20:48)

  • Mehrere i2c Teilnehmer mit unterschiedlichen Geschwindigkeiten? Schau mal ob du hier fündig wirst!

  • Ja: Der langsamste Teilnehmer bestimmt die Geschwindigkeit. Iss so.

    Allerdings sollten nach I2C-Standard konforme Chips mindestens 100k können, auch der SHT31. Und eigentlich ist eine Reduzierung auf 10k normalerweise kein Problem, es dauert dann halt länger. Also 10k sollte auf jeden Fall gehen.

    Wie lang sind die Leitungen zu den Modulen? Welche Art Leitungen?

    Wie ist die Betriebsspannung der Module?

    Welche Adressen haben die Module?

    Hast Du ein Oszi, mit dem Du die Signale auf SCL und SDA ansehen kannst?

  • Titel falsch!

    daran liegt es nicht

    1. kann man für die langsamen Teilnehmer die Geschwindigkeit vor Abfrage umstellen, der langsamste bestimmt sonst immer das Tempo, wie meine RTC beim EEPROM schreiben, sonst kann ich auf schnell schalten.

    2. Die Adressen dürfen nicht kollidieren, also einzeln die Adressen testen I2C Scanner und welche mit gleichen Adressen umkonfigurieren oder einen belassen, die anderen entfernen.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Vielen Dank für deine Antwort. Die Adressen sind alle unterschiedlich. Wie kann ich denn in python die Geschwindigkeiten ändern? Dachte die wären fest vorgegeben durch die config Datei im Boot Ordner?

    Wenn ich für die Kamera 10k einstelle bekomme ich keine Bilder mehr. Und der CCS811 läuft nicht mit 100k. Angeschlossen ist das ganze an ein Breadboard, die Länge der Kabel liegt bei ca 15cm. Da müsste ich erst schauen ob ich einen Logikanalyser organisiert bekomme.

    Einmal editiert, zuletzt von AlphaBrownie (11. Dezember 2018 um 21:43)

  • wie meine RTC beim EEPROM schreiben, sonst kann ich auf schnell schalten.

    Ähm nee, das kann funktionieren, muss aber nicht. Wenn der langsame Teilnehmer zu schnell angesteuert wird, kann er trotzdem auf das Signal reagieren. Bestenfalls kommt er beim Lesen ausser Tritt und hängt sich auf, schlechtestensfalls glaubt er sich angesprochen und stört Dir mit seinen Antworten oder einem Clock Stretch die Kommunikation.

    Du musst bedenken, dass die einfachen I2C Bausteine, vor allem die älteren, nicht sonderlich intelligent sind. Da ist das alles mit Flipflops und Schieberegistern gelöst.

    Aber 100k sollten wie gesagt eigentlich alle können, ein Blick ins Datenblatt kann helfen.

  • das kann ich dir nur für den AVR oder Arduino sagen, beim PI nutze ich I2C nicht mehr.

    Aber 100k sollten wie gesagt eigentlich alle können,


    beim Atmel klappt das on the fly, die Clock ist auch schnell genug wie alle meine I2C devices 400kHz nur das EEPROM ist lahm

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Ich dachte noch an eine andere Ursache, die sich aber nach einer Recherche der Datenblätter ausschließt - zusätzliche Pullups an den Modulen, die es den Treibertransistoren erschweren, ein Low-Signal zu erzeugen. Also der Ccs811 hat offenbar keine (siehe Seite 11) und die Kamera auch nicht.

    Allerdings gibt die Spec des Ccs811 eine UNTERE Frequenz von 10kHz an. Typisch sind Werte von 100kHz und das Maximum liegt bei 400kHz. Ich würde den Aufbau mal (zunächst einzeln und dann mit beiden Busteilnehmern) unter 100kHz und 400kHz probieren. Um Spannungsschwankungen/Störungen an den IC's zu vermeiden würde ich 1µ+100nF X7R kurz an den Bausteinen parallel anbinden.

  • Ich dachte noch an eine andere Ursache

    und da ich gerade am ESP32 3,3V arbeite und dem eine RTC angekoppelt habe die auf 5V läuft damit der LiR2032 geladen wird noch Pegelwandler eingebaut, die helfen auch bei schwachen Ports die Pegel bi-dir zu richten. 2x BSS170 o.ä.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Ich würde erstmal mit einem Oszi schauen, welche Taktraten der Raspi wirklich raushaut und wie die Signale aussehen.

    Dabei aufpassen, übliche Tastköpfe mit Leitungskapazitäten um die 150pF verschleifen die Signale schon merklich. Hängt an einer Leitung ein Tastkopf und an der anderen nicht, können die unterschiedlichen Verzögerungen schon zu Fehlern führen.

  • Also ich dachte auch wie schnasseldag daran, ob die PullUps nicht das Problem sind. Nach Analyse der Datenblätter sieht er kein Problem mehr, da in der Peripherie keiner verbaut ist. Mir stellt sich trotzdem die Frage: Wo sind nun die PullUps die ja benötigt werden? Im Raspberry? Die internen sind aber sicher nicht passend!?

    Eine Analyse der Pegel und Flanken mit dem Oszi wäre wohl sehr hilfreich...

    ...wenn Software nicht so hard-ware ;) ...

    Freue mich über jeden like :thumbup:

  • Die internen sind aber sicher nicht passend!?

    Warum sollten die nicht passend sein? Da sind angeblich 1k8 verbaut, das ist schon sehr niedrig, sollte aber noch von jeder Peripherie verkraftbar sein.

    Dazu nochmal 10k extern dazuschalten macht den Kohl auch nicht fett, aber bei mehreren wirds dann eng.

    Ich verbau zwischen 3k3 und 4k7 am Master, oder aktive Pullups wenn es nicht energiesparend sein muss, und fahre damit bisher gut.

  • Servus Fliegenhals,

    Der RPi hat doch zwei i2c Busse, damit könnte man auch jeden Sensor mit seiner bevorzugten Busgeschwindigkeit, separat betreiben.

    der i2c-0 liegt, wenn ich es richtig in Erinnerung habe, auf den Pins ID_SD und ID_SC ...

    Das kann, muss aber nicht funktionieren ( -> ID_SD und ID_SC als GPIO verwenden )

    Zudem: dieser Bus hat imho keine physikalischen pullups verbaut ... da muss man sich wohl selbst drum kümmern.

    cu,

    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!