I2C EEPROM con dirección no estándar?

4

Por lo tanto, sé que casi todos los IC de EEPROM i2c utilizan 0xAh (o 1010) como los cuatro bits principales de la dirección del esclavo. Actualmente tengo una EEPROM de 16 kbit en mi bus i2c que usa los 3 bits más bajos del esclavo Dirección para direccionamiento de bloque Esto significa que coopta todas las direcciones que comienzan con 0xAh.

Necesito colocar una segunda EEPROM en el mismo bus, pero me cuesta mucho encontrar uno que no entre en conflicto con el chip existente (por razones de diseño, ese chip no puede cambiar). Una EEPROM de menor capacidad está bien, pero no puedo usar ninguno de los innumerables dispositivos de 8 kbit / 4 kbit / 2 kbit que existen porque sus direcciones de esclavos comienzan con 0xAh.

Lo único que pude encontrar fue este chip de NXP, que usa 0x2h como el Los cuatro primeros bits de la dirección del esclavo. Pero no funciona en modo rápido (400 kHz) y solo viene en paquetes DIP o SO, los cuales son demasiado grandes.

¿Alguien sabe de un chip i2c que funciona en modo rápido, viene en un paquete razonable y, lo más importante, usa una dirección de esclavo no que comienza con 1010 / 0xAh? ¡Estaría extremadamente agradecido por cualquier ayuda que me indique la dirección correcta!

    
pregunta llakais

3 respuestas

9

Si bien no fue específicamente la respuesta a su pregunta, en una situación similar en una de las actualizaciones de nuestros productos, utilizamos una solución alternativa: un dispositivo I2C con direcciones idénticas debía agregarse al diseño, pero convenientemente las partes tenían capacidad para chip líneas.

Por lo tanto, el diseño simplemente agregó un CE en uno de los GPIO del controlador. En realidad, agregamos 2, de modo que potencialmente podríamos incluir 2 partes más cuando, inevitablemente, el equipo de software supere el 100% de la capacidad adicional que acabamos de proporcionar. ellos.

    
respondido por el Seemingly So
2

Si puede golpear al maestro I2C y si ninguno de los dispositivos utiliza el protocolo de enlace basado en SCK, podría intercambiar SDA y SCK en algunos de los dispositivos I2C. Es posible que deba verificar su código I2C para asegurarse de que nunca genere ninguna secuencia de eventos en SCK / SDA que un dispositivo con esos pines invertidos pueda interpretar erróneamente como una secuencia de inicio + direccionamiento. Normalmente, esto no debería ser un problema, ya que cada bit "1" registrado por un dispositivo se considerará como una parada y un reinicio por el otro, y la única vez que un dispositivo verá un bit "0" sincronizado es si el otro hace una parada y reinicia. Aún así, existe una posibilidad muy remota (teórica) de que ambos dispositivos puedan entrar de alguna manera en un estado en el que están tratando de hacer valer un SDA que podría bloquear el bus. Si está utilizando un procesador que puede impulsar pines altos con 10 mA, ese peligro podría evitarse al conectar un resistor de 330 ohmios en serie con la conexión "SDA" en al menos un lado del bus (asegurando así que el procesador pueda funcionar el otro lado, lo que causaría que cualquier dispositivo que mantuviera un nivel bajo de SDA lo liberara, permitiendo así que el otro lado esté sincronizado).

    
respondido por el supercat
0

Como el PCF85103 (256 * 8bit EEPROM con una dirección no estándar 0010XXX en lugar del habitual 1010xxx) se excluye debido a la velocidad, la única solución restante puede ser utilizar un multiplexor (PCA9548, PCA9546, PCA9544 / 45 , PCA9540, PCA9542 / 43).

    
respondido por el Horst

Lea otras preguntas en las etiquetas