I2C EEPROM mit Nicht-Standard-Adresse? [Duplikat]

Ich weiß also, dass fast alle I2C-EEPROM-ICs 0xAh (oder 1010) als die obersten vier Bits der Slave-Adresse verwenden. Ich habe derzeit ein 16-kbit-EEPROM auf meinem I2C-Bus, das die unteren 3 Bits der Slave-Adresse für die Blockadressierung verwendet. Dies bedeutet, dass alle Adressen, die mit 0xAh beginnen, kooptiert werden.

Ich muss ein zweites EEPROM auf denselben Bus setzen, aber es fällt mir äußerst schwer, eines zu finden, das nicht mit dem vorhandenen Chip kollidiert (aus Designgründen kann sich dieser Chip nicht ändern). Ein EEPROM mit kleinerer Kapazität ist in Ordnung, aber ich kann keines der unzähligen 8-kbit/4-kbit/2-kbit-Geräte verwenden, da ihre Slave-Adressen alle mit 0xAh beginnen.

Das einzige, was ich finden konnte, war dieser Chip von NXP, der 0x2h als die obersten vier Bits der Slave-Adresse verwendet. Aber es funktioniert nicht im schnellen Modus (400 kHz) und kommt nur in DIP- oder SO-Paketen, die beide viel zu groß sind.

Gibt es einen I2C-Chip, der im schnellen Modus arbeitet, in einem vernünftigen Paket geliefert wird und vor allem eine Slave-Adresse verwendet, die nicht mit 1010/0xAh beginnt?

Dies ist auch off-topic, da nach einer Empfehlung für ein bestimmtes Produkt gefragt wird.

Antworten (3)

Obwohl dies nicht speziell die Antwort auf Ihre Frage war, haben wir in einer ähnlichen Situation bei einem unserer Produkt-Upgrades eine Problemumgehung verwendet: Ein identisch adressiertes I2C-Gerät musste zum Design hinzugefügt werden, aber praktischerweise hatten die Teile Chip-Enable-Leitungen.

Also fügte das Design einfach ein CE von einem der Controller-GPIOs hinzu - eigentlich haben wir 2 hinzugefügt, damit wir möglicherweise zwei weitere Teile einbauen könnten, wenn das Softwareteam unweigerlich die zusätzliche 100%-Kapazität, die wir ihnen gerade bereitgestellt haben, überwächst.

Danke, das ist eine gute Idee. Dieser Chip hat einen Schreibschutz, aber leider keine Chipfreigabe. Ich könnte also mit dieser Methode schreiben, dass es richtig funktioniert, aber lesen wäre immer noch ein Durcheinander.
@SeeminglySo +1 für "Umgehung des Problems".
@llakais Ähnlich wie bei der vorgeschlagenen Antwort kann die SCL (per Hardware oder im Code) so gesteuert werden, dass jeweils nur während des Schreibens ein Chip getaktet wird? Irgendwelche anderen I2C-Geräte am Bus außer den EEPROMs?
@ExcitingProjects Leider sind noch andere Geräte am Bus, aber danke für die Idee.

Wenn Sie den I2C-Master bitbangen können und keines der Geräte SCK-basiertes Handshaking verwendet, können Sie SDA und SCK auf einigen der I2C-Geräte austauschen. Möglicherweise müssen Sie Ihren I2C-Code überprüfen, um sicherzustellen, dass er niemals Ereignissequenzen auf SCK/SDA generiert, die ein Gerät mit vertauschten Pins fälschlicherweise als Start- und Adressierungssequenz interpretieren könnte. Normalerweise sollte das kein Problem sein, da jedes "1"-Bit, das von oder zu einem Gerät getaktet wird, vom anderen als Stopp und Neustart angesehen wird und das einzige Mal, dass ein Gerät jemals ein "0"-Bit eingetaktet sieht ist, wenn der andere einen Stopp und Neustart macht. Dennoch besteht eine sehr entfernte (theoretische) Möglichkeit, dass beide Geräte irgendwie in einen Zustand geraten könnten, in dem sie versuchen, SDA geltend zu machen, was den Bus blockieren könnte. Wenn Sie einen Prozessor verwenden, der Pins mit 10 mA hoch treiben kann,

Da der PCF85103 (256*8bit EEPROM mit einer Nicht-Standard-Adresse 0010XXX statt der üblichen 1010xxx) aufgrund der Geschwindigkeit ausscheidet, bleibt vielleicht nur die Verwendung eines Multiplexers (PCA9548, PCA9546, PCA9544/45, PCA9540, PCA9542/43).