Wii Nunchuck an Arduino

[Siro]

Hallo HaWe,
schau mal bitte hier rein:
https://allaboutmcu.wordpress.com/20...is-is-a-draft/

Auszug:

This will not work with the Wii nunchuck, even though we know its write address(which is 52 by the way, A4 in hex).
For the communication to work – after sending the write adress for the first time – “0x40” must be sent before 0.

StartI2C();
IdleI2C();
MasterWriteI2C(0xA4);
MasterWriteI2C(0x40);
MasterWriteI2C(0x00);
StopI2C();

And again for the knockoff versions of the nunchuck it’s different once more,
there are not only one but TWO handshakes this time around, the cheeky bastards:

StartI2C();
IdleI2C();
MasterWriteI2C(0xA4);
MasterWriteI2C(0xF0);
MasterWriteI2C(0x55);
StopI2C();

StartI2C();
IdleI2C();
MasterWriteI2C(0xA4);
MasterWriteI2C(0xFB);
MasterWriteI2C(0x00);
StopI2C();

Siro

[HaWe]

Hallo HaWe,
schau mal bitte hier rein:
https://allaboutmcu.wordpress.com/20...is-is-a-draft/

Auszug:

This will not work with the Wii nunchuck, even though we know its write address(which is 52 by the way, A4 in hex).
For the communication to work – after sending the write adress for the first time – “0x40” must be sent before 0.

StartI2C();
IdleI2C();
MasterWriteI2C(0xA4);
MasterWriteI2C(0x40);
MasterWriteI2C(0x00);
StopI2C();

And again for the knockoff versions of the nunchuck it’s different once more,
there are not only one but TWO handshakes this time around, the cheeky bastards:

StartI2C();
IdleI2C();
MasterWriteI2C(0xA4);
MasterWriteI2C(0xF0);
MasterWriteI2C(0x55);
StopI2C();

StartI2C();
IdleI2C();
MasterWriteI2C(0xA4);
MasterWriteI2C(0xFB);
MasterWriteI2C(0x00);
StopI2C();

Siro

das kann doch nicht richtig sein - die Nunchuk adresse ist 0x52, nicht 0xA4 und nicht (DEC) 52 !
0x52 wird ja auch von meinem I2C Scanner erkannt...!

Scanning at 400k

0  ** 01 02 03 04 05 06 07 -- -- -- -- -- -- -- -- 
1  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
2  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
3  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
4  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
5  -- -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 
6  -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
7  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ** 
Scan result for i2cclock 400k
found: 9 devices

das einzige, wirklich seltsame ist, dass außer x52 immer auch x01...x07 erkannt werden...
(x68 ist ein zusätzlicher MPU6050 zu Testzwecken)

[Klebwax]

hallo,
ich versuche erfolglos, einen Wii Nunchuck an Arduino (3.3V ARM Cortex) auszulesen. Ich habe 2 Nunchucks ausprobiert, beide verhalten sich identisch.
Vom I2C Scanner wird jeder einzelne bei Adresse 0x52 erkannt, sowohl bei 100kHz als auch bei 400kHz. Pullups sind jew. 4.7k, an den Nunchucks oder I2C Bus liegt es also nicht. (Auch alternativ testweise angeschlossener MCP6050 funktioniert auf i2c)

Spannungsversorgung über 3.3V und GND Buchse.

Seltsamerweise aber liefert der i2c-Scanner auch gleichzeitig I2C Devices an x01 x02 x03 x04 x05 x06 x07 (zusätzlich zu x52), die verschwinden, wenn er abgesteckt ist.

Es sind original-Nunchucks aus einem Wii-Set (IIRC).

Ich benutze zwar kein Arduino, hab aber schon einen Nunchuk (Clone) verschiedentlich zum Laufen gebracht. Wenn man einen funktionierenden I2C Master hat, ist das kein Hexenwerk. Ist halt ein I2C Device wie tausend andere auch. Ich zeig den Code mal in Portionen, damit ich dazwischen ein paar Erläuterungen machen kann.

#include "I2cMaster.h"

#define NUNCHUK_ADDR 0x52

typedef struct {
    int x;
    int y;
    int acc_x;
    int acc_y;
    int acc_z;
    int c_button;
    int z_button;
} nunchuk_data_t;

int NunchukInit(void);
int NunchukStart(void);
int NunchukRead(nunchuk_data_t *data);

Die Adresse ist natürlich 0x52, nur die Arduino-Jünger popeln da immer noch das R/W-Bit mit rein, weil die wohl die I2C-Spec nie gelesen haben oder weil ihnen die Aufteilung eines Bytes in verschiedene Bitfelder intellektuell zu anspruchsvoll ist. Hier wird nur die Struktur für das Ergebnis beschrieben. Das packt man gerne in ein Headerfile.

int NunchukInit(void) {
    I2cStart();
    if(I2cWriteAddress(NUNCHUK_ADDR, I2C_WRITE)){
        I2cStop();
        return -1;
    }
    if(I2cWriteByte(0x40)){
        I2cStop();
        return -1;
    }
    if(I2cWriteByte(0x00)){
        I2cStop();
        return -1;
    }
    I2cStop();
    return 0;
}

Das ist meine Init-Funktion. Hier werden dann die Funktionen aus meiner I2C lib verwendet. I2CStart() bzw I2CStop() erzeugt die entsprechenden Zustände auf dem Bus. I2cWriteAddress() setzt aus der Adresse und R/W das erste Byte des I2C Telegramms zusammen. Die Funktion liefert ACK/NAK zurück, wie es vom Bus kommt. Kommt NAK, wird die Sache abgebrochen. Bei I2cWriteAddress() heißt das typischerweise, es gibt kein Device auf dieser Adresse. So testen die I2C Scanner. Dann wird in das Nunchuk-Register mit der Adresse 0x40 eine 0 geschrieben, um den Nunchuk zu starten. Das findet man in Beispielen im Netz.

Das erste Byte nach dem Adressbyte bei einem Write setzt bei I2C typischerweise den Registerpointer im Device. Hier wird er auf 0 gesetzt.

int NunchukStart(void) {
    // set register address
    I2cStart();
    if(I2cWriteAddress(NUNCHUK_ADDR, I2C_WRITE)){
        I2cStop();
        return -1;       // nunchuk didn't respond
    }
    if(I2cWriteByte(0x00)){
        I2cStop();
        return -1;
    }
    I2cStop();

}

Die interessanten Register im Nunchuk liegen ab Adresse 0, daher muß NunchukStart() vor jedem Auslesen ausgeführt werden. Beim Interpretieren der gelesenen Daten gibt es ein Problem. Die Datenbytes sind "verschlüsselt". Es ist aber eine wirklich simple Funktion, die man auch im Netz findet und bei mir NunchukDecode() heißt.

int NunchukDecode(int data){
    return ((data ^ 0x17) + 0x17) & 0xff;
}

int NunchukRead(nunchuk_data_t *data) {
    int temp;

    I2cStart();
    if (I2cWriteAddress(NUNCHUK_ADDR, I2C_READ)) {
        I2cStop();
        return -1;       // nunchuk didn't respond
    }
    data->x = NunchukDecode(I2cReadByte(I2C_ACK));
    data->x -= 128;             // center the value
    data->y = NunchukDecode(I2cReadByte(I2C_ACK));
    data->y -= 128;
    data->acc_x = NunchukDecode(I2cReadByte(I2C_ACK)) << 2;
    data->acc_y = NunchukDecode(I2cReadByte(I2C_ACK)) << 2;
    data->acc_z = NunchukDecode(I2cReadByte(I2C_ACK)) << 2;
    temp = NunchukDecode(I2cReadByte(I2C_NACK));
    I2cStop();
// decode the last byte
    if(temp & 0x01)
        data->z_button = 0;
    else
        data->z_button = 1;
    if(temp & 0x02)
        data->c_button = 0;
    else
        data->c_button = 1;

    data->acc_x |= (temp >> 2) & 0x03;
    data->acc_y |= (temp >> 4) & 0x03;
    data->acc_z |= (temp >> 6) & 0x03;

    return 0;
}

Hier wird ein Byte nach dem anderen eingelesen, dekodiert und in die Struktur gepackt. Zum Schluß wird das letzte Byte gelesen und die Bits ausgewertet. Wenn ich mich recht erinnere, ist der Nunchuk pingelig, wenn das letzte Byte nicht mit NAK quittiert wird. Er bleibt dann hängen und blockiert den Bus.

Hier noch ein Kommentar zu einer der gezeigten Arduino-lib. Dort wird nie ACK ausgewertet sondern immer weiter gemacht. Das führt dazu, daß selbst wenn der BUS leer ist, immer 0xff bzw 255 gelesen wird. Die Pullups sorgen für eine 1 auf dem Bus. Wenn ich also lese: "ich bekomme immer 255" oder auch andere Zweierpotenzen, die sich aus Umrechnungen ergeben können, weiß ich, daß der Bus klemmt oder das Device nicht angesprochen wird ohne in den Code zu schauen oder das Scope anzumachen.

MfG Klebwax

[HaWe]

hallo,
vielen Dank für deine Infos!

Was jetzt ntl super wäre, wenn man das alles in einen lauffähigen Arduino-kompatiblen Code packen könnte (ich selber kann es wirklich nicht).

Die Arduino Wire class für I2C ist ja schon ein bisschen eigen, aber grundsätzlich ist mir I2C sowieso recht unverständlich: ich selber habe es noch NIE geschafft, irgendeinen i2c-Code für ein Device selber zu schreiben, weder in Arduinisch noch mit Raspi-C/wiringPi noch in Lego-Mindstorms-NXC...)

(PS, ein Scope besitze ich ntl auch nicht, ich bin absolut kein Techniker und habe auch überhaupt keine Ahnung, wie so was funktioniert oder wie man damit umgeht: alles was ich habe ist ein 5EUR Multimeter für Notfälle )

[HaWe]

Update:

dieser Code funktioniert bei einem Arduino Uno und Mega, aber NICHT bei einem Arduino Due (M3) oder Adafruit M4, dort ständig Fehlmessungen:
periodisch immer solche Blöcke:

Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0

ohne mein Zutun dann plötzlich:

Data,255,255,255,255,255,0,100
Data,0,0,0,0,0,100,100
Data,0,0,0,0,1,100,100
Data,32,0,0,0,0,100,100
Data,0,0,3,0,0,100,100
Data,0,0,0,0,0,100,100
Data,0,0,0,0,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,125,129,127,100,0
Data,176,181,177,59,226,0,100
Data,125,228,31,125,41,100,0
Data,125,129,127,10,176,0,100
Data,177,59,226,29,125,100,100
Data,31,125,41,126,255,0,0

dann danach plötzlich wieder ohne mein Zutun:

Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0
Data,255,255,255,255,255,0,0

und absolut keine Beeinflussung der Ausgaben durch Tastendrücke, Potibewegung oder Wii-Bewegung


Sourcecode:

/*
 *  Nunchuk auslesen
 *
 *  funktioniert mit original Nunchuck
 *  UND mit Wirelesse Nunchuck
 *
 *  Pinbelegung:
 *      3.3V  (Kabel rot)
 *      GND   (Kabel weiß)
 *      A4    (Kabel grün)
 *      A5    (Kabel gelb)
 */

#include <Wire.h>

const int dataLength = 6;             //  numer ob bytes to request
static byte rawData[dataLength];      //  array to store nunchuck data

//  construct to create an enumerated list of the sonsor values returned from the nunchuck
enum nunchuckItems  {  joyX, joyY, accelX, accelY, accelZ, btnZ, btnC };

void setup()
{
    Serial.begin(57600);
    delay(500);
    Serial.println("Labels,Xjoy,Yjoy,Xaccel,Yaccel,Zaccel,Z-btn,C-btn,");
    delay(500);
   
    nunchuckInit();
}

void loop()
{
  if (nunchuckRead() == true)
 {
    Serial.print("Data,");          // Data-Header
    Serial.print(getValue(joyX), DEC);
    Serial.write(",");
    Serial.print(getValue(joyY), DEC);
    Serial.write(",");
    Serial.print(getValue(accelX), DEC);
    Serial.write(",");
    Serial.print(getValue(accelY), DEC);
    Serial.write(",");
    Serial.print(getValue(accelZ), DEC);
    Serial.write(",");
    Serial.print(getValue(btnZ), DEC);
    Serial.write(",");
    Serial.print(getValue(btnC), DEC);
    // Serial.write(",0");
    // Serial.write("\n");
    Serial.println();
 }   
    delay(20);     // time between redraws
}

void nunchuckInit() 
{
    Wire.begin();                  //  join I2C bus as master
    Wire.beginTransmission(0x52);  //  transmit to device 0x52
    Wire.write((byte)0xF0);        //  send memory adress
    Wire.write((byte)0x55);        //  send a zero
    if (Wire.endTransmission() == 0)  {   
         Wire.beginTransmission(0x52);  //  transmit to device 0x52
         Wire.write((byte)0xA5);        //  send memory adress
         Wire.write((byte)0x00);
    }     //  stop transmission
}


//  send a request for data to the nunchuck
static void nunchuckRequest()
{
    Wire.beginTransmission(0x52);    //  transmit to device 0x52
    Wire.write((byte)0x00);          //  send one byte
    Wire.endTransmission();          //  stop transmission
}


//  receive data back from the nunchuck,
//  returns true if read successful, else false
boolean nunchuckRead()
{
    int cnt=0;
    Wire.requestFrom (0x52, dataLength);    //  request data from nunchuck
    while (Wire.available ())  {
        rawData[cnt] = Wire.read();
        cnt++;
    }
    nunchuckRequest();      //  send request for next dat payload
    if (cnt >= dataLength)
        return true;        //  success if all 6 bytes received
    else
        return false;       //  failure
}


//  encode data to format that most wiimote drivers accept
// static char nunchuckDecode (byte x)  {
    // return (x ^ 0x17) + 0x17;
//    return x;
// }


int getValue(int item)   {
    if (item <= accelZ)
        return (int)rawData[item];
    else if (item == btnZ)
        return bitRead(rawData[5], 0) ? 0: 100;
    else if (item == btnC)
        return bitRead(rawData[5], 1) ? 0: 100;
}

Nachdem alle anderen bisher von mir verwendeten i2c-Geräte (OLED SSD1306, MPU6050, CMPS11, CMPS12, BME280, BMP280, PCF8574, MCP9808, ADS1115) auf allen meinen ARMs (Due=M3, Itsybitsy M0, Feather M4) funktionieren, auch bei jeder Bus-Geschwindigkeit (insb. 100kHz und 400kHz), und der Scanner auch alle Geräte findet, kann es nicht an der i2c-Verbindung oder dem i2c-Bus liegen, und nachdem der Nunchuk an AVR mit dem Code läuft, sind auch der Nunchuk ok und auch der Code grundsätzlich ok.
Was sein kann wegen AVR/ARM Unterschieden, ist:
die ARMs laufen mit 3.3v, allerdings ist auch der Nunchuk für 3.3V ausgelegt (5V sind an sich zu hoch, werden aber wohl toleriert).
AVRs verwenden als "char" signed char, während ARMs bei "char" unsigned char verwenden.
Ich sehe aber noch nicht, wo das im Code (zB. dem obigen) zu Konflikten führen könnte.

Was jetzt weiterhelfen würde zur Bestätigung und zum Debuggen:

wenn jemand einen funktionierenden Nunchuk besitzt und einen Arduino Due (oder Adafruit M4) und dann guckt, ob er meine Fehlmessungen z.B. mit dem Code von uxomm bestätigen kann.

[Ceos]

was für eine clock-rate hat dein I2C eigentlich?! nicht dass der 400kHz versucht und dein nunchuck einfach nicht mitkommt?
ich konnte jetzt konkret keine infos dazu in den vorherigen posts finden oder habs übersehen

vielleicht muss tdu einfach mal einen gang zurückschalten

[HaWe]

wie gesagt, ich habe grundsätzlich 100kHz und 400kHz mit anderen Geräten und auch einem Scanner (inkl. Nunchuk) einwandfrei getestet, aber per default verwendet Arduino immer 100kHz (auch im Beisp. oben). Auch die AVRs laufen mit dem Code also einwandfrei mit 100kHz mit dem Nunchuk-Code, daran kann es also nicht liegen.
Auch die Pullups waren in beiden Fällen je 4k7.

[HaWe]

der Code oben von mir läuft ja nachweislich mit meinem AVR, nur nicht mit meinen ARMs M3/M4.

[Siro]

Hast Du die Pullups mal auf 1K gesetzt. Ich benutze generell 1K bei 400 KHz.

[HaWe]

ich habe mir dein Link aus dem ersten Beispiel nochmal angesehen udn entdeckt, dass dort überall delay(1) verbaut sind aber auskommentiert

https://github.com/infusion/Fritzing...chuk/Nunchuk.h

kommentier doch mal probehalber die ganzen delay(1) ein und schau ob das zu besseren ergebnissen führt, damit wäre zumindest schonmal sichergestellt dass dein reine ablauf ein timing problem hat oder nicht

wenn es nicht klappt sehe ich das problem defintiv in der wire-lib implementation für die boards due und M4 und kann nurnoch empfehlen sich an deren entwickler zu wenden oder hier auf antwort von jemand mit der gleichen hardware zu hoffen (support aber eben leider nur in englisch ... PS da ist schon ein issue das das gleiche problem beschreibt, kannst du mal die prozessoren benennen die auf den boards verbaut sind, dann könnte ich mal eine antwort in das topic für dich setzen)

edit
falsch verstanden, du meinst ja den Code vom Link!
probiere ich gleich aus!

- - - Aktualisiert - - -

getestet überall mit delay(1) auskommentiert: keine Verbesserung leider (alle Änderungen sporadisch, keine Reaktion auf Tastendruck, Poti, Bewegung)

128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,508,-172,-512,1,1
-127,-128,-512,-512,-512,1,1
-127,-128,-512,144,-384,1,1
-127,-128,-512,-512,-512,1,1
-124,-128,-512,-512,-512,1,1
-127,-128,-512,-512,-512,1,1
-127,-128,511,511,511,0,0
128,127,511,511,511,0,0
-2,1,-3,-469,194,0,1
50,-69,393,-394,-9,1,1
-96,-3,-348,-8,-10,0,1
0,-118,194,215,196,0,0
99,-99,-9,403,-387,0,1
-86,-2,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,508,508,-172,1,1
-127,-128,-512,-512,-512,1,1
-127,-128,-512,-510,144,1,1
-127,-128,-512,-512,-512,1,1
-127,-125,-512,-512,-512,1,1
-127,-128,-512,-512,-512,1,1
-127,-128,-509,511,511,0,0
128,127,511,511,511,0,0
128,-3,4,-1,-470,1,1
54,49,-273,395,-395,0,1
101,-97,-9,-345,-7,0,1
2,-1,-472,195,214,0,1
-68,98,-393,-11,400,0,0
-2,-87,-5,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0
128,127,511,511,511,0,0

meine Boards sind Arduino Due (Original) mit M3 (SAM3X8E) und Adafruit Feather M4 (ATSAMD51)

- - - Aktualisiert - - -

update 2:
der Code von deinem Link
https://github.com/infusion/Fritzing...chuk/Nunchuk.h
funktioniert mit un-kommentiertem delay(1) anfangs immerhin mit meinem Mega2560 und reagiert auch auf Tasten/Poti, aber dann hängt er sich nach wenigen Sekunden komplett auf
In der Originalfassung (auskommentiertes delay(1) ) dagegen ist er immerhin auf dem Mega absolut stabil, genau wie der uxomm-Code.
Nur ergänzend nochmal:
KEINER der auf dem Mega2560 funktionierenden Codes läuft allerdings auf M3 oder M4.

Der Nunchuk ist wie gesagt das erste Gerät, das solche Probleme mit I2C macht, speziell auf den ARM Boards.
ich tippe langsam auch auf clock-stretching Probleme...
Aber ich brauche eben eine Arduino-Lösung mit den dortigen Wire() Bordmitteln.

(editiert)