As some of you may know, I have been playing around with several different Lynxmotion robots and control most of them using a DIY remote control that communicates to the robots using XBee. Lately I have been experimenting with some different configurations of remotes, including an Arduino based one, that uses a 4D Systems display... For awhile now I have been thinking of building one that uses 2 nunchucks. More background up on the Lynxmotion forum thread (http://www.lynxmotion.net/viewtopic.php?f=21&t=7728
It was easy to connect the first one up to the I2C pin of my Seeeduino Mega board with a prototype Shield, which you can see up in the post (http://www.lynxmotion.net/viewtopic.php?t=5447&p=76220#p76220
Hooking up the 2nd one has been more problematic. That is the nunchuck has a fixed I2C address. So far I have not found anywhere any way to change the address. I have found a few places where people hooked up the two on the same bus, by adding a couple of transistors that are connect up to the SDA line of each of the nunchucks and uses 2 IO lines to enable one or the other... Did not want to go this route. So I decided to try running the 2nd one using a Software I2C. I did find an Arduino Software I2C library (SoftI2cMaster) by William Greiman and downloaded it. I modified the simple test program to read both devices and if anything changes display the values. I also hooked up my Logic Analyzer. When I tried it, I did not get any valid data back on the SDA line (all 0xff values). It appeared like it was ACK and NACKing my bytes properly...
From the logic analyzer I found that this I2C was running at least twice as slow as the hardware version. so I removed the usage of pinMode, digitalWrite, with quick manipulations of the ports (still with interrupt protection). The init function did all of the mapping of Arduino pin numbers to the appropriate port stuff. I then kept changing the delays in the code until the timing was almost identical with the hardware implementation. It finally started to talk after I tweaked the stop bit timing
. But then I found that my reads were still not consistently returning all of the bytes of the data properly. In particular the last couple of bytes. Looking at the timings of the hardware one, it looked like the delay on the reads was not consistent. I finally figured that the nunchuck was doing some clock stretching. So yesterday I worked on this. I now have it working (I think), by delaying a little, then changing the SCL line to input, then setting it's value high (enable PU), then looping while the pin is not high, then switching back to output...
I wonder if instead, I should add some external PU resistors to do this? Also I wonder if anyone else has found an easier way. If anyone else is interested, I could upload my hacked up version of this library. Probably up to my Lynxmotion thread, as I don't know of ways to upload here.