He estado usando con éxito la USI en un Attiny84 para hablar SPI a un módulo de radio. Esto es bueno para piratear sensores y otras cosas como pequeños dispositivos de radio. Mi próximo proyecto de sensor involucra un sensor con una interfaz I2C. Sé que USI también puede hablar I2C, pero ya lo estoy usando para hablar SPI a la radio.
Sé que el propio USI tiene bits de modo para cambiarlo de modo de tres a dos hilos, por lo que podría hacer que hable SPI o I2C. Pero, ¿cómo podría esto interactuar con hardware externo? Cuando está en modo I2C para hablar con el otro dispositivo, se desactiva la línea SS del dispositivo SPI, por lo que la radio SPI simplemente la ignorará. Pero cuando está en modo SPI para hablar con el módulo de radio, seguramente los datos y las líneas del reloj serán tales que el dispositivo I2C piense que una transacción está en curso. ¿Algo que pueda hacer para evitar esto?
Algunas ideas que tengo:
-
Implementación de software de I2C en dos pines GPIO de repuesto.
-
Colocando una puerta de búfer entre la salida del reloj de la pequeña USI y la línea SCL del bus I2C, para que un pin GPIO en la pequeña pueda controlarlo.
-
Use otro pin GPIO como la línea SCL en el bus I2C, y use la temporización solo de software del USI.
Sin embargo, cada uno de estos utiliza al menos otro pin GPIO, y no tengo muchos de repuesto. ¿Puedo hacerlo de una manera más agradable? P.ej. ¿Alguna manera de trabajar las líneas garantizada por orden en modo SPI, para que I2C nunca vea una condición de "INICIO"?
¿Alguna vez alguien más ha mezclado con éxito estos?