I am running the standard I2C scanner on the Arduino Uno Q and I wanted to connect an MPU6050. I have already tried connecting SDA/SCL to PIN A4/A5 and D20/D21 but all the addresses return an error value of 1 which from the docs is DATA_TOO_LONG_FOR_TRANSMIT_BUFFER = 1, is 1 the expected error when device for a given I2C does not exist?
I tried Wire, Wire1 and Wire2 but all of them return the same error. Are there more wires and which one corrosponds to which I2C, how do I find similar information? Should I lookup datasheet of the STM chip?
Here is my code:
#include <Wire.h>
// Set I2C bus to use: Wire, Wire1, etc.
#define WIRE Wire
byte val = 0;
void setup() {
WIRE.begin();
Serial.begin(9600);
while (!Serial)
delay(10);
Serial.println("\nI2C Scanner");
}
void loop() {
byte error, address;
int nDevices;
Serial.println("Scanning...");
nDevices = 0;
for(address = 1; address < 127; address++ )
{
// The i2c_scanner uses the return value of
// the Write.endTransmisstion to see if
// a device did acknowledge to the address.
WIRE.beginTransmission(address);
Wire.write(val);
error = WIRE.endTransmission();
if (error == 0)
{
Serial.print("I2C device found at address 0x");
if (address<16)
Serial.print("0");
Serial.print(address,HEX);
Serial.println(" !");
nDevices++;
}
else if (error==4)
{
Serial.print("Unknown error at address 0x");
if (address<16)
Serial.print("0");
Serial.println(address,HEX);
}
Serial.print("I2C error at address 0x");
Serial.print(address,HEX);
Serial.print(" is ");
Serial.println(error);
}
if (nDevices == 0)
Serial.println("No I2C devices found\n");
else
Serial.println("done\n");
delay(5000); // wait 5 seconds for next scan
}
1. SDA and SCL header pins of UNO Q forms the I2C Bus and behaves exactly the same way the I2C Bus of UNO R3 behaves except that UNO Q is a 3.3V device. So, always connect 5V device/sensor with UNO Q using level shifter.
2
From the figures of post #3, if you are convinced the MPU6050 is a 3.3V device, then make the following connection:
Open the attached datasheet of STM32U585 MCU of UNO Q board. Serac for SDA text, you will find that there are four I2C buses that are supported by MCU. STM32U585XX (1).PDF (7.0 MB)
From ARDUINODOCS, find the header pins (SDA/SL) for I2C Bus. In the sketch use Wire.begin();.
So the endTransmission function from the variant of the Wire library bundled with the "Arduino UNO Q Board" platform returns 0 on success, and 1 on any type of error. It doesn't provide the standardized granular error codes claimed by the documentation (which is done by the Wire libraries bundled with other Arduino boards platforms).
I have submitted a report of the inaccuracy of the information in the Wire library reference as it applies to the UNO Q (and other boards of the Zephyr-based platforms) to the responsible parties at Arduino. Thanks for bringing this to our attention. I apologize for any confusion caused by this inaccuracy in the documentation.
Wire.beginTransmission(slaveAddress);
byte busStatus = Wire.endTransmission(); //default arg is true for stop
if(busStatus != 0)
{
Serial.print("Bus error!");
while(true);
}
Serial.println("Slave is present.");
What I see above in the referred quote -- are those lines have defined the endTransmission() method? I mean that the calling to endTransmission() executes all those lines in the background?
I'm not sure "background" is the best way to describe it, as this might be seen as implying it is done asynchronously as the sketch thread proceeds. However, you are correct that when you make a function call like Wire.endTransmission(), the code lines shown in your quote are indeed executed.
In this case where you don't pass an argument to the function, they are actually executed via this overload of the function:
(that this just provides a default value of true for the stopBit parameter)
Returns
A byte value indicating the status of the transmission:
0: success.
1: data too long to fit in transmit buffer.
2: received NACK on transmit of address.
3: received NACK on transmit of data.
4: other error.
5: timeout.
The reduction to 0 and 1 is misleading and the cause has been discovered by @ptillisch ...
The above function clearly returns 1-byte data which is either 0x00 or non-zero (1).
When there are five write() operations within beginTransmission()/endTransmission(), there are six (1 + 5) ACK (0) signals returned by the slave (Fig-1 for a single write()). These ACK signals are effectively combined (logically ANDed, considering their active-low nature) to determine whether the entire transmission was successful. The final result is then reported to the user program as 0, indicating a successful transmission cycle. Therefore, returning 0 for success and 1 for error appears quite logical to me.
The above bytes values 0x00 - 0x05 are created by the application program depending on the status values (Fig-2) produced following I2C transactions. The status values can be observed if one goes with register level proramming.
The slave transmits an ACK by pulling the SDA line low. If there are two write() operations, there will be two ACK events. Including the ACK generated during the address match, there are a total of three ACK events. Based on these ACK responses, the MCU derives a single busStatus value, which is then returned by the Wire.endTransmission() function. I hope this explanation makes sense.
When Wire.beginTransmission(slaveAdd) is seen by compiler, the data bytes that followed by write() code are begin to be queued for onward transmission byte-by-byte and to be initiated by Wire.endTransmission(). All the operations following the recognition of slaveAdd must be successful to generate the final decisin of "Data transfer ok", and this is the fact that has prompted me to use the term ANDed. Hope, I have been able to explan to some extent.
It worked if I used either the 5V or 3.3V power for the MP6050 breakout board. The Adafruit board has voltage level translators for SCL/SDA, your breakout board does not. They both have pull-up resistors on SCL/SDA.
I could not get the Adafruit MPU6050 breakout board to work with Stemma connector on the Uno Q or the Uno R4 WiFi. I tried two different cables. On the schematics for the Uno R4 it shows pull-up resistors and a 3.3 logic interface to the 5V MCU. That means there are two sets of pull-up resistors when connecting to the Stemma connector; one on the breakout board and one on the Uno R4. When connecting to the pin header, there is only one set.
