I2C.writeBulk() argument datatype?

[KGB]

We’re trying to send data over I2C to an Arduino. Trying to figure out what the appropriate Python data type would be for the I2C.writeBulk() method.

We appear to be connecting successfully to the Arduino and getting a message received, but are having difficulty with the data contents of those messages.

We are creating the I2C object successfully (the Arduino is listening on address 100):

self.myArduino = wpilib.I2C(wpilib.I2C.Port.kOnboard, 100)

But we’re having difficulty figuring out the correct data type for the writeBulk() method. Both of these fail:

if self.myArduino.writeBulk(‘A’):
if self.myArduino.writeBulk(1):

they raise the exception:

TypeError: writeBulk(): incompatible function arguments. The following argument types are supported:

1. (self: wpilib._wpilib.I2C, data: buffer) → bool

So… what Python data type should we be passing in for data (buffer)?

Thanks in advance!

[msoucy]

My guess is it’s talking about the built in buffer type that was renamed to memoryview in Python 3:

What is Python buffer type for?

[virtuald]

Buffer isn’t a type in python 3, it’s a protocol that objects can implement. Common types that implement the buffer protocol are bytes (but not strings), bytearray, numpy arrays, and memoryview.

[KGB]

Thanks for the tip on memoryview; that was the trick, and we got it working. Here’s our working code:

self.myArduino = wpilib.I2C(wpilib.I2C.Port.kOnboard, 100)
command = 1  
# note that bytes takes an array; in our case we are sending just a single int byte
if self.myArduino.writeBulk(memoryview(bytes([command]))):
...

[Joe_Ross]

Since you are using the onboard I2C port, you should be aware of this issue: Known Issues — FIRST Robotics Competition documentation

[KGB]

Thanks very much for this heads-up about the onboard I2C port. We haven’t seen that hanging problem, but it sounds unpredictable and catastrophic when it does occur.

We haven’t tried anything on the MXP port, but reading the NI RoboRio doc, it seems like we should just be able to move our SCL/SDA wires over to pins 32 and 34 on the MXP expansion connector (and, of course, switch the wpilib.I2C.Port.kOnboard to wpilib.I2C.Port.kMXP). Sound correct?

[Joe_Ross]

Sounds about right

[KGB]

Any idea if this same issue might affect connecting the NAVX micro gyro? We had successfully connected it via the onboard I2C port, but the hang issue you linked doesn’t sound like it’s specific to a particular device. But perhaps the NAVX is somehow known not to generate the problem on the onboard port?

[Peter_Johnson]

Any device connected to the onboard I2C port can trigger the issue.

[KGB]

As follow-up on the topic of NAVX gyro & I2C, we moved our NAVX micro from the onboard I2C port to the MXP expansion connector (pins 30-GND, 32-SCL, 33-3.3V, 34-SDA) and changed the initialization to reference the MXP port:

self.gyro = navx.AHRS.create_i2c(wpilib.I2C.Port.kMXP)

And it works. Thanks again for the heads-up about the bad news on the kOnboard onboard I2C port.