I2C y SPI en el mismo bus

Algunos dispositivos esclavos I2C utilizan una configuración de hardware, lo que implica tener dispositivos esclavos que no están listos inmediatamente para un ciclo que mantiene SCK bajo hasta que lo están, y tener dispositivos maestros que liberan SCK esperan hasta que la línea realmente se levante antes de procesar el siguiente ciclo. Dichos dispositivos no coexistirán bien con un bus SPI.

Si el dispositivo I2C no acepta 00 o FF como un byte de direccionamiento, se puede evitar cualquier posibilidad de interferencia configurando el bus SPI para que el estado de los datos solo cambie cuando el reloj sea alto, o bien asegurándose de que el dispositivo I2C verá como caen los bordes de reloj que caen después de cualquier cambio de datos asociado. Dependiendo de a qué tipo de dispositivo SPI se está conectando, ese puede ser el estado natural de las cosas o puede ser algo incómodo. Si se trata de un SPI que golpea a los bits, generalmente no será difícil garantizar que la secuencia de altos y bajos en SCK / SDA reinicie continuamente el chip I2C sin que sea capaz de decir nada. Si se necesita usar SPI de hardware, pero se puede usar BitBang I2C, el cableado de SCK a otro que no sea el reloj SPI puede permitirle evitar problemas [por ejemplo, si uno conecta SCK a MOSI y SDA a MCK, entonces sería imposible que SCK vea más de dos ciclos consecutivos sin que se produzca un flanco ascendente o descendente en SDA mientras SCK estaba sentado arriba].

Una advertencia importante con este enfoque, sin embargo, es que muchos dispositivos I2C no especifican su comportamiento si las transiciones en SCK o SDA ocurren por encima de una cierta velocidad, y los dispositivos SPI a menudo se ejecutan muy por encima de las velocidades que los dispositivos I2C pueden acomodar. Si es práctico, puede ser bueno que I2C comparta un pin con SPI pero no ambos, o agregue algún hardware para garantizar que I2C no vea señales rápidas en SCL y SDA

si su dispositivo i2c no tiene habilitación, o un cs cuando intenta hablar spi en esos pines, puede confundir la máquina de estado i2c interna. El mejor caso que significaría que su próxima transacción i2c se estropearía, o podría tirar de la línea baja en medio de una transacción spi. En el peor de los casos podría bloquear el bus i2c. Probablemente podría desbloquearlo pero tendría que revisar cada lectura y escritura (tal vez la suma de comprobación).

También debe asegurarse de que si está compartiendo líneas como la línea de salida de su dispositivo spi, no debe mantener el pin ni bajo ni alto cuando está desactivado. De lo contrario, i2c no podrá escribir o luchará duro contra el controlador.

En general, no lo haría yo mismo, tal vez podría agregar un pequeño interruptor mux o fet para aislar el dispositivo i2c en modo spi.

Podría funcionar, y en lo que se reduciría es: ¿podría cualquier flujo de bits SPI parecerse a una condición de inicio I2C seguida por cualquiera de las direcciones de esclavo de los dispositivos I2C que está utilizando? Ninguno de sus dispositivos I2C intentará hacer nada o interrumpir el bus sin esta secuencia inicial.

La segunda parte, no enviar ninguna dirección de esclavo I2C válida, puede ser complicada, ya que querrá ser capaz de escribir cualquier información que desee en su tarjeta SD. Así que te quedas con la primera parte: no se produce una condición de inicio I2C durante las comunicaciones SPI.

Dado que se produce un inicio de I2C cuando la línea SDA cambia de alta a baja, mientras que SCL es alta, esto es lo que debe tener en cuenta.

Si puede configurar su maestro SPI para que solo cambie el estado de SDO cuando SCK está bajo, entonces no debería tener problemas ...