Wii Nunchuck an Arduino

[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.

[Ceos]

Auch die AVRs laufen mit dem Code also einwandfrei mit 100kHz mit dem Nunchuk-Code, daran kann es also nicht liegen.

nicht zwingend, im I2C protokoll gibt es auch sog. clock stretching und das kann je nach konfiguration (auf die du angeblich laut arduino foren keinen einfluss nehmen kannst) vielleicht zu lange dauern

ich weis zum beispiel aus eigener leidlicher erfahrung, dass ein gewöhnlicher atmega z.b. nur clockstretching bis maximal 25mS erlaubt und dann stumpf weiter taktet (eine konvention des SMBus, weil atmel keine I2C lizenz hatte haben sie einfach den baugleichen SMBus als referenz genommen) ... aber das ist nur als beispiel gemeint, das betrifft dein problem nicht

aber vielleicht gibt es noch andere effekte die mit irgendwelchen timings zusammen hängen

(auch ein kleines beispiel: ein pic schafft es unter umständen mit dem timing im UART einen atmega ins stolpern zu bringen weil der pic die bit timings "zu exakt" einhält und der atmega das stopbit "verpasst")

[HaWe]

hmmmhhh...
das wäre ntl blöde, aber vlt kennt jemand DOCH Tricks, um den Nunchuk mit Arduino-Code auf ARMs anzusteuern...?

Wie gesagt,
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 oben (und seinen Patchs/Änderungen) bestätigen kann.

[Ceos]

ein weiterer Hinweis den ich gefunden habe, zwischen der "Busfreigabe und Busübernahme" (was zum geier auch damit gemeint ist, ich behaupte mal zwischen einem stop und dem folgenden start bzw. zwischen dem stop und restart beim lesen) sollten wohl mind. 300uS Pause sein da sich der Chuck sonst weghängen kann (gerade das klingt plausibel, da die ARMs deutlich schneller arbeiten als atmegas)

wie du das aber realisierst entzieht sich leider meienr kenntnis, aber es klingt stark danach dass der chuck selbst kein clock stretching beherrscht und einfach darauf hofft dass der master nicht zu schnell nachfragt (hab ich auhc schon mit einem signalwandler erlebt, kein clock stretch und einfach nur aufgehängt, weil ich nicht genug gewartet habe)

[HaWe]

danke für die Infos!
Jetzt bräuchte ich allerdings wen, der die Fehler tatsächlich findet und sie "fixen" kann...

[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]

das ist aber sehr weit außerhalb vom Standard, zumal der Due schon eingebaute Pullups hat (nur mit denen allein geht es aber auch nicht). Aber ich kann 2k2 mal am Due probieren - Momentchen...

- - - Aktualisiert - - -

update:
auch kein Unterschied

Ich denke, das einzige was hilft ist, wenn hier jemand , der selber die Hardware hat, es bei sich selber testet.