I2C Communication between RoboRIO and Arduino

[CSkillet]

Hello,
So I've been trying to send data from the RoboRIO to the Arduino UNO using the Transaction() function of the I2C Class of the C++ WPILib. I have the address all connected, because AddressOnly() returns false, meaning a success. However, Transaction() returns true, meaning the process aborted, and that's my problem. It's not a problem on the Arduino side because its not receiving any data at all.
I have switched off and on between using the built in I2C port and the MXP port on the RoboRIO, but neither have worked. I have the SDA, SCL, and Ground pins set up, but not the voltage, as the Arduino would not operate at 3.3V. Moreover, I just have the Arduino plugged into a computer. I would assume the wiring is good because the RoboRIO can sense that there is a device at the Arduino I2C address.

Here is some of the code on the RoboRIO side:

Header File (.h):

char START_INDICATOR = 'S';
unsigned char byteDataToSend;
unsigned char* CONVERTED_START_INDICATOR;

.cpp File

CONVERTED_START_INDICATOR = new unsigned char;

byteDataToSend = reinterpret_cast<unsigned char&>(START_INDICATOR)
CONVERTED_START_INDICATOR = &byteDataToSend;

i2C->Transmission(CONVERTED_START_INDICATOR , 1, NULL, 0)


Any help is appreciated, thanks

[NHollander]

In order to get the arduino to communicate over I2C, I found that it is necessary to connect all 4 pins from the RoboRIO socket to the appropriate terminals on the arduino.

For our robot this year, we had a Teensy LC controlling LED strips, which were controlled over I2C. For the longest time, we could not get the RoboRIO to talk with the arduino, even when it saw an I2C device was present.

In order to get it to work, we had to have the 4 wires from the RoboRIO, as well as 5V coming from a second VRM, which also supplied the power necessary to drive the LED strips. One additional challenge we ran into was dealing with finding the appropriate pullup to use. In the end, we settled with the internal resistors, which were larger than necessary, and therefore resulted in less than ideal communication speeds, but it worked.