¿Puedo usar un ATtiny84 como esclavo SPI y maestro i2c en la misma aplicación?

Usted identificó correctamente el mayor problema: el host SPI podría intentar impulsar la línea de reloj / datos mientras que el maestro o esclavo I2C lo reduce.

El segundo problema es el tiempo, porque la solicitud SPI puede aparecer en medio del paquete I2C. Lo que suceda a continuación depende del esclavo I2C en particular. Puede ignorar los datos, esperar el próximo ciclo de reloj, esperar la condición de parada o simplemente hacer algo extraño/inesperado.

La solución más fácil ya sería la separación sugerida de los canales y el bit-banging I2C. Sin embargo, esto solo es posible si tiene 2 pines y tiempo de procesador disponible, y es aceptable una velocidad I2C más lenta.

Si lo anterior no funciona para usted, es necesario algún hardware adicional. Específicamente, necesita dos puertas de 3 estados para desconectar las líneas SCK y MOSI provenientes del maestro SPI, y una puerta más para desconectar la entrada SCL del esclavo I2C (cuando las puertas SPI están abiertas). Esta es la solución que ya describió en su pregunta y funcionará, hasta cierto punto. El problema potencial aquí es que el maestro SPI, sin saber que no está escuchando, aceptará cualquier estado que tenga en la línea MISO como respuesta válida.

Si la línea CS del maestro está disponible y desea ser más amigable con el maestro, puede intentar usar el estiramiento del reloj I2C como una forma de pausar la transacción I2C para manejar la solicitud SPI. La idea es colocar pestillos en el bus I2C para "congelar" las señales que provienen de attiny en el momento en que se activa la línea CS. Pasarán varias cosas entonces:

• el SCL y el SDA provenientes de attiny se detendrán donde estaban;
• el ISR en attiny reprogramará USI a SPI;
• al final, abrirá las puertas SCK y MOSI y manejará la solicitud entrante.

Cuando se libera la línea CS, attiny cerrará las puertas SPI, generará una condición de "parada" para el esclavo I2C y reprogramará USI nuevamente. Este es un escenario muy complicado y es posible que a algunos dispositivos esclavos no les guste (el estiramiento del reloj maestro quedó obsoleto en las especificaciones recientes).

En resumen, si puede usar bit-banging, úselo. Si no, prepárate para algunos retoques extensos.

¿La mejor solución es usar un búfer de tres estados que mi ATtiny84a pueda alternar para cortar el maestro SPI externo de las líneas en cuestión cada vez que quiera leer/escribir en la EEPROM?

Puede haber una solución más sencilla.

... ATtiny84A que utiliza una USI (interfaz serie universal) y, como tal, no hay periféricos I2C y SPI dedicados.

Bueno, USI es un periférico I2C y SPI dedicado. Pero solo un tipo de autobús en cualquier diseño dado.

¿Puedo usar un ATtiny84 como esclavo SPI y maestro I2C en la misma aplicación?

Sí, eso es posible.

• Implemente el maestro de bus I2C utilizando software bit-banging. Esto le permite usar cualquier pin GPIO para el bus I2C.
  Los buses I2C generalmente funcionan a un ritmo pausado, y una opción viable es una opción viable.
• Use el hardware USI para esclavo SPI.
  La implementación de un esclavo SPI o I2C en el firmware no es práctica a cualquier velocidad de datos razonable.