Wii Nunchuck an Arduino

[HaWe]

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

[Siro]

Ich habe evtl. noch eine Idee.
Ich hatte mal Probleme weil ich mein NACK nicht oder zu spät gesendet hatte,
wenn ich mir den Code ansehe, kommt dein NACK evtl. zu spät.
Du liest alle Daten ein, jeweils mit einem ACK
Am Ende liest Du nochmal ein "Dummy" ein mit dem NACK. Da gibt es garnichts mehr zulesen.
Das NACK muss meines Wissen nach direkt beim letzten Byte gesendet werden
(Das ist nur ein Vermutung)

Kannst Du das mal ausprobieren:

data->acc_z = NunchukDecode(I2cReadByte(I2C_NACK)) << 2; // hier schon das NACK
// temp = NunchukDecode(I2cReadByte(I2C_NACK)); // die Zeile weg.

Verschiedene Chips scheinen sich hier unterschiedlich zu verhalten.
Bei mir ging es zunächst, dann hab ich ein anderes EEPROM gehabt und da trat erstmals der Fehler auf.

Siro

[HaWe]

die Zeile finde ich nicht...

/*
 *  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;
}

[Siro]

Achso, sorry, das war der Code von Klebwax

[Klebwax]

Ich habe evtl. noch eine Idee.
Ich hatte mal Probleme weil ich mein NACK nicht oder zu spät gesendet hatte,
wenn ich mir den Code ansehe, kommt dein NACK evtl. zu spät.
Du liest alle Daten ein, jeweils mit einem ACK
Am Ende liest Du nochmal ein "Dummy" ein mit dem NACK. Da gibt es garnichts mehr zulesen.
Das NACK muss meines Wissen nach direkt beim letzten Byte gesendet werden
(Das ist nur ein Vermutung)

Kannst Du das mal ausprobieren:

data->acc_z = NunchukDecode(I2cReadByte(I2C_NACK)) << 2; // hier schon das NACK
// temp = NunchukDecode(I2cReadByte(I2C_NACK)); // die Zeile weg.

Du beziehst dich auf meinen Code. Zuerst, er funktioniert. Und das nicht zufällig. Ich lese das letzte Datenbyte nach temp ein, weil ich es anschließend weiter bearbeiten muß. Das ist, wie man aus dem weitern Code leicht sehen kann, kein Dummy-Read. Und da es das letzte ist, quittiere ich es mit NAK. Im letzten Byte stehen die Tasten und die Restbits der ACC-Werte.

Verschiedene Chips scheinen sich hier unterschiedlich zu verhalten.

Richtig. Mache funktionieren, obwohl man das letzte Byte nicht mit NAK quitiert, sich nicht an die I2C Spec hält. Da sieht man mal, wie gut I2C funktioniert, selbst wenn man etwas falsch macht. Hättest du es gleich richtig gemacht, wäre dir ein unterschiedliches Verhalten gar nicht aufgefallen.

Aber, wie schon gesagt, HaWe verwendet anderen Code.

MfG Klebwax

[HaWe]

Richtig. Mache funktionieren, obwohl man das letzte Byte nicht mit NAK quitiert, sich nicht an die I2C Spec hält. Da sieht man mal, wie gut I2C funktioniert, selbst wenn man etwas falsch macht. Hättest du es gleich richtig gemacht, wäre dir ein unterschiedliches Verhalten gar nicht aufgefallen.

Aber, wie schon gesagt, HaWe verwendet anderen Code.

MfG Klebwax

wenn ich dich richtig verstehe, benutzt du aber (auch) nur einen AVR, oder?
Mit AVRs funktioniert es aber doch auch mit "meinem" Code!
Oder hast du es bei dir mit einem Due oder M4 erfolgreich getestet? Das wäre ja erstmal die erste Hürde.

[Klebwax]

wenn ich dich richtig verstehe, benutzt du aber (auch) nur einen AVR, oder?

Nein, ich habe keine AVR/Arduino. Ich benutze PICs. Der Code funktioniert auf PIC16xx (8 Bit) und auf PIC24xxx (16 Bit). Das Ganze nach lua umgesetzt funktioniert auch auf dem ESP8266 (ich benutze die lua-Firmware). Und der Python-Code für den Raspi, den ich im Netz gesehen habe, macht das genauso. Bin aber noch nicht dazu gekommen, meinen Nunchuk am Pi zu betreiben (zu viele Projekte). Ich verwende I2C häufig, baue mir auch meine eigenen Slaves aus kleinen µC, Um der Frage zuvorzukommen, ich verwende i.d.R. keine libs. Ich benutze die nur als Anhaltspunkt, wenn mir etwas im Datenblatt unklar ist. Im Vergleich zu anderen Prokollen/Schnittstellen ist I2C so simpel, das es eigentlich schneller ist eigenen Code zu schreiben, als fremde Libraries wirklich zu verstehen.

Mit AVRs funktioniert es aber doch auch mit "meinem" Code!
Oder hast du es bei dir mit einem Due oder M4 erfolgreich getestet? Das wäre ja erstmal die erste Hürde.

Wenn C-Code (oder auch C++) nur auf bestimmten Prozessoren funktioniert, ist er Schrott und da, wo er geht, ist es eher Zufall.

    Wire.write((byte)0x55);        //  send a zero

Wenn ich dann auch noch so etwas lese, wundert mich das nicht. Was nun, 0x00 oder 0x55? Das kann beim Debuggen mal vorkommen, aber das veröffentlichen? Da hat jemand, das was er gemacht hat nicht wirklich ernst genommen.

MfG Klebwax

[HaWe]

Andere Codes, die wenigstens bei Arduino-AVRs funktionieren, hier schlecht zu reden, ist ziemlich billig....
Allerdings: PICs sind hier nicht das Thema, und auch Arduino AVRs sind nicht das Thema, sondern alleine Arduino-Code für die M3 und M4 Cores. Außerdem steht immer noch im Raum, dass möglicherweise der Nunchuk wegen clock-stretching oder wegen elektrischer Probleme etc. noch nicht mal 100%ig sicher auf jedem i2c-Bus mit jedem Board läuft.
Solange also dein Code nicht Arduino-ARM-kompatibel ist und noch nichtmal getestet werden konnte, nützt es nichts, und dein Code müssste dazu auch erstmal für M3/M4 in Arduinisch überhaupt zur Verfügung stehen - und darauf wäre ich wirklich gespannt.

[Ceos]

Darf ich hier mal kurz reingrätschen und darauf hinweisen, dass wir nciht bare-metal sondern arduino und nodeMCU (das meintest du doch mit lua oder?) bibliotheken reden?

das bedeutet dass die implementation der lib für das jeweilige board durchaus äußerst unterschiedlichen sein könnte und @HaWe dein Problem gehört streng genommen in den Arduino Bugtracker, denn es kristallisiert sich immer mehr heraus dass wohl an der lib für die due boards etwas nicht stimmt dass dein nunchuck ins stlpern bringt!

ich lege nochmal dringend ans herz zu prüfen ob du irgendwie delays zwischen dem start und stop conditions einfügen kannst oder beim auslesen zwischen schreiben der registeradresse und dem beginn des lesens, vielleicht löst das dein problem schon aber ganz ohne oszilloskop um die signale zwischen den boards zu vergleichen wird das nichts

schau mal ob du dir nicht einen günstigen logic analyzer besorgen kannst oder vielleicht sogar mit einem zusätzlichen board einen DIY logic analyzer bauen kannst

mir ist klar dass du normal immer auf libs setzt um dich nciht mit sowas auseinandersetzen zu müssen, aber die libs werden auch nur von menschen geschrieben und könen fehler beinhalten (und darauf wette ich in diesem fall sogar)

[Ceos]

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)