Week 2: Functional Requirements for the Communications Interface

Last week I investigated the NXT hardware, expanded upon some communications possibilities, and gave a very light preliminary assessment which leaned in favor of the RJ12 sensor ports currently used for COTS NXT sensors.

But before delving into further detail regarding comms, I'm going to take an aside and mention that  Professor Anderson has provided me with the board I'll be interfacing with the NXT. While I've previously been under the assumption that the "Arduino" I'd be using was a reference Arduino Uno, I've been provided with a ChipKit Uno32.

Fig 1. ChipKit Uno32

Upon some reading from ChipKit's website this particular device appears to be a clone Arduino, which claims to be fully "Arduino-Compatible". At first glance it seems far beefier than a reference Arduino Uno, and touts more I/O pins, a more robust microcontroller IC (80 Mhz PIC controller vs the reference Uno's 16 MHz AtMega328 AVR controller), and also a variety of jumpers to configure various board functionality (power regulator/hardware SPI/etc.). I've never worked directly with a ChipKit board before, however I'm banking on the "Arduino-Compatible" part for ease of use.

Back on the comms side as I've previous mentioned, I have opted to go down the RJ12 route. The primary reason for this is that it is likely to be the most documented interface for the NXT, and there is no additional significant hardware required unlike the other approaches I've mentioned. To marginally hash out the factors involved in making this decision:

• I need something workable fast, while I'd love to explore other communications options I'm limited in time and budget
• The likely scenario for this interface is during a class lab or other hands-on segment. Complexity would make achieving the overall goal, basic communications, needlessly difficult.
• The protocols in play are likely either SPI or I2C, and while I'm not an expert, I have experience working with both of these protocols.

Additionally I wanted to throw around some functional requirements of the interface:

• Needs to be capable of both synchronous and asynchronous communications
• Capable of scaling from simple sensor concepts to more involved (possibly DSP-heavy) sensors
• Not likely to be used for "high-speed" comms, here defining "high-speed" to be in excess of the capabilities afforded by I2C or SPI. However, should be capable of continuously passing data at a rate commensurate to the NXT's maximum sensor poll rate.

Given that the on-board comms (UART/USART/PCB-based SPI) are not directly exposed by the hardware, the requirement for simplicity rules out these options. Bluetooth is a contender up to the point where additional hardware in the form of an Arduino-based radio is required; I'm all for this research but budget constraints limit my frivolity with component selection.

Research into current NXT sensors and their interfaces indicated that while the sensor ports are reconfigurable to a degree, the digital COTS sensors default to I2C based communication. And thus I2C it is.