Sunday, September 8, 2013

Week 4: Software-side of the I2C communication

I haven't received the NXT for experimentation yet, and I apologize the next few entries may be somewhat short. In the meantime I've been covering some ground on how the software will implement I2C communication between the NXT and ChipKit.

Looking into the ChipKit, it appears that when they say "Arduino Compatible", they really mean Arduino-022 compatible. I'm not going to be sure if this is an issue until I test on hardware, but I just want to note that Arduino-022 and the related libraries are very much out of date. As of late 2011, the Arduino Foundation has released the much newer Arduino v1.0, and all library development has migrated to support that codebase. As many of the v1.0 core libraries are not backwards compatible with Arduino-022, I'm going to have to rely upon the older libraries. I'm not entirely sure what this spells for documentation purposes.

In particular, the library needed will be the Arduino Wire library. This is the Arduino library responsible for managing any hardware I2C function, and while it is possible to bitbang the communication in software, I'd rather stick with what is established. The Arduino Wire library is very straightforward, requiring the device to be initialized with an I2C bus address and communication interrupt handlers during the init() function. I'll explore this part later when I begin coding the ChipKit side.

On the NXT side, the RobotC API exposes two functions for handling I2C access. They are 'sendI2CMsg' and 'readI2CReply' respectively. The I2C send is fairly self explanatory, it will send a message packet on a particular sensor line (remember there are 4) to a particular I2C address. The readI2CReply will send a data request packet across the bus to a specified address, then proceed to receive a user-program specified number of bytes as a response. I will explore this in further detail once I begin NXT coding.

As an aside, I want to make note of an irregularity with the way the NXT handles I2C addressing. The Arduino must be initialized with a particular bus address, it can be anything but I2C only provides 7-bits of addressing so keep to that range. The NXT must be initialized with the same address so it knows where to address the packets it sends on the sensor data line. Even though the NXT and Arduino are directly connected, they are still operating with I2C and thus use address-based communication. However... the address provided to the NXT in RobotC must first be bitshifted left by 1 bit!!!! For example this makes an Arduino I2C address of 0x0A into 0x14, and so on the NXT side all packets will be addressed to 0x14, while the Wire library on the Arduino must be provided with 0x0A. I'm not sure why this irregularity exists, but I'm rolling with it.

Another aside: It should be possible to daisy chain multiple sensor devices off a single port due to I2C being a bus. I'm not going to explore this, but it's an interesting idea.

Also below is the link to the RobotC NXT API, which contains documentation for all NXT-related functions provided by RobotC.

RobotC NXT API:

http://www.robotc.net/support/nxt/MindstormsWebHelp/index.htm#page=nxt_functions/Sensors_Digital/Sensor%20Digital.htm