i2c woes

danielstritt

I was wondering if there was currently an issue I'm not aware of, that prevents I2C from working using PropGCC? Most specifically, I am trying to get a Wii Nunchuck or Classic Controller to work (as in read button states). I am using the Wii Nunchuck and Classic Controller Drivers by Pat Daderko that I downloaded from the object exchange. Basically, I tried to convert them using spin2cpp with the commands --ccode and --main (on the Test*.spin demo files, not the drivers). The only modification to the files is the pin numbers used to communicate over I2c. I am using a Gadget Gangster Quick Player so I changed them from 28/29 to 22/23. In the spin tool, the files run fine. But converted to C it give me garbage values. Then I tried to load the spin file directly in SimpleIDE, and compile the demo file as a spin file. That gave all 0's as the returned values. I even tried writing my own simple code to communicate with the device, but I have little experience with that protocol, so I could have just made a mistake since that didn't work either.

Im sorry about the generallities, I know those never help. But it's late, and ive been working on this issue for days before I realized PropGCC is still considered beta, and maybe this feature isn't working yet.

Any Ideas? I really want to work just in C/C++ on the prop.

Thanks,
Daniel

SRLM

PropGCC has an I2C driver included with the distribution: https://code.google.com/p/propgcc/source/browse/lib/include/i2c.h?r=0eaa4e957d3df2949c97157faff8e959c18f44fb

This thread may be useful: http://forums.parallax.com/showthread.php?142296-multi-byte-i2c-with-current-interface-is-it-possible

As for your specific code: can you post what you have, and the outputs? I'm having similar problems (partially garbage values) with a spin2cpp serial object. It might be the same issue from both.

Also, maybe try making it a C++ project (instead of C with --ccode), and see if that works.

blindstar

What memory model are you using? I have found that the i2c driver does not work in xmmc, xmm - single, xmm - split, however it works fine in lmm.

-mark

David Betz

blindstar wrote: »

What memory model are you using? I have found that the i2c driver does not work in xmmc, xmm - single, xmm - split, however it works fine in lmm.

-mark

It should be possible to use the i2c driver with xmmc programs. I'll have to try it out later to see what the problem is. There is no reason that this shouldn't work. The other xmm modes should also work and may once I find out what's preventing xmmc from working. Sorry for this problem!

jazzed

If you are running XMMC from EEPROM, it's best to use a different set of pins for I2C.
P27/28 can be shared via a some advanced methods.

ersmith

Drivers converted via spin2cpp may not always work correctly. One potential source of problems is timing: the Spin interpreter is a lot slower than C or C++ code, and unfortunately some drivers implicitly rely on the slow speed of the interpreter for delays and such. Another possible problem is that the C code sometimes requires explicit "volatile" qualifiers to be inserted on variables that are used by other COGs. You didn't mention which optimization settings you're using, but the volatile issue usually arises with code compiled with -Os or -O2. You could try -O1 or even -O0 to see if that works better.

Eric

David Betz

jazzed wrote: »

If you are running XMMC from EEPROM, it's best to use a different set of pins for I2C.
P27/28 can be shared via a some advanced methods.

Ah, I didn't realize he was using xmmc with the eeprom cache driver. That would certainly require special handling. It isn't too difficult using the i2c driver in the library but it might be difficult or impossible to share 28/29 with a Spin driver converted with spin2cpp.

blindstar

I have not been able to get any of the i2c open commands to work (they never return) compiling to xmmc running from of flash or the sd card (the same code runs fine when compiled to LMM). This could very easily be me as I have not written any c for a vey long time. Would one of you be willing to try and use the i2c drivers (just an open) and tell be that they work in xmmc?

danielstritt

I forgot to mention, I am doing this in LMM, but I did try other options, just so see if it worked, and had similar results. I also tried all the different optimizer settings. I'm wondering if it's just my code. I know it won't help anyone unless they have experience interfacing Wii accessories to the prop.

nu.c

I noticed the Arduino code for the Nunchuck driver is different, using the i2c address of 0x52, and sending just 2 bytes to handshake (0x40, 0x00), but that never worked for me either.

David Betz

danielstritt wrote: »

I forgot to mention, I am doing this in LMM, but I did try other options, just so see if it worked, and had similar results. I also tried all the different optimizer settings. I'm wondering if it's just my code. I know it won't help anyone unless they have experience interfacing Wii accessories to the prop.

nu.c

I noticed the Arduino code for the Nunchuck driver is different, using the i2c address of 0x52, and sending just 2 bytes to handshake (0x40, 0x00), but that never worked for me either.

I just realized that I have one of the Quick Player Extreme boards and a Wii controller. I'll try your code later.

danielstritt

Hmm, seems like the problem isn't the compiler, but me. I realized the EEPROM uses I2C to communicate, so I wrote a simple program to write to it, and read it back. Worked fine. So the problem is my driver for the nunchuck. I just need to keep trying I guess

David Betz

danielstritt wrote: »

Hmm, seems like the problem isn't the compiler, but me. I realized the EEPROM uses I2C to communicate, so I wrote a simple program to write to it, and read it back. Worked fine. So the problem is my driver for the nunchuck. I just need to keep trying I guess

I'm glad you were able to verify that i2c communications was working for you. I had intended to try your code on my QuickStart board last night but ended up spending all of my time working on Propeller 2 code. I still want to try your code and understand the nunchuck protocol because I've wanted to use it myself. Keep us posted on your progress.