Usando la comunicación I2C y SPI en el mismo reloj y líneas de datos

No lo creo. Un simple hecho de compartir el reloj y las líneas de datos entre los dispositivos SPI e I ² C no parece una buena idea. Dicho intercambio puede introducir un modo de falla, que puede dañar la comunicación SPI.

Imagina que MOSI / SDA y SCLK / SCK están compartidos. Nos estamos comunicando con el dispositivo SPI. Los dispositivos esclavos I ² C "ven" también el reloj y los datos. Es posible que alguna combinación aleatoria de bits en los datos SPI se vea como una condición de inicio y dirección de esclavo para el dispositivo I ² C. El dispositivo esclavo I ² C interpretará esto como el comienzo de una transacción de lectura I ² C, comienza a transmitir y baja el MOSI / SDA. Esto corrompería la comunicación SPI.

Entonces, ¿qué se puede hacer. Tiene un dispositivo SPI que requiere comunicación de alta velocidad y muchos dispositivos I ² que pueden funcionar con una comunicación relativamente lenta. Una situación como la tuya no es infrecuente. Considera esto:

• Use el periférico de hardware (MSSP en el PIC) para SPI. Bit-bang I ² C en un par de pines de E / S digitales separados.
• Utilice MSSP para la comunicación SPI. Conecte los dispositivos I ² C a través de un SPI-to-I ² puente C (SPI slave, I ² C master) .
• Utilice el MSSP para ambos buses. Coloque los dispositivos I ² C en su propia sucursal que tiene un interruptor, que puede desconectar los dispositivos I ² C del bus durante la comunicación SPI.
• Busque una foto con 2x periféricos MSSP.

editar:
El tema de usar el mismo MSSP para SPI y I ² C ha aparecido en los foros varias veces a lo largo de los años: CCS forum 2003 , PicList 2005 (discusión sólida) , Foro propio de Microchip 2012 , EE.SE 2012

Creo que el circuito que se muestra a continuación logrará lo que necesitas. Se muestra un dispositivo I2C, junto con dos dispositivos SPI. El circuito se puede expandir fácilmente a cualquier número de dispositivos I2C o SPI. Las puertas lógicas adicionales requeridas se comparten entre todos los dispositivos; No hay puertas lógicas necesarias por dispositivo, por lo tanto, se mantiene el conteo de partes. Solo se necesita un cable adicional por encima del máximo de cuatro (más las selecciones de chips SPI) necesarios para las interfaces I2C / SPI estándar.

En el PIC18F25K80, SCL (reloj I2C) y SCLK (reloj SPI) están en el mismo pin, y SDA (datos I2C) y SDI (SPI data in) están en el mismo pin. SDO (salida de datos SPI) está en un pin por sí mismo.

Hay dos problemas: uno es deshabilitar el (los) dispositivo (s) I2C cuando se selecciona un dispositivo SPI (y, a la inversa, para deshabilitar la (s) línea (s) de salida del (los) dispositivo (s) SPI cuando no están seleccionados (s); y, en segundo lugar, abordar el problema de los pull-ups en las líneas I2C cuando el cable SDI de SPI está impulsando la línea SDA / SDI en el microcontrolador.

Para manejar el primer problema, todas las selecciones de chips SPI se ANDAN juntas. Estoy mostrando un 74HCT21 de cuatro entradas Y con dos entradas sin usar; esto podría expandirse a cualquier número de selecciones de chips.

Si cualquier selección de chip es 0, entonces la salida de la compuerta AND es 0, lo que deshabilita el interruptor analógico, por lo que el reloj SCL del microcontrolador no puede llegar al dispositivo (s) I2C. Si todas las selecciones de chips son 1, entonces la salida de la compuerta AND es 1, lo que habilita el interruptor analógico, por lo que el reloj SCL pasa de manera bidireccional entre el microcontrolador y el dispositivo (s) I2C.

Para el segundo problema, se proporciona un pullup en los pines SDA según la especificación I2C. Por supuesto, esto también pone un pullup en el pin SDA / SDI del microcontrolador. Como los dispositivos SPI no están configurados para conducir contra un pullup, agregué un búfer de colector abierto 74HCT07 para solucionar este problema.

El búfer está precedido por una puerta OR, con una entrada del mismo cable que habilita / deshabilita el reloj I2C. De modo que cuando la interfaz I2C está habilitada, la puerta OR siempre está activada, manteniendo la salida del colector abierto del búfer alto.

Es posible compartir pines I2C y SPI si el código que usa cada interfaz puede garantizar que los dispositivos que usan la otra nunca vean ninguna secuencia de pulsos que haga que realicen cualquier acción o produzcan datos. Para evitar que una secuencia de pulsos se confunda con una secuencia de direccionamiento I2C, uno debe asegurarse de que nunca haya ocho transiciones consecutivas bajo-alto-bajo en el cable del reloj I2C en el que el estado del cable de datos I2C no cambie. Cuando se utiliza un maestro SPI típico y el cableado CLK a SCK y MOSI o MISO a SDA, es posible que no se cumpla dicha garantía, ya que el reloj y los datos cambiarían aproximadamente de manera simultánea, y la forma en que el dispositivo I2C los interprete dependerá de la señal que vió cambiar primero .

Sin embargo, si el hardware es lo suficientemente configurable como para poder conectar CLK a SDA y MOSI a SCK, las cosas podrían funcionar de manera segura en una implementación SPI típica siempre que se eviten las direcciones I2C que contienen todos los ceros o todos, ya que sería imposible para que MOSI pase de bajo a alto y luego de alto a bajo más de una vez (mucho menos ocho veces) sin una transición intermedia en CLK.

Una advertencia es que algunos dispositivos intentan "detectar automáticamente" la interfaz adjunta, y algunos métodos de detección automática pueden considerar secuencias de señales que no se definirían en una interfaz como una indicación de que deberían usar una interfaz diferente. Debería ser posible que los dispositivos seleccionen automáticamente las interfaces mediante el flejado sin tal detección falsa si algunas interfaces que usan un subconjunto de los cables requieren que otros cables se unan entre sí (por ejemplo, para un dispositivo que admita SPI e I2C, el cableado de ambos / CS y CLK a SDA, y MOSI a SCK), pero muchos dispositivos utilizan métodos de detección crudos y poco confiables que pueden causar estragos incluso cuando se usan con otros dispositivos del mismo tipo .