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

No me parece. Compartir de forma simplista el reloj y las líneas de datos entre dispositivos SPI e I ² C no parece una buena idea. Tal intercambio puede introducir un modo de falla, que puede corromper la comunicación SPI.

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

Entonces, qué puede hacerse. Tiene un dispositivo SPI que requiere comunicación de alta velocidad y muchos dispositivos I ^{2 C que pueden funcionar con una comunicación relativamente lenta.} Una situación como la suya no es infrecuente. Considere estos:

• 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 puente SPI a I ² C (esclavo SPI, maestro I ² C) .
• Utilice el MSSP para ambos autobuses. Coloque los dispositivos I ² C en su propia rama que tiene un interruptor, que puede desconectar los dispositivos I ² C del bus durante la comunicación SPI.
• Busque una foto con 2 periféricos MSSP.

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

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 verán ninguna secuencia de pulsos que los lleve a realizar alguna acción o generar 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 las que el estado del cable de datos I2C no cambie. Cuando se usa un maestro SPI típico y se conecta CLK a SCK y MOSI o MISO a SDA, tal garantía puede no cumplirse ya que el reloj y los datos cambiarían aproximadamente simultáneamente, y cómo los interpreta el dispositivo I2C dependería de qué señal vio cambiar primero. .

Sin embargo, si el hardware es lo suficientemente configurable como para poder conectar CLK a SDA y MOSI a SCK, entonces las cosas podrían funcionar de manera segura en una implementación típica de SPI siempre que se eviten las direcciones I2C que contienen todos ceros o todos unos, ya que sería imposible que MOSI vaya de bajo a alto y luego de alto a bajo más de una vez (mucho menos ocho veces) sin que intervenga la transición 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 que las secuencias de señales que no estarían definidas en una interfaz indican que deben usar una interfaz diferente. Debería ser posible que los dispositivos seleccionen automáticamente las interfaces a través del flejado sin tal detección falsa si algunas interfaces que usan un subconjunto de los cables requieren que otros cables se flejen juntos (por ejemplo, para un dispositivo que admite SPI e I2C, cableado tanto /CS como CLK a SDA y MOSI a SCK), pero muchos dispositivos utilizan métodos de detección toscos y poco fiables que pueden causar estragos incluso cuando se utilizan con otros dispositivos del mismo tipo .

Creo que el circuito que se muestra a continuación logrará lo que necesita. Se muestra un dispositivo I2C, junto con dos dispositivos SPI. El circuito se puede ampliar fácilmente a cualquier número de dispositivos I2C o SPI. Las puertas lógicas adicionales requeridas se comparten entre todos los dispositivos; no se necesitan puertas lógicas por dispositivo, por lo que se mantiene la cuenta atrás de las piezas. Solo se necesita un cable adicional por encima del máximo de cuatro (más selecciones de chip 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 (entrada de datos SPI) están en el mismo pin. SDO (salida de datos SPI) está en un pin por sí mismo.

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

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

Si alguna selección de chip es 0, entonces la salida de la compuerta AND es 0, lo que desactiva el interruptor analógico, por lo que el reloj SCL del microcontrolador no puede llegar a los dispositivos I2C. Si todas las selecciones de chip 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 bidireccionalmente entre el microcontrolador y los dispositivos I2C.

Para el segundo problema, se proporciona un pullup en los pines SDA según la especificación I2C. Por supuesto, esto también activa el pin SDA/SDI del microcontrolador. Dado que 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 se afirma, manteniendo alta la salida de colector abierto del búfer.