Kaskadierte i2c-Adressübersetzer?

Ich versuche, viele (~ 80) ToF-Abstandssensoren VL53L0X an einen einzigen i2c-Bus anzuschließen. Sie haben die Standard-i2c-Adresse 0x52, die programmierbar, aber nicht persistent ist. Somit habe ich die Wahl zwischen dem selektiven Ein-/Ausschalten von Sensoren (über GPIO-Erweiterung auf i2c usw.) und dem Neuprogrammieren jeder einzelnen Adresse beim Start oder der Adressen, die direkt in Hardware übersetzt werden. Hier geht es um die zweite Option.

Da wäre der Umsetzer T(etwas wie LTC4316, aber am besten einer ohne Spannungsteiler) immer zwischen Sensor Sund Bus, so, natürlich jeder Umsetzer auf eine andere Adresse eingestellt:

master ---+---+---+---+
          T   T   T   T
          S   S   S   S

Jetzt würde ich gerne weitere identische Module wie dieses hintereinander schalten können, aber um Adresskonflikte zu vermeiden, hätte jedes Modul Nam Anfang einen Übersetzer:

(--  module 1 --)     (--  module 2 --)      (--  module 3 --)

M---+---+---+---+ === M---+---+---+---+  === M---+---+---+---+
    T   T   T   T         T   T   T   T         T   T   T   T
    S   S   S   S         S   S   S   S         S   S   S   S

Modul 1 würde übersetzt werden durch M, Modul 2 durch MM, Modul 3 durch MMMund so weiter, zum Beispiel so (der Einfachheit halber mit Sensoradresse 0, T1 addieren, M4 addieren)

global address        4  5  6  7     8  9 10 11   12 13 14 15
module-level address  0  1  2  3     0  1  2  3    0  1  2  3
sensor address        0  0  0  0     0  0  0  0    0  0  0  0

Ich hätte gerne einen Kommentar, ob dies logisch ein guter Weg ist, ob es elektrisch sinnvoll ist, und vielleicht sogar einen Vorschlag für einen IC ähnlich dem LTC4316, mit Übersetzungsadresse, die durch Hoch-/Tiefziehen der Pins wählbar ist.

Was ist die geplante Kommunikationsgeschwindigkeit für das I2C? Planen Sie, die 400 kHz zu verwenden? Was ist die Mindestkommunikationsgeschwindigkeit, die Sie berücksichtigen werden?
Es sollte geringe Datenmengen übertragen, maximal vielleicht 10 Hz auf jedem Sensor, also maximal ca. 1 kHz Messwerte auf dem gesamten Bus, was einer Datenrate von vielleicht 10 kbps entspricht.

Antworten (1)

Es klingt teuer und ressourcenintensiv, einen Adressübersetzer für jeden Sensor zu haben. Vielleicht könnten Sie stattdessen einen I2C-gesteuerten Analogschalter verwenden und die SCL einfach auf jeden der Sensoren schalten, damit sie beim Trennen keine Befehle sehen.

Beispielsweise ist der Linear Tech LTC1380 ein 8:1 I2C-gesteuerter analoger Mux, der auch deaktiviert werden kann, um keine analoge Verbindung zu haben.

Sie könnten einfach zwei der LTC1380 parallel schalten, um SCL in 16 verschiedene Pfade aufzuteilen, und dann einen weiteren LTC1380 auf jedem der 16 Pfade platzieren, um mit 8 verschiedenen Sensoren auf jedem der 16 Taktpfade zu kommunizieren.

Eine andere Möglichkeit besteht darin, 7 Mux-Kanäle auf jeder Platine zu behalten und einen an die nächste Platine weiterzugeben. Die nächsten Durchgangstafeln hätten ebenfalls 7 an Bord und eine Durchgangstafel. Der ~100-Ohm-Widerstand des Analogschalters würde schließlich Probleme verursachen, aber Sie könnten wahrscheinlich mit 4,7-K-Pullup-Widerständen mit einer Tiefe von 4 Ebenen davonkommen. Nach 4 Leveln gehen dir sowieso die Adressen für die Muxes aus.

Wenn Sie die beiden Methoden kombinieren, könnten Sie auf der obersten Ebene ein 8: 1 haben, das mit 8 3 tiefen Ketten mit jeweils 7 Sensoren spricht, was Ihnen 8 * 21 = 168 Sensoren ergibt.

Um bei der Aufrechterhaltung der Signalqualität zu helfen, könnten Sie vielleicht die analogen Muxes mit dem LTC-4302 kombinieren , der im Grunde eine programmierbare Verbindung zwischen zwei I2C-Bussen ist, die 32 verschiedene Pin-programmierte Adressen haben können. Es hat auch eine Anstiegszeitbeschleunigung, die bei langen Bussen hilfreich sein könnte.

Egal was Sie tun, stellen Sie sicher, dass Sie die kapazitiven Ladespezifikationen von I2C (~400pf) nicht überschreiten. Die Aufteilung der Busse kann dabei helfen.

Danke für die Antwort. Der Preis für Übersetzer spielt keine große Rolle, für mich ist es eine Möglichkeit, die Bedienung zu vereinfachen, die Sensoren erscheinen einfach mit unterschiedlichen Adressen. Wie hoch wäre die Ressourcenintensität? Energieverbrauch?
Wenn es Ihnen nichts ausmacht, für jeden Sensor einen Übersetzer zu verwenden, sollte das, was Sie vorschlagen, funktionieren. Ein „Merkmal“ ist, dass Sie jeden LTC4316 einzeln konfigurieren müssen, um eine andere Adresse in 0x52 zu übersetzen. Das bedeutet für jeden Sensor eine andere Widerstandseinstellung. Der Stromverbrauch ist wahrscheinlich kein Problem, da der LTC4316 nur 2 mA verbraucht. Ich persönlich würde es einfacher finden, den I2C-Bus mit MUXes und/oder dem LTC3402 aufzuteilen und nicht 80 Widerstandskombinationen für die Adressübersetzer herausfinden und alle erforderlichen unterschiedlichen Widerstände zur Stückliste hinzufügen zu müssen.
Sie können das Widerstandsproblem vermeiden, indem Sie eine R-2R-Leiter ( en.wikipedia.org/wiki/Resistor_ladder ) verwenden, die von einem Jumper-Header angesteuert wird, um die Konfigurationsspannung zu erzeugen. Auf diese Weise können Sie die Adresse jedes Sensorpfostenherstellers festlegen. Das würde einen Header und Widerstände für jeden Sensor hinzufügen und Sie müssten jeden Header richtig überbrücken. Sie könnten auch einen Trimmerwiderstand an jedem Übersetzer anbringen und die richtige Spannung einstellen. Ich denke, es ist weniger umständlich, den I2C-Bus aufzuteilen, sodass der Pfad zu jedem Sensor zur Laufzeit einzeln aktiviert werden kann.
Danke, sehr nützliche Vorschläge. Die Idee (sobald wir die Prototypenfunktion usw. überprüft haben) besteht darin, ein bescheidenes Volumen (zig) von hergestellten Leiterplatten zu haben, deshalb finde ich die Idee, dass jedes Modul völlig identisch ist, aber mit unterschiedlichen Adressen, wenn es verkettet ist, so faszinierend. Also machen wir die Widerstandskombinationen nur einmal :) Freut mich, dass Leute wie Sie ihre Erfahrungen und ihr Wissen hier teilen. Beifall!
Kaskadierte i2c-Adressübersetzer?
AntwortenHierDatenschutz-Bestimmungen1y, 0v