Pages: [1]   Go Down
Author Topic: (Solved) RasPi (MS) and ATtiny85 (SL) via i2c - Sketch runs once ...  (Read 1280 times)
0 Members and 1 Guest are viewing this topic.
Germany
Offline Offline
Newbie
*
Karma: 1
Posts: 6
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello!

I have successfully installed and used the ATtiny extensions using the Arduino Uno as a programmer. First I programmed a skeleton to use i2c and the only thing the sketch does is assigning a slave address to the ATtiny85. I connected everything to the Raspberry Pi and was able to detect the chip on the bus at address 0x26. Second I transferred the sample sketch "Tiny85_I2C_Slave_Ex". I then again connected everything to the Raspberry Pi.

When I run i2cdetect to see what is connected and which addresses are used I get:

Code:
pi@raspberrypi ~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: 20 -- -- -- -- -- 26 -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --              

Then I write and read from the ATtiny using i2cget. The LED flashes but instead of adding 10 to the written value and returning the new value it returns reads 0x00. When I run the sketch a second time it does not work anymore.

Code:
          pi@raspberrypi ~ $ i2cget -y 1 0x26 0x01 c
0x00

When I run i2cdetect again the ATtiny after executing the sketch once seems to have flushed the bus taking all addresses. I get:

Code:
pi@raspberrypi ~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77                        
pi@raspberrypi ~ $


I have tried several chips, tried it on a breadboard on a PCB but the result is always the same. I do not use any pullup resistors since the Raspberry Pi provides them. I added them but with no change of the results. I tried a different sketch for reading and writing from the bus and the same happens. So it has obviously nothing to do with the sketch but with a) the ATtiny85 in general or b) the TinyWire library.

Has anyone seen something similar? Are their known bugs? Or am I simply to unexperienced?

Thanks for reading! Thanks for any help!

Greetings,
Moritz
« Last Edit: January 12, 2013, 04:32:58 pm by moritzp » Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 22
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I missed your post. Sounds like: http://arduino.cc/forum/index.php/topic,140594.0.html

Maybe we can debug this thing together? Are you running the Attiny at 3.3V or with voltage shifters?
Logged

Germany
Offline Offline
Newbie
*
Karma: 1
Posts: 6
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi cronix,

seems to be the same issue. I have connected the ATtiny directly to the Raspberry Pi w/o anything inbetween. So it is running with 3V3. On the Raspberry Pi forum I found a similar discussion (see here) where it is mentioned that switching a ATtiny85 pin between input and output isn't that simple because of its tri-state nature. I checked the datasheet and on page 57, chapter 10.2.3 the topic is described.

Since I am using a dedicated library "TinyWire" (the same library that you use) I expect the library to handle it. But my knowledge is not sufficent enough to check and debug the library and verify the assumptions made in the other post.

But yes, let us solve this together.

Have a nice day!
Moritz
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I think there is a bug in usiTwlSlave.c when buffer underruns occur. Specifically, if this bit of code is ever reached, its game over:
      {
        // the buffer is empty
        SET_USI_TO_TWI_START_CONDITION_MODE( );
        return;
      } // end if
The fix is to change SET_USI_TO_TWI_START_CONDITION_MODE to set SDA as an input rather than leaving it as a output in the buffer underrun case:
#define SET_USI_TO_TWI_START_CONDITION_MODE( ) \
{ \
  /* set SDA as input */ \
  DDR_USI &= ~( 1 << PORT_USI_SDA ); \
  USICR = \
I was seeing the issue you were seeing today until I did this.
Logged

Germany
Offline Offline
Newbie
*
Karma: 1
Posts: 6
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hello rpurdie!

Thank you very much, now it works.

Greetings,
Moritz
Logged

Pages: [1]   Go Up
Jump to: