I've been successfully using the USI on an Attiny84 to talk SPI to a radio module. This is good for hacking up sensors and whatnot as little radio devices. My next sensor project involves a sensor with an I2C interface. I know the USI can talk I2C as well, but I'm already using it to talk SPI to the radio.
I know the USI itself has mode bits to switch it from three- to two-wire mode, so I could have it talk SPI or I2C. But how might this interact with external hardware? When it's in I2C mode to talk to the other device, the SPI device's SS line is deasserted, so the SPI radio will just ignore it. But when it's in SPI mode to talk to the radio module, surely the data and clock lines will be such that the I2C device thinks a transaction is ongoing? Anything I can do to prevent this?
Some ideas I have:
Software implementation of I2C on two spare GPIO pins.
Putting a buffer gate between the clock output of the tiny USI and the SCL line of the I2C bus, so that one GPIO pin on the tiny can control it.
Use another GPIO pin as the SCL line on I2C bus, and use software-only clocking of the USI.
Each of these uses at least one other GPIO pin though, and I don't have many spare. Can I do it a nicer way? E.g. some order-guaranteed way of working the lines when in SPI mode, so that I2C never sees a "START" condition?
Has anyone else ever successfully mixed these?