2

I am working on communication between a Arduino and ATtiny13, and I need to get this bare-bone communication to work. There is a Arduino Nano powered by USB cable from the PC, and there is ATtiny13 powered by 3V3/GND from the Nano. Nano pin 2 and Tiny pin 2 are connected by single 20cm long wire.

Nano sends one byte of information to Tiny, and then Tiny sends the same byte back to Nano. At least that is the idea, it doesn't quite work.

This is Arduino sketch (master of sorts):

    #define DATA_PIN 2
    
    void setup() {
      pinMode(DATA_PIN, OUTPUT);
      digitalWrite(DATA_PIN, HIGH);
      Serial.begin(9600);  // Otvori Serial Monitor
    }
    
    void loop() {
      byte dataToSend = 0x55;  // sending some byte
      byte receivedData;
    
      sendByte(dataToSend);
    
      receivedData = receiveByte();
      
      pinMode(DATA_PIN, OUTPUT);
      digitalWrite(DATA_PIN, HIGH);
      
      Serial.print("Sent: 0x");
      Serial.print(dataToSend, HEX);
      Serial.print(", Received: 0x");
      Serial.println(receivedData, HEX);
    
      delay(1000);  // small pause for user's convenience
    }
    
    void sendByte(byte data) {
      pinMode(DATA_PIN, OUTPUT);  // to output mode
      digitalWrite(DATA_PIN, LOW);
      delayMicroseconds(500);
      for (int i = 0; i < 8; i++) {
        digitalWrite(DATA_PIN, (data & (1 << i)) ? HIGH : LOW);  // send one bit
        delayMicroseconds(500);  // one bit duration
      }
      digitalWrite(DATA_PIN, HIGH);  // Idle state
    }
    
    byte receiveByte() {
      pinMode(DATA_PIN, INPUT);  // switch to input mode
      byte received = 0;
      while (digitalRead(DATA_PIN) == HIGH);  // wait for LOW (start bit)
      delayMicroseconds(750);  // wait to half of first bit
      for (int i = 0; i < 8; i++) {
        if (digitalRead(DATA_PIN) == HIGH) {
          received |= (1 << i);  // read one bit
        }
        delayMicroseconds(500);  // to the end of the bit
      }
      pinMode(DATA_PIN, OUTPUT);  // back to output mode
      digitalWrite(DATA_PIN, HIGH);  // idle state
      return received;
    }

This is ATtiny13 sketch (this would be the slave):

    #define DATA_PIN 2
    
    void setup() {
      pinMode(DATA_PIN, INPUT);
    }
    
    void loop() {
      byte receivedData = receiveByte();  // wait for the message from arduino
      sendByte(receivedData);  // send back that data
    }
    
    byte receiveByte() {
      pinMode(DATA_PIN, INPUT);  // switch to input mode
      byte received = 0;
      while (digitalRead(DATA_PIN) == HIGH);  // wait for LOW (start bit)
      delayMicroseconds(750);  // wait for the half of bit
      for (int i = 0; i < 8; i++) {
        if (digitalRead(DATA_PIN) == HIGH) {
          received |= (1 << i);  // reat the bit
        }
        delayMicroseconds(500);  // to the end of bit
      }
      return received;
    }
    
    void sendByte(byte data) {
      pinMode(DATA_PIN, OUTPUT);  // to output mode
      digitalWrite(DATA_PIN, LOW);
      delayMicroseconds(500);
      for (int i = 0; i < 8; i++) {
        digitalWrite(DATA_PIN, (data & (1 << i)) ? HIGH : LOW);  // send one bit
        delayMicroseconds(500);  // duration of one bit
      }
      pinMode(DATA_PIN, INPUT);  // back to input mode
    }

All that I get is this, over and over:

...
Sent: 0x55, Received: 0x0
Sent: 0x55, Received: 0x0
Sent: 0x55, Received: 0x0
...

Now, when I send some hardcoded data from Tiny to Arduino, it gets displayed on Serial monitor just fine.

The problem is somewhere in sending from Arduino to Tiny, please help!

Improve this question
11
  • 9600 is just for serial monitor, this communication between the MCUs has arbitrary 500 microseconds bit length Commented Feb 9 at 17:30
  • @Milos In a comment to an answer, you said GPT gave you dumb code. Is the above code you are using AI generated? Commented Feb 9 at 17:31
  • 2
    debug this by changing the speed to 2 seconds per bit ... flash an led on both devices between transmitting bits and when reading bits ... that will tell you if the bits are being read at the correct time Commented Feb 9 at 17:37
  • Justme: yes, it is ai generated, and later corrected to have the start bit... I just took it from ai without reviewing it... Commented Feb 9 at 18:13
  • jstola: thanx, it is a great idea, Imma do it! Commented Feb 9 at 18:14

2 Answers 2

Reset to default
0

There are at least three problems with your code. The first is that the sender does not send the startbit that the receiver expects, and the others are that the the receiver waits for a startbit for each bit received, and that it samples that startbit instead of the following bits. Thus, the code should be more like this:

void sendByte(byte data) {
  pinMode(DATA_PIN, OUTPUT);  // to output mode
  // Send start bit
  digitalWrite(DATA_PIN, LOW);
  delayMicroseconds(500);
  // Send data bits
  for (int i = 0; i < 8; i++) {
    digitalWrite(DATA_PIN, (data & (1 << i)) ? HIGH : LOW);  // send one bit
    delayMicroseconds(500);  // duration of one bit
  }
  digitalWrite(DATA_PIN, HIGH);  // Idle state
  pinMode(DATA_PIN, INPUT);  // back to input mode
}    

byte receiveByte() {
  byte received = 0;

  // wait for LOW (start bit)
  while (digitalRead(DATA_PIN) == HIGH); 
  delayMicroseconds(500)  
  for (int i = 0; i < 8; i++) {
    delayMicroseconds(250);  // wait for the half of bit
    if (digitalRead(DATA_PIN) == HIGH) {
      received |= (1 << i);  // read the bit
    }
    delayMicroseconds(250);  // to the end of bit
  }
  return received;
}

In addition there may be some timing problems. Testing with an ATtiny1614 instead of an ATtiny13, the delayMicroseconds was found to give too short delays, resulting in the byte received being wrong, the reply being started too early, and the reply having wrong timing. This problems could be solved by including

#define F_CPU 16000000UL
#include <avr/delay.h>

at the top of the ATtiny file, setting the Attiny1614 frequency to 10 MHz(!), and replacing delayMicroseconds() with _delay_us().

Improve this answer
5
  • thanx, GPT gave me some dumb code, but still, it don't work Commented Feb 9 at 15:11
  • 1
    Your code isn't any better than the original. You've just distributed the delays differently. But both versions fail to transmit a full stop bit, which becomes a problem when sending bytes back-to-back. Commented Feb 9 at 15:51
  • Start bit is the important part, stop bit isn't quite needed here as the receiving routine expects only 8 bits after this start bit, and then just stops reading after the whole byte has been read. I just cannot locate the problem... Commented Feb 9 at 17:06
  • @DaveTweed Compared to the code originally in the question when I wrote my answer, the answer solved the three pinpointed problems. These improvements were later incorporated in the code in the question. Commented Feb 9 at 20:57
  • @Milos There might be some timing problems on the ATtiny13. A possible solution to this is added to my answer. Commented Feb 9 at 20:57
0

ATtiny13 powered by 3V3/GND from the Nano

This is an issue. The Arduino Nano uses 5 V logic. When it sets its data pin to OUTPUT HIGH, it will source excessive current through the ATtiny's ESD protection diode. This may fry the Arduino's output, the ATtiny's input, or both. Furthermore, when the data flows in the reverse direction, the ATtiny's HIGH level (3.3V) is pretty close to the Arduino's “input high” voltage (VIH = 3V). If the Arduino's 3.3V output is a bit weak, the logic level may fall below VIH. The Arduino 3.3V output is provided by the USB/serial bridge, and it is only rated to something like 30 mA.

What I suggest is:

  1. Make sure the Arduino's output and the ATtiny's input still work.

  2. Power the ATtiny from the Arduino's 5V pin.

  3. Use separate wires for the Arduino → ATtiny and the ATtiny → Arduino communication directions. If this is too impractical, then put a series resistor, at least 220 Ω, in series between the two data pins. This should prevent you from frying a GPIO in case both pins happen to be outputs at the same time (the software should prevent this from happening, but software bugs do happen).

If, once you have fixed this, it still doesn't work, then take a scope and look at the signals that travel through the wire. This should at least show you which side is failing. Other things you should try:

  • Every time you have

    pinMode(DATA_PIN, OUTPUT);
digitalWrite(DATA_PIN, HIGH);

    swap these lines around. This should prevent a glitch where the line could be in the OUTPUT LOW state for a very brief time, which the receiver may interpret as a start bit.

  • Replace every instance of INPUT with INPUT_PULLUP. This should prevent the line from floating, which could cause spurious stop bits to be detected.

  • Make the senders output a stop bit. Yes, I know the receivers do not expect a stop bit. However, a stop bit gives the receiver time to get itself ready to catch the next start bit. Or, better yet, add five stop bits. This should make it easier for you to tell the frames apart on the scope.

  • Use direct port manipulation instead of digitalRead()/digitalWrite(). These function from the Arduino core are really slow, and they may throw your timings off.

  • Use a hardware timer instead of delayMicroseconds(). A timer's accuracy will not be thrown off by the time the CPU spends executing other code, including timer interrupts.

Improve this answer
1
  • 1
    Instead of direct port manipulation I use with great success and the same result the library digitalWriteFast. Its functions can be used anywhere with pins that are known constants at compile time. Commented Feb 10 at 10:10

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.