ATtiny85: i2c via USI?

[jkorinth]

Hi there! I'm trying to setup a small simulation program for an ATtiny85 with a custom i2c device. I've started its implementation from the i2c_eeprom.c example, but then I realized that the ATtiny85 does not implement TWI. So, is my understanding correct that I need to implement a bit-banging implementation of the i2c protocol on the peripheral side using the wire IRQs for PB0/PB2? Or is there an easier way with USI?

Thanks!
Jens

[gatk555]

The datasheet has a section on using USI for i2c and I think there may also be a Microchip application note. Simavr has an USI simulation, but a quick scan suggests it omits the i2c-specific features. I have used Simavr to debug a firmware with USI, but that was for asynchronous serial.

So if you want to simulate, the options are to add the USI features first, or bitbang. Or maybe a different AVR. I do not understand the "wire IRQs" as I would expect a bitbang i2c implementation to just use PORT registers.

[jkorinth]

On the firmware side I'm using TinyWireM, which is based on the application note, I think. And yea, that uses the registers of the ATtiny85 directly, AFAICT. Do you think this should work already?

On the peripheral side, I understand that I can use avr_irq_register_notify to get the PB0/PB2 state changes; this would allow to drive the i2c slave state machine, but how would I change direction on SDA? Can I simply call avr_raise_irq? I guess I would need to unregister my own callback first etc. Is there already some reusable code for this in simavr?

[gatk555]

I am fairly sure the library will not work. Several places in avr_usi.c just have a TODO comment and no code for TWI, including making connection to the pins. If that were fixed, or a library that bitbangs a GPIO port is used, then the peripheral side would use the IOPORT_IRQ_PINx IRQs with both avr_irq_register_notify() and avr_raise_irq(). The callback handler must ignore echoes of avr_raise_irq() calls. (But there could be problems with Simavr's pull-up handling).

An alternative option: assume the library is good and write a stub version that just writes a function identifier and parameters into static memory locations. The id location is written last, and monitored by an IRQ. So the peripheral code gets a callback when the library is called and can interpret at a higher level. For sending data to firmware, the stub library's read function monitors a data-ready flag in memory. That, and the data byte location are in avr->data[] and can be written directly by peripheral code. Ugly, but I think not much code. Simavr's implementations of UART, SPI, and TWI are also somewhat fake: they ignore pins and serialisation and transfer data in complete bytes with IRQ calls.