BasicMicro - Forums

I've been trying to interface a Wii nunchuck with a Basic Micro Nano 28x with no luck I wonder if anyone has tried to do this with sucess.
Wiring wise, the nunchuck is powered by a seperate 3.3v supply sharring a common ground with the Nano. The data line is connected to p12 and the clock is connected to p11. Both lines are held high with 4.7k resistors. I have also tried this with no resistors. The Address = 0x40 and the Device Name = 0x52. A Null ( 0x00 ) is sent to request data be sent from the nunchuck.

A code snippet:

I2CData con P12
I2CClock Con P11
DataByte Var word
Main
i2cout I2CData, I2CClock, 0x52, [0x40, 0x00]
i2cin I2cData,I2cClock, 0x52, [dec databyte]
Serout p20, i9600, [Dec DataByte,13]
Goto Main

The program does not want to drop below the i2cout statement.
I have read that some processors are too slow (Basic Stamp and standard Picaxe chips) but the Picaxe x2 parts, the Propeller or the arduino are quick enough. The Nano 28x should be as fat or quicker than these 3. I've looked at the Picaxe code for interfacing it to a nunchuck, but can't transilate it to Basic Micro. The Arduino is programmed in C, which I don't know.

Any suggestions as to what I can try next?

Thanks in advance
Jim

Post the C code and we may be able to help or determine the problem. The problem may be the time it takes to go from one basic command to another. Is there iny info on what the speed has to be?

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Hi Nathan,
Thanks for the reply! I don't know what the actual speed is, but the nunchuck uses the fast protocol. (theres also a slow one.) I've been reading all I can on the subject and the only number I've seen posted is 40000. I'm not sure if that is the speed, but they said that it needed to be put in the library. I assume it means a C file. I also found a video of a guy who managed to hook it up to a Basic Atom (Pro?) but he showed no code. I also read somewhere that the nunchucks are capable of some speed adjustments. I hope this helps. What I've seen done with the Arduino is great, I think it would be even greater if we can port this to Basic Micro.




Thanks for your help
Jim

I think 40kbps is too fast for the Nanos, maybe even for the Nano28X(20mhz chip). I think the guy who did it was using an AtomPro which is significantly faster.

But, I2C is a clocked serial system. Slave devices(eg the Nunchucks) are supposed to work at the supplied clock speed. It may have a minimum speed which it will ignore any clock slower but it will not just run too fast.

So you have this working on an Arduino? Do you have a scope? If so you could compare the 2 signals, arduino/nano and see how much difference there is in the speeds and maybe see any differences in send/received data.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Nathan,

Once again, thanks for the reply.

I don't have an Arduino. (wouldn't do me any good, don't know C) What I have been doing is internet searches on nunchuck interfacing. The Arduino had the most hits.

Don't have a scope yet, one of these days. I do have a Atom Pro, 28 pin. I think my next step will be to try to get that to work with the nunchucks. Might have to wait a week, going on vacation. I'll post the results when I can.

Couple of questions about I2C. Do the I2Cin and I2Cout commands automatically determine what speed to use based on the device? Also, if I2C is a serial system, can serlin and serout commands be used to acomplish the same thing? The nunchuck requires a 0x00 be sent to request data, similar to the MAX Sonar devices I am using. Maybe go that route?

Jim

I believe by default the Arduino initialize I2C to 100khz, using the Atmega hardware I2C. I know that the for example the PIC that is used in the Nano 18 does have I2C support, not sure how fast you can make it run. It also looks like the SCL/SDA lines are exported as data lines.

As Nathan mentioned, I2C is a clocked serial system. What that means is for each data bit that is sent or received to the Nunchuck, another IO line is used to pace the IO, that is this unlike normal async communications (serin/serout), that rely on specific timing. So in principle I2C should be much more forgiving of timing, unemotionally it also implies that you can not user serin/serout to talk to the Nunchuck.

Good luck
Kurt

Thanks for the input Kurk.

I've had a chance to hook the nunchuck to my Basic Pro 28. Still can't get it to drop below the first i2cout line.
I noticed in the manual that the control byte is 8 digits long.
Soooooo when I converted the hex numbers to binary, I got

Device name = 0x52= 1010010 (7 digits)
Address = 0x40 = 1000000 (7 digits)

However when I added them togeather (1010010 + 1000000) I got 10010010, an 8 digit number. . I have used this number with no luck. I have also tried to use the most significant bits from each with no luck. (1010 and 1000 = 10101000). Have I done this correctly to come up with the correct control byte? Is there something in the way i2c functions that would prevent a program from going to the next line?

Thanks again guys for your help
Jim

Sorry but it doesn't work that way. 0x52 is still 8 bits no matter how you represent it(eg %1010010 or %01010010 are the same number).

Adding the device id and address isn't how it works either.

I2C commands require a command byte. This byte has the device ID in the high 4 bits(bits 7 to 4) and the address in bits 3 to 1 and the type of command(read or write) in bit 0. We ignore bit0 in the serin/out commands because we already know what that bit should be and set it appropriately so you can ignore it.

Where are you getting the device name and address from? That is proabbly supposed to be sent as data(after sending a command byte).

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Trying everything I can. The ID and the addresss come from this C code snippet and elsewhere:

Wire.beginTransmission (0x52); // transmit to device 0x52
Wire.send (0x40); // sends memory address
Wire.send (0x00); // sends sent a zero.
Wire.endTransmission (); // stop transmitting

Parallax code for the SX/b has it this way

I2C_Start
I2C_Send $A4
I2C_Send $40
I2C_Send $00
I2C_Stop

And code for the Picaxe is as follows

Symbol nunchukaddress = $A4
hi2csetup i2cmaster, nunchukaddress, i2cslow, i2cbyte
hi2cout ($40,$00)

As you can see, in the first 2 examples, the address and ID are transmitted seperatly and both are 8 bit numbers. Thats why I tried to put the 2 numbers togeather. Also note that the Picaxe does things a bit differently, kinda like hserin/out.

Jim

An update

I have been able to get the nunchuck interfaced to a Picaxe 28x2 chip. ( based on the PIC18F2520 ) Though I clock this chip with a 16 mz res, the clock speed must be slowed in the program by using a command modifier (_16) This gives the chip a speed of 8 mhz. According to the Picaxe data sheet on I2C, I2C devices come in 2 basic speeds, slow - 100,000 HZ and fast - 400,000 HZ. Both fast and slow can be used at slower speeds. (there is a third standard over 400K, but that is rarely used) The nunchucks run at the slower speed of 100k.

The basic code with the Picaxe is:

A little explanation; In the hi2csetup line,i2cmaster sets the processor as the master, $A4 is the nunchucks address, I2cslow_16 tells the processor what the device speed is and i2cbyte tells the processor that the device recieves data in bytes as opposed to words (2 bytes).

Note that here, my circuitry is being powered by 5 volts and not the 3.3V I used with the Basic Micro.

Soooo, there are a few differences here as opposed to what I did with the Basic Micro. Next step is to try and reconcile these with the Basic Micro chip.

I'll post my results as soon as I can. If any one has suggestions, please chime in.

As always, thanks
Jim

oooh - kayyyy.
In your PICAXE code you have "i2cwrite" on one line, and "write12c" on another.

In the original post, you ran the Wii Nunchuck on 3.3V, but the Atom28X was using 5V. So how do you mean you ran it at 5V this time? The nunchuck or the processor? If the Wii part, try using the Wii with the Atom28X using 5V on both.

And have fun doing it.
ken

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/

Thanks Ken for chiming in. I'll try to answer your questions.

The Wii Nunchuck is a 3.3 device. What I originally did was use a 3.3 power supply to power the nunchuck, the Nano 28x was supplied with 5v.. I also ran a ground from the 3.3 supply to my Basic Micro board. The pull up resistors were put on the +5v line.(this is a custom board and fairly easy to do. This board was designed with i2c in mind and has a jumper to supply the device with 3.3 or 5v. ). I did not use 5v at first because of the nunchucks 3.3 v requirement. As reported, no luck.

I have about 20 documents on the nunchucks and a few of them suggested that the nunchucks will run on 5v without a problem. (I have seen suggestions where 5v may shorten the life of the Wii device, but no one is reporting so. I had mine hooked up for about 6 hrs yesterday and had no ill effects) Being that my Picaxe hardware (bread board) is a lot harder to wire, I elected to try 5v. It worked. Interestingly, I managed to reverse the pos and neg voltage when I first hooked it up to 5v and caused my regulator to heat up. The nunchuck survived. Must be a pretty robust device. Also, the Picaxe worked with and without the pull up resistors. I have since gone back and tried the nunchucks on a Nano 28x and a Atom pro using 5v to power the nunchucks and still had no luck.

On to programming. Most of what follows are from comments and docs. on C postings. I don't know C but I can read their comments. Very little documentation has been posted in my Picaxe postings.

First the numbers:

0x52 is supposed to be the device address.
0x40 is supposed to be the device name (I now question that)
0x00 is used to request data from the device.

I'll try to answer your question first. As I understand it, the first i2cwrite is used to initiate the nunchuck and is only needed once in a program. After that, you only need to i2cwrite a 0x00 to request data.

I have tried this and about a hundred varients on the Nano and Basic Atom Pro with no luck. I have not even been able to get the program to go to the next line after using an i2c command.
(i.e. i2cout I2CData, I2CClock, 0x52, [0x40,0x00]. The program hangs no matter what varients of the numbers I use. As Spock might say, when the obvious don't work, it might be the inobvious. So I have swapped all the numbers in one way or another. I have also used binary.

The Basic Micro i2c command calls for a control byte which,according to the manual sets the device name and address. This control byte is a 8 bit number. However, the address and device ID numbers I have are individually 8 bit numbers and thus not, on the face of things, compatable with Basic Micro. I mentioned in a previous post, that I tried a varity of methods to combine the the 2 numbers. None worked and Nathan shot down my reasoning.

Soooo, at this point, I'm at a loss as to what the problem is. I'm sure it is something stupid (me), it always is.. But I'm not ready to give up yet. I'm leaving for vacation tomorrow,so I won't be able to test hardware until I get back.

As always, thanks for your help
Jim

It looks like A4 is your control byte? Please confirm this. The control byte is what has to be sent before anythign else. If the device doesn't get this it will not respond.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Thanks for replying Nathan

A4 is the address. With the picaxe, it only has to be used once when setting up the program. 0x40 is supposed to be the device name, but I now believe it to be a control byte (or command). . In Pic basic, it also needs to be sent once. After the i2c command is set up, only 0x00 needs to be sent to request data.

In Basic Micro, I have placed all the above numbers in all possible spots and have also done the same in different number formats, binary, hex etc.

My program does not fall to the next line after an i2cout using any combination.

I suspect that I am giving a bad explanation as to what I am doing. If I can clarify further, let me know.

As always, thanks in advance.

Jim

If the i2cout command just freezes, this means the i2cout command is not getting an ack back from the device. You can set a timeout to get out of this but that won't get the device working. It will just stop the module from freezing. It appears the nunchucks aren't recognizing the signal. It could be too fast on the atompro. We don't have any option to slow this down right now. It's set to go at or less than 100kbps though so any i2c device should work just fine. Are you using pullups on both line(clk and data)?

We may have to make this a project we do to figure out why this is an issue. I don't currently have access to any wii nunchucks but I'll try to get my hands on one.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved