¿Es posible la frecuencia mixta I2C?

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

Por lo tanto, la respuesta que está buscando depende de los detalles específicos de su aplicación, tales como:

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

Por supuesto, es difícil predecir qué pasaría con un dispositivo operado fuera de sus especificaciones unos años después.

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

Otra opción, si no tiene un bus I2C adicional que sale de su maestro es usar un conmutador I2C, como el PCA9543A / 43B . Coloque los esclavos de 400 kHz en una rama y los esclavos de 100 kHz en la otra y cámbielo según sea necesario.

No hay garantía de que el dispositivo de 100 kHz no se comporte mal cuando se lo exponga a un tráfico de 400 kHz, es posible cualquier cosa, desde los NACK hasta el bloqueo del bus.

Debes ejecutar todo el bus a 100kHz o tener un bus de baja velocidad separado para tu periférico lento.

Otras opciones. En lugar de tener dos buses, puede usar una línea adicional (Más fácil con un software / bitbanged I ² C). Una línea de reloj separada, o una línea de datos separada. O use un búfer I ² C o I ² C para poner ese único chip de 100MHz en su propio segmento, sin tener que cambiar nada más.

O simplemente pruébelo en un solo bus. Es muy posible que el chip de 100 kHz afecte a la línea. Podría leer cada 4to bit y terminar pensando que ha sido abordado. Pero tendría que ver una condición de inicio válida, y luego leer cada cuarto bit de los siguientes 32 bits como su dirección exacta, entonces tendría que intentar leer el siguiente par de bytes como información válida para escribir en sus registros. , o tratar de registrar los datos. No creo que sea una situación demasiado probable. Lo mejor es cablearlo en un circuito de prueba y comprobarlo.

Dos cosas a tener en cuenta, si se trata de un circuito único, o si solo está haciendo algunas, es bastante fácil arriesgarse o cambiarlo. Si se trata de un artículo producido en masa, es posible que desee tener el segundo bus. La otra, es que debe considerar que el chip de 100 kHz se produjo simplemente con la especificación original I ² C, y es muy posible que admita velocidades de reloj más altas. Simplemente no se probó con la especificación de 400 kHz de velocidad más alta.

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 retraso mínimo en particular;
2. el orden relativo de los flancos ascendentes y descendentes es de importancia crítica.

Debido a la diferencia en la fuerza del conductor y la capacitancia de la línea, sería teóricamente posible que un dispositivo responda a un borde de caída algo lento en SCL al conducir SDA tan rápido que otro dispositivo vea caer primero a SDA.

Podría haber sido posible definir múltiples umbrales lógicos en SCL, y especificar que para que se considere que un flanco descendente en SCL viene después de un borde en SDA, todavía debe estar por encima de 2/3 VDD cuando el borde en SDA se detecta, pero es posible que un dispositivo no haga valer 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 bordes de caída casi simultáneos en SDA y SCL generalmente considerarán que el borde en SCL ocurrió primero a menos que esté precedido sustancialmente por el borde en SDA. Algunas implementaciones de I2C manejan esto mediante la sincronización de SCL y SDA con algún reloj externo y requieren que se observe un flanco descendente de SDA dos períodos antes que el de SCL para que se considere que es lo 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 parece que una de esas secuencias se dirige al dispositivo lento, puede reaccionar en consecuencia, aplastando cualquier otra comunicación que pueda estar ocurriendo.

No hay ninguna razón particular por la que los dispositivos en un bus I2C deban depender de la sincronización con el reloj del sistema (sería mejor poder detectar dos umbrales discretos en SCL), pero el hecho es que algunos dispositivos funcionan de esa manera. . Tenga en cuenta que incluso si un dispositivo que estaba limitado a velocidades bajas internamente quisiera coexistir con un bus rápido, es probable que tenga que emplear el estiramiento del reloj en cualquier momento en el que esté pasando algo en lo que pueda estar interesado.

Esto causaría que algunas comunicaciones se produzcan más lentamente de lo que podrían hacerlo, pero la degradación de la velocidad probablemente no sería tan mala como se requiere con el diseño sincronizado con el reloj (la cantidad real por la cual el dispositivo lento alarga los relojes no sería tan malo como la cantidad en la que el reloj debe reducirse para evitar fallas en el peor de los casos en las unidades de reloj sincronizadas).