Wii Nunchuck an Arduino

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

[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