use shiftIn and shiftOut with attiny85

Question

I want my Attiny85 to communicate with another attiny85. one attiny should send a message to my other attiny. When he receives the correct message he should turn one led on. Just a very simple test scatch. I don't know why but the led never turns on.

Here is my code:

1st attiny85:

int clk_pin = 4,
    data_pin = 3,
    led = 0;

void setup() {
  pinMode(clk_pin, INPUT);
  pinMode(data_pin, INPUT);
  pinMode(led, OUTPUT);
}

void loop() {
  byte incoming = shiftIn(data_pin, clk_pin, LSBFIRST);

  if (incoming == 2)
  {
    digitalWrite(led, HIGH);
    delay(1000);
    digitalWrite(led, LOW);
    delay(1000);
  }
}

2nd attiny:

int clk_pin = 0,
    data_pin = 1;

void setup(){
  pinMode(clk_pin, OUTPUT);
  pinMode(data_pin, OUTPUT);
}

void loop(){
  byte test = 2;
  shiftOut(data_pin, clk_pin, LSBFIRST, test);

  delay(5000);
}

I think there might be something wrong with my shiftIn/shiftOut command. It's actually the first time I'm using this.

Thanks for helping!

Answer 1

shiftIn() and shiftOut() are designed for communicating with different types of shift registers. These are typically external components which don't run code themselves, such as the 74HC595.

You can't use shiftIn() to read data that's been written using shiftOut(). The reason is that both functions try to act as the host in the communication -- i.e. the one that controls the clock line.

When you call shiftIn(), the clock line is pulsed each time it's ready to read a bit (i.e. it tells the shift register when to write). When you call shiftOut(), the clock line is pulsed each time it writes a bit (i.e. it tells the shift register when to read).

Neither one will respond to a clock line provided externally. The result is that your ATTiny's aren't synchronised so they won't be reading/writing at the same time.

A much simpler approach would be to setup a conventional serial connection between the two microcontrollers. You could do that either using software or hardware serial. The only caveat is that the sender would need to ensure the receiver is up-and-running before it transmits anything. This could be done using some kind of handshake at startup -- one device repeatedly sends something until the other replies.