¿Puedo usar bus I2C o GPIO como I2C para conectar dispositivos I2C?

Dependiendo de la cantidad de datos que vayan a lo largo del bus, y si hay "conflictos" de ID de dispositivos o datos que se transfieren al mismo tiempo, no hay problema para colgar todos sus dispositivos en un bus. Para eso fue diseñado I2C.

Para repartir la carga, el uso de 2 o 3 buses I2C puede facilitar las cosas (por ejemplo, mantener los diferentes sistemas separados), pero puede significar que tiene que hacer lo mismo 3 veces en el software. Puede hacer algo como usar un bus para la transferencia de "alta velocidad" de una gran cantidad de datos (por ejemplo, hacia / desde un dispositivo de almacenamiento) y otro bus que funcione mucho más lento para realizar actividades menos críticas como leer un sensor de temperatura cada segundo o encender un LED encendido apagado.

Bit-banging I2C usando pines GPIO es un "último recurso", ya que generalmente es mucho más fácil usar el dispositivo I2C incorporado, y la mayoría de los procesadores tienen cosas como controladores de interrupción y DMA para hacer el trabajo mucho más fácil, automatizar las transferencias, ahorrar carga del procesador/sobrecarga de software, etc.

Es mucho mejor tener comunicaciones manejadas por interrupciones en lugar de intentar hacerlo por GPIO + esperas/temporizadores, etc., especialmente si tiene mucho que hacer/muchos datos para mover.

Editado para agregar: también puede ser útil usar un bus para dispositivos que necesitan un cambiador de nivel (por ejemplo, dispositivos de 5v conectados a un micro de 3.3v en un bus, dispositivos nativos de 3.3v en el otro bus)

Si está implementando un maestro I2C para un sistema de un solo maestro, sugeriría que el golpe de bits puede ser preferible a tratar de usar hardware incorporado. Entre otras cosas:

1. Si algún dispositivo en el bus I2C se "confunde", a veces puede ser difícil convencer a las implementaciones maestras de hardware para que generen las mejores formas de onda para "desatascarlo" (enfoque recomendado: si SDA no está flotando, o si su dispositivo está conduciendo SCK bajo, confirme SDA, confirme CLK, libere SDA, libere CLK y espere a que CLK suba; repita según sea necesario y luego confirme y libere SDA con SCK alto). Tenga en cuenta que si un dispositivo EEPROM pensó que estaba en medio de un ciclo de escritura, esta forma de onda hará que aborte la escritura en curso; si el procesador no sabe por qué la EEPROM esperaría escribir datos, abortar la escritura es probablemente mejor que escribir datos de los que el procesador no sabe nada. Fácil de hacer con golpes de bits; más difícil de hacer (si es posible) en muchas implementaciones de hardware I2C.
2. Muchas implementaciones de hardware I2C requieren que el procesador decida, antes de leer cada byte, si debe o no reconocerse positiva o negativamente. En muchos casos, sería más conveniente tener una rutina de "lectura de bytes" que envíe un reconocimiento positivo que reconozca el byte anterior (si lo hay), lea el siguiente byte y no lo haga hasta que se necesite el siguiente byte; una vez que no se necesiten más datos, llame a una rutina de "lectura final" para enviar un reconocimiento negativo. Tal enfoque es fácil cuando se golpean los bits, pero no conozco implementaciones de hardware I2C que permitan leer un byte sin tener que saber, de antemano, si será el último.

La facilidad o dificultad de escribir una implementación maestra I2C bit-bang es esencialmente independiente de la cantidad de dispositivos en el bus. Las implementaciones de esclavos I2C son generalmente difíciles o imposibles sin al menos cierto nivel de soporte de hardware, pero es fácil hacer grandes cambios en un maestro I2C.

Si su procesador de aplicaciones tiene hardware I2C que puede operar en modo maestro, ciertamente puede usarlo para comunicarse con dispositivos esclavos.

En comparación con las implementaciones de GPIO bit-banged, puede ser más rápido en términos de tiempo de desarrollo para usar el hardware integrado. Lo más probable es que haya algunas bibliotecas que simplificarán la configuración del modo y la actividad general que el maestro I2C deberá realizar (lecturas, escrituras, ACK, NACK, llamada general, serialización de bytes de entrada y salida, etc.)

Sin embargo, si el hardware I2C tiene errores, o las bibliotecas no le brindan la funcionalidad que necesita, es posible que le resulte mejor optar por I2C bit-banged de GPIO y evitar usar el hardware I2C. La desventaja, por supuesto, es tener que escribir mucho más código.