¿Es posible la frecuencia mixta I2C?

Question

Supongamos que tenemos una I de 400 kHz 2 C. Hay un maestro y un montón de dispositivos esclavos. Nos gustaría introducir un dispositivo esclavo más, pero desgraciadamente sólo va a 100 kHz .

Claramente, las opciones de diseño sólidas son:

• Sólo hay que hacer funcionar ese bus a 100 kHz
• utilizar buses separados para los periféricos de 400 kHz y 100 kHz

Pero la pregunta es sólo sobre un hack: ¿qué pasa si usamos un bus, y dirigimos los dispositivos de 400 kHz a 400 kHz, y cambiamos el bus a 100 kHz cuando hablamos con el esclavo de 100 kHz?

O podría el esclavo más lento comportarse mal en respuesta al hash de 400 kHz que ve en la I 2 C porque piensa erróneamente que se está dirigiendo a él?

¿Podemos confiar en que los dispositivos de 100 kHz sigan siendo capaces de procesar 400 kHz I 2 C lo suficientemente bien como para ignorar de forma fiable los mensajes dirigidos a otros esclavos?

Answer 1

Otras opciones. En lugar de tener dos buses, se podría utilizar simplemente una línea extra (más fácil con un software/bitbanged I 2 C). Una línea de reloj separada, o una línea de datos separada. O utilice una línea I 2 C o I 2 C para poner ese único chip de 100MHz en su propio segmento, sin tener que cambiar nada más.

O simplemente pruébalo en un solo bus. Es muy posible que el chip de 100kHz afecte a la línea. Podría leer cada 4 bits y terminar pensando que ha sido direccionado. Pero tendria que ver una condicion de inicio valida, y entonces leer cada 4 bits de los siguientes 32 bits como su direccion exacta, entonces tendria que intentar leer el siguiente par de bytes como informacion valida para escribir en sus registros, o intentar sincronizar los datos. No creo que sea una situación demasiado probable. La mejor opción es simplemente conectarlo en un circuito de prueba y comprobarlo.

Dos cosas a tener en cuenta, si se trata de un circuito único, o sólo se hacen unos pocos, es bastante fácil arriesgarse, o cambiarlo. Si se trata de un artículo producido en masa, es posible que solo quieras tener el segundo bus. La otra, es que tienes que considerar que el chip de 100kHz fue simplemente producido a la I 2 C, y es muy posible que soporte velocidades de reloj más altas. Sólo que no se probó con la especificación de 400kHz de mayor velocidad.

Answer 2

Como sugieres, hacerlo no es una buena práctica de ingeniería. Mientras que algunos dispositivos ignoran el tráfico que no pueden recibir (submuestreo), otros dispositivos podrían saturar el bus con tramas erróneas.

Por lo tanto, la respuesta que busca depende de las características específicas de su aplicación, como por ejemplo

• longitud de sus conexiones I2C
• valor de las resistencias pull-up
• compatibilidad de dispositivos

Por supuesto, es difícil predecir lo que ocurrirá con un dispositivo que funcione fuera de sus especificaciones dentro de unos años.

Otra opción es pasar una línea de apagado a los dispositivos lentos o pasar la línea de reloj (siempre que no puedan generar señal de reloj) a través de una puerta AND.

Answer 3

No hay garantía de que el dispositivo de 100kHz no se comporte mal cuando se expone al tráfico de 400kHz - cualquier cosa, desde NACKs hasta cuelgues del bus son posibles.

Deberías hacer funcionar todo el bus a 100kHz o tener un bus separado de baja velocidad para tu periférico lento.

Answer 4

Otra opción, si no tiene un bus I2C adicional que salga de su maestro, es utilizar un interruptor I2C, como el PCA9543A/43B . Ponga los esclavos de 400kHz en una rama y los de 100kHz en la otra y conmútelos según sea necesario.

Answer 5

El diseño del bus I2C es tal que -

1. cuando se produce un flanco descendente en SCL, que puede hacer que un dispositivo esclavo afirme inmediatamente SDA, sin ningún retardo mínimo particular;
2. el orden relativo de los flancos ascendentes y descendentes es de vital importancia.

Debido a la diferencia en la fuerza del driver y la capacitancia de la línea, sería teóricamente posible que un dispositivo respondiera a un flanco de caída algo lento en SCL conduciendo SDA tan rápido que otro dispositivo viera caer SDA primero.

Podría haber sido posible definir múltiples umbrales lógicos en SCL, y especificar que para que un flanco descendente en SCL se considere que viene después de un flanco en SDA, todavía debe estar por encima de 2/3 VDD cuando se detecta el flanco en SDA, pero un dispositivo no puede afirmar SDA en respuesta a un flanco descendente en SCL hasta que haya caído por debajo de 1/3 VDD, pero la especificación no está escrita en tales términos.

En cambio, los dispositivos que ven los flancos descendentes casi simultáneos en SDA y SCL generalmente considerarán que el flanco en SCL ha ocurrido primero a menos que sea sustancialmente precedido por el flanco en SDA. Algunas implementaciones de I2C manejan esto sincronizando SCL y SDA a algún reloj externo y requiriendo que un flanco descendente de SDA sea observado dos períodos antes que el de SCL para ser considerado como que ha llegado primero. Si la velocidad de las operaciones en SCL y SDA es demasiado rápida en relación con el reloj de sincronización, los dispositivos pueden percibir secuencias arbitrarias de señales altas y bajas en SCL y SDA; si una de esas secuencias parece dirigirse al dispositivo lento, puede reaccionar en consecuencia, aplastando cualquier otra comunicación que pueda estar en marcha.

No hay ninguna razón en particular para que los dispositivos en un bus I2C tengan que depender de la sincronización con un reloj del sistema (ser capaz de percibir dos umbrales discretos en SCL sería mejor), pero el hecho es que algunos dispositivos de hecho trabajan de esa manera. Ten en cuenta que incluso si un dispositivo que estuviera limitado a velocidades lentas internamente quisiera coexistir con un bus rápido, probablemente tendría que emplear, como mínimo, el estiramiento del reloj cada vez que ocurriera algo en lo que pudiera estar interesado.

Esto provocaría que algunas comunicaciones se produjeran más lentamente de lo que lo harían de otro modo, pero la degradación de la velocidad probablemente no sería tan grave como la que se requiere con el diseño de reloj sincronizado (la cantidad real por la que el dispositivo lento estira los relojes probablemente no sería tan grave como la cantidad por la que el reloj debe ser ralentizado para evitar los fallos del peor escenario en las unidades de reloj sincronizadas).