Hello All,
I try to get I2C on a Pro Mini to work since days.
Beforehand, very interesting, the same code runs on an Uno without problems.
The very simple code for master and slave you will find below.
I have tested the Pro Mini with and without 10k resistors.
Master is an Mega.
I can simulate the problem on the Uno by removing all Wire entries of the slave code.
Honestly I don't understand it.
Many thanks.
Master Mega:
#include <Wire.h>
#define pro_mini_id 10
#define start_pin 8
#define response_pin 9
byte datum;
int iteration;
int max_iteration = 25;
void setup()
{ Wire.begin();
Serial.begin(250000);
pinMode(start_pin, OUTPUT);
pinMode(response_pin, INPUT);
iteration = 1;
Serial.println("Start"); }
void loop()
{ if (iteration <= max_iteration)
{ Read_HX711();
Serial.println(datum);
iteration += 1; } }
void Read_HX711()
{ digitalWrite(start_pin, HIGH);
digitalWrite(start_pin, LOW);
while (digitalRead(response_pin) == 0)
{}
Wire.requestFrom(pro_mini_id, 1);
datum = Wire.read(); }
Slave Pro Mini:
#include <Wire.h>
#define pro_mini_id 10
#define start_pin 10
#define response_pin 11
byte buffer;
byte counter;
volatile byte signal_flag;
void setup()
{ Wire.begin(pro_mini_id);
Wire.onRequest(Response);
Serial.begin(250000);
pinMode(response_pin, OUTPUT);
pinMode(start_pin, INPUT);
counter = 1;
signal_flag = 0;
Serial.println("START");}
void Response()
{ Wire.write(buffer);
signal_flag = 1; }
void loop()
{ while (digitalRead(start_pin) == 0)
{}
delay(500);
buffer = counter;
digitalWrite(response_pin, HIGH);
while (signal_flag == 0)
{}
digitalWrite(response_pin, LOW);
signal_flag = 0;
counter += 1; }
The 'buffer' is also used in the interrupt routine 'Response()', it must therefor also be 'volatile'.
Does it work if you have the Slave code on a Arduino Uno ?
Do you have the GNDs connected ?
You don't check if some data was actually received. Use the return value of Wire.requestFrom() or use Wire.available(). If the number of received bytes is not the same as requested, then something is wrong.
I like to see a consistent text layout of the code. You have that. I think it is normal that everyone uses his or her own style to format the text. Fine. But the way you write the text of the code is something I have never seen in my life. I hope I don't offend you, but it is awkward. The structure of the code is not visible when you use closing curly brackets like that. Did you use a different language before ?
Koepel:
The 'buffer' is also used in the interrupt routine 'Response()', it must therefor also be 'volatile'.
Does it work if you have the Slave code on a Arduino Uno ?
Do you have the GNDs connected ?
You don't check if some data was actually received. Use the return value of Wire.requestFrom() or use Wire.available(). If the number of received bytes is not the same as requested, then something is wrong.
I like to see a consistent text layout of the code. You have that. I think it is normal that everyone uses his or her own style to format the text. Fine. But the way you write the text of the code is something I have never seen in my life. I hope I don't offend you, but it is awkward. The structure of the code is not visible when you use closing curly brackets like that. Did you use a different language before ?
Dear Koepel,
Many thanks.
Yes, the code (unchanged) works on the slave Uno perfectly but absolutely not on the slave Pro Mini!
The Uno is my reference, since chip and pins are equal.
I think common ground, volatile, et cetera can't be the reason.
Pull-up resistors? 10k are as high to let I2C block the digital pins 10 and 11 as well?
And why can I simulate the problem on a slave Uno by deleting all Wire.h related code?
My background:
Yes, I have learned more than one language.
If I read/write a code, I don't see brackets. I see the horizontal position of the code lines only.
Perhaps your wiring is wrong or the Pro Mini is wrong.
Could you show a photo of the wiring of the Pro Mini ?
Perhaps the label on the Pro Mini for A4 and A5 are swapped, or perhaps the A4 and A5 are not connected to the microcontroller.
You might have to make a test sketch that set a pin high and low and measure if the matching pin on the board is really high and low.
Don't do such a test with a I2C device connected, it might pull SDA or SCL low and if you happen to set that pin as output and high, then there will be some kind of shortcut.
Problem solved.
The killers were the pull-up resistors.