Wii Nunchuck an Arduino

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

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.

Ich sehe grad, Klebwax erwähnte schon:

Zitat:

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

Das war auch meine Vermutung gewesen.
Wie das bei deinem Code genau abläuft lässt sich schlecht nachvollziehen, das kommt ja aus einer Bibliothek.
Bleibt wohl wirklich nur jemand übrig, der es schon lauffähig geschaft hat.
Ein Versuch war es wert.

Siro

ja klar, danke, die 2 Widerstände zu wechseln war ja kein Aufwand 8)
Mit i2c Steuer-Code kenne ich mich allerdings überhaupt nicht aus.

Ich hab hier auch noch etwas gefunden.
https://oscarliang.com/wii-nunchuck-arduino-tutorial/
Nach jedem kompletten Empfang ruft er anscheinend diese Funktion auf,
sonst funktioniert die Synchronisation wohl nicht.

Code:

void NunC_SendNextByteRequest() { // I don't know why, but it only works correct when doing this exactly 3 times // otherwise only each 3rd call reads data from the controller (cnt will be 0 the other times) for(byte i = 0; i < 3; i++) { Wire.beginTransmission (WII_NUNCHUCK_TWI_ADR); // transmit to device 0x52 Wire.send (0x00); // sends one byte Wire.endTransmission (); // stop transmitting } }

Das spricht irgendwie dafür, dass der nunchuck sich "verheddert"

Siro

was soll ich davon wann und wo aufrufen, bzw. wie sieht dann mein neuer Komplett-Code aus?
der Autor bezieht sich allerdings auch auf AVRs, und mit AVRs klappt es ja bei mir mit dem obigen Code von uxomm - nur nicht mit ARMs...:confused:

Ich muss mich wohl entschuldigen HaWe,
ich hatte das Problem nicht (eigentlich garicht) richtig verstanden (schäm) :p

Es tritt nur auf, wenn dein DUE mit dem nunchuk verbunden wird.
Die anderen I2C Chips am DUE laufen einwandfrei.
Der nunchunk am AVR hingegen läuft auch wiederum einwandfrei.

Der Scanner zwischen DUE und nunchuk laufen auch richtig.
ABER: jedoch sieht das nur so aus weil x01...x07 nicht sein dürfte.

Ich grüble schon ne Weile woran das liegen kann.

Um den I2C BUS zu scannen gibt es 2 Möglichkeiten,
mit Read oder mit Write, das könnte ein Problem werden.
Eventuell scannt die AVR Lib anders als die DUE Lib

Kannst Du mal das Scannen ausklammern, vielleicht passiert dabei irgendeine Schweinerei.
Vielleicht haben die sich bei Nintendo da irgendwas implementiert, man weis es ja nicht.
Ich weis nicht ob Du das beim Starten generell machst.

Oder nächster Versuch, gibt das Scannen am AVR auch die 0x1..0x7 raus ?

Siro

:)

am AVR (Mega):
bei 400kHz: ja, ebenfalls; seltsamerweise sogar auch noch 78...7E

bei 100kHz auch, aber mit i2c Error 4 (dargestellt als ?? )
https://github.com/arduino/ArduinoCo...ity/twi.c#L224

Code:

Scanning at 100k 0 ** ?? ?? ?? ?? ?? ?? ?? -- -- -- -- -- -- -- -- 1 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 5 -- -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 6 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 7 -- -- -- -- -- -- -- -- ?? ?? ?? ?? ?? ?? ?? ** Scan result for i2cclock 100k found: 1 devices error: 14 devices Scanning at 400k 0 ** 01 02 03 04 05 06 07 -- -- -- -- -- -- -- -- 1 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 5 -- -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 6 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 7 -- -- -- -- -- -- -- -- 78 79 7A 7B 7C 7D 7E ** Scan result for i2cclock 400k found: 15 devices error: 0 devices

- - - Aktualisiert - - -

dies ist mein Scanner Code:

Code:

// -------------------------------------- // i2c_scanner // // This sketch tests the standard 7-bit addresses // Devices with higher bit address might not be seen properly. // #include <Wire.h> #define ESP_SCL D1 //GPIO5=D1 SCL ESP8266 default #define ESP_SDA D2 //GPIO4=D2 SDA ESP8266 default byte error, address; int nDevices, nDeverr; void setup() { //Wire.pins(D2, D1); // change only if not default Wire.begin(); Serial.begin(115200); while (!Serial); // Leonardo: wait for serial monitor Serial.println("\nI2C Scanner"); } void loop() { static uint32_t i2cclock = 10000; int iores; nDevices = 0; nDeverr = 0; if(i2cclock==10000) i2cclock=100000; else if(i2cclock==100000) i2cclock=400000; /*else if(i2cclock==400000) i2cclock=1000000; */ else if(i2cclock==400000) i2cclock=10000; Wire.setClock(i2cclock); Serial.print("\nScanning at "); Serial.print(i2cclock/1000); Serial.println("k"); for(address = 0; address < 128; address++ ) { if (address%16 == 0) { Serial.println(); Serial.print( (address+1)/16); Serial.print(" "); } if(address==0 || address==127) { Serial.print("** "); continue; } Wire.beginTransmission(address); error = Wire.endTransmission(); if (error == 0) { if (address<16) Serial.print("0"); Serial.print(address,HEX); Serial.print(" "); nDevices++; } else if (error==4) { Serial.print("?? "); nDeverr++; } else { Serial.print("-- "); } } Serial.println(); Serial.print("Scan result for i2cclock "); Serial.print(i2cclock/1000); Serial.println("k"); Serial.print("found: "); Serial.print(nDevices); Serial.println(" devices "); Serial.print("error: "); Serial.print(nDeverr ); Serial.println(" devices \n"); delay(5000); }

- - - Aktualisiert - - -

(bei ARMs habe ich nie diese error 4 = ?? , allerdings auch nie die Adressen 78...7E)

Zitat:

Zitat von 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.

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.

Zitat:

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

Zitat:

Zitat von Klebwax

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.