Attiny master-slave I2C communication

[shomar80]

Hi Rambo,

I am not sure if I am posting this in the correct place, so I would appreciate if you can take a look?

I have started a question where I am trying to establish communication between attiny 85 master and 2 attiny85 slaves using your library, the details are here: http://forum.arduino.cc/index.php?topic=255543.0

I hope you can help me in finding where and what I am doing wrong?

Thanks

[rambo]

Can't be bothered to register on the Arduino forum right now, most likely reason is that the master library can't deal with the slave strething the I2C clock, this is very common problem when there is no hardware support for full I2C spec.

The clock speeds are likely a red herring, maybe the fuses are set wrong somehow but I don't see the I2C coms working at all if the slave is running at 1MHz, unless you specify some nonstandard extra-low bus speed.

[shomar80]

Hi Rambo,

I am not sure exactly how it is happening, I have the slave set to 1Mhz and the master at 16Mhz and it is working. I used the arduino IDE to set the clocks, so I am not sure what settings are being pushed when I have done that.

Thank you for the reply anyway, I really appreciate it :)

[rambo]

You need to "burn bootloader" each time you change the clock speed, then you upload the program.

Anyway if you have a logic analyzer of any sort (OpenLogicSniffer, Bus Pirate with a logic analyzer firmware) you can check what is actually going on in the I2C bus (I have OpenLogicSniffer, and it was pretty invaluable in figuring out what went wrong when I was trying to use Bus Pirate to test my attiny I2C slave code [turns out BP can't handle clock stretching by the slave... so I had to write https://github.com/rambo/I2C/blob/master/examples/i2crepl/i2crepl.ino ])

[shomar80]

I have burnt the boot loader when I changed the clock as you mentioned.

I ordered a logic analyzer from saleae and can't wait to receive it to get to the bottom of this. Maybe I can share the outputs once I have that if you are interested? I am also interested in learning from you on this :)

[rambo]

Ok, just checking. In fact I'm not sure I have actually tested I2C at 1MHz, just read somewhere that 8MHz is the minimum.

It seems Salea has OSX software so I can take a look at the data files too when you get them, remember to sample at 4 times the bus speed (or even faster) to get accurate clock edges (twice the bus speed you can recover the data but cannot see jitter and other possible timing issues).

[shomar80]

Excellent, I will keep you posted then although this will take a whole for delivery.

[ravipr72]

Hi Rambo, I am trying to use TinyWire{S,M} on attiny45@8Mhz and it does'nt seem to work. I have modified the example code to just react to request from Master. Is there any known issue here? It seems to work fine if I use Arduino (Wire) as either Master or Slave.

[rambo]

Probably TinyWireM cannot deal with "clock-stretching" (neither will raspberry pi, btw), ATMega328 (in Arduino) has proper hardware I2C so in slave mode it does not stretch the clock (if you don't do much, but you shouldn't) and in master mode it can handle clock-streching by the slave.

[ravipr72]

Thanks for the reply. I really appreciate. Note that if I replace either of Master or Slave with ATMega328, it seems to work. is that expected as well?

[rambo]

Yes, in slave mode atmega328 will not stretch the clock (unless you do something incredibly stupid in the interrupt) and in master mode it can handle clock stretching correctly.

ATTiny1634 in theory has proper hardware support for I2C slave (but not master), but I have not yet had the time to update this library to support that.

[ravipr72]

BTW, changing the Slave to 16Mhz and master to 8Mhz makes it work quite well. basically Slave has to be faster than the master so that Master does not resort to clock stretching.

On Sat, Jan 17, 2015 at 3:27 AM, Eero af Heurlin notifications@github.com wrote:

Closed #11 https://github.com/rambo/TinyWire/issues/11.

— Reply to this email directly or view it on GitHub https://github.com/rambo/TinyWire/issues/11#event-220363366.

[rambo]

It's the slave that does the clock-streching, not master. But yeah, if the slave is fast enough (for whatever reason) then there is no need to stretch the clock. You could also just lower the I2C communication speed (since the bus is synchronously clocked by the master it doesn't really matter if you're using "nonstandard" speed as long as the master can generate that clock).

[ravipr72]

Thanks and sorry for bugging you (again). How do I lower the I2C speed? I tried chaning the F_CPU and SYS_CLK in TinyWireM, but do not recall it made any difference. Will try again if thats the way to slow it down.

On Tue, Jan 20, 2015 at 12:14 PM, Eero af Heurlin notifications@github.com wrote:

It's the slave that does the clock-streching, not master. But yeah, if the slave is fast enough (for whatever reason) then there is no need to stretch the clock. You could also just lower the I2C communication speed (since the bus is synchronously clocked by the master it doesn't really matter if you're using "nonstandard" speed as long as the master can generate that clock).

— Reply to this email directly or view it on GitHub https://github.com/rambo/TinyWire/issues/11#issuecomment-70611346.

[ravipr72]

I meant that if Slave is faster and will not do clock stretching, master will not have to handle the clock stretching scenario - basically I picked it up from your old email to me on this topic !

On Tue, Jan 20, 2015 at 12:14 PM, Eero af Heurlin notifications@github.com wrote:

It's the slave that does the clock-streching, not master. But yeah, if the slave is fast enough (for whatever reason) then there is no need to stretch the clock. You could also just lower the I2C communication speed (since the bus is synchronously clocked by the master it doesn't really matter if you're using "nonstandard" speed as long as the master can generate that clock).

— Reply to this email directly or view it on GitHub https://github.com/rambo/TinyWire/issues/11#issuecomment-70611346.