Need Help Getting I2C TinyWireS Slave code working in ATtiny85..

Hi Everyone,

I've been digging for a while and no luck finding my problem.

I've got an ATtiny85 that I've got loaded up with an example sketch from here: (the slave example) and on my Duemillanova I've got the i2cREPL sketch loaded up to test the bus:

Everytime I hook up the attiny, Enter "S" to scan, I get the message some the Serial Monitor:

Scanning for devices...please wait

There is a problem with the bus, could not complete scan

When I unplug it, my other devices on the bus show up, DS1307 and 24c32 EEPROM.

Scanning for devices...please wait

Found device at address - 0x50 Found device at address - 0x68

Scan done.

When I hook up with the ATTiny alone on the bus with two 4.7K pull-ups I also get the same result.

Scanning for devices...please wait

There is a problem with the bus, could not complete scan

Any ideas?

Anyone who's used this code before and maybe know's what going on?

Which of the examples are you running? Post the schematics of your setup (the complete as you test on)! Looks like your setup acts like it would do clock stretching.

Attiny85 Setup

Arduino Duemillanova Setup
I2C Master Library: GitHub - rambo/I2C: Arduino I2C Master library (originally by Wayne Truchsess)
Demo Code/I2C Tool: I2C/i2crepl.ino at master · rambo/I2C · GitHub

Schematic:(Substitute Uno for Duemillanova)

Update, I just tried the same code and the modified I2C slave library on an ATtiny84 with the same error as above.

GitHub - svoisen/TinyWire: My modifications to TinyWire Arduino libs <-Attiny84 TinyWireS library


I have this programmer:

The programmer also has breakout pins for prototyping and you just plug it into USB and it powers the chip. Also, you can unplug it from USB and feed it power and ground and it'll work like the same. (Features as advertised).

It turns out this programmer hardware is messing up the I2C bus. I learned this because I set up the circuit exactly like the above picture and it works! (Removed ATiny and put into breadboard.) Then I hooked up a DS1307 and 24c32 to the bus and they all are recognized!

I've emailed sparkfun about this.

( :fearful:If I only did this 24 hours ago...)

I've emailed sparkfun about this.

You don't have to email them, they probably know about. The programmer is not supposed to be left on the device during operation. Plug it in, upload the new sketch and unplug it. That's the expected work-flow. The programmer pulls PB0 to GND by the yellow LED. During the programming this is not a problem because it's the MOSI pin but if you want to do I2C this pin is SDA and a constantly grounded SDA pin is not what you'd expect on an I2C bus.

Thanks for clarification. It's too late, they already wrote me back and explained the same thing! It is advertised as a breakout so I thought there wouldn't be any problems with it. Oh well.

Thanks! I'm still having some other little issues with i2c and the rest of the performance of my attiny that I've gotta work through now.

I've got it somewhat working..I seem to have trouble with multiple devices on the bus..The other devices don't read..and sometimes the ATTiny won't read. I have to unplug it from the bus and plug it back in and then it will read. Mind you, I'm using a Netduino as a master I2C. Also, when I hooked it up to a Logic Analyzer, I get some suspect results with regards to the protocol, but the results that are returned are the correct value:

Here's my Slave Request Event Which will split a short into two bytes and send them back.

void requestEvent()
  if (ReceiveCount==1)
   Data1 = TinyFrequencyCounter.PeriodMicros();//buffer data
   //send lower
   byte byteL = Data1 & 0xFF;
   //byte byteL = 100;
  else if (ReceiveCount == 2)
  //send upper
  byte byteU = Data1 >> 8;
  //byte byteU = 100;

I found an updated USITWISLAVE library that has since been updated which might fix my problems, but I'm having trouble getting it to work/adapting to Arduino Code. Still working on it..

That sounds a bit like the problem that I had with an ATtiny and I2C. Your logic analyzer doesn’t show the picture of the SDA unfortunately so I have to guess that yours might be the same problem.
I had timing issues because of the timer interrupt of the Arduino environment (that feeds the millis() and micros() calls). If you turn that off or at least enable interrupts again in the interrupt handler you might get it to run smoothly (as it did for me).

Well, the results seem inconsistent, but now I'm getting clean transfers when it's working... Here's a updated screenshot.[click to enlarge] Would you like me to zoom in on a specific part?

I am using Micros to capture some time.

Here's my ISR:

//PCINT Interrupt
  microsTemp = micros(); //get time first!
  if (ReadPinState()>0)//pin is high/rising edge
      case 1: t1=microsTemp;//start time
      case 2: t2=microsTemp;//end time
              InterruptCount=0;//reset count