Wii Nunchuck an Arduino

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

[HaWe]

@Ceos:
mein Code oben (von uxomm) nutzt keine weiteren Libs, und wenn du meinst, dass der Code anders aussehen müsste, dann ändere ihn mal bitte so um, das er in der geänderten Form getestet werden kann.
Auch ist es nicht nur der Due, sondern auch der Adafruit M4, der betroffen ist, und beide hatten bisher NIE Probleme mit meinen Standard-I2C-Geräten (OLED SSD1306, MPU6050, CMPS11, CMPS12, BME280, BMP280, PCF8574, MCP9808, ADS1115).
Wir sind hier ja auch im Arduino-Unterforum, daher ist es klar, dass eine funktionierende Arduino-Lösung (für i2c-Wire-class) gebraucht wird.

[Siro]

@Klebwax:
Sorry, das sollte in keinster Weise Kritik am Code sein.,
zumal Du völlig recht hast. Der Code ist so richtg.
Ich hab mich durch "temp" verwirren lassen. Dein temp wird ja tatsächlich ausgewertet.
Ich dachte zuerst, das ist so eine Art dummy read.
Da steht der Tastenstatus und es wird auch das NACK gesendet.
Also alles völlig okay.

Zum Problem:
Es ist schon mehrfach bei mir aufgetreten, dass alter Code, der auf verschieden Controllern lief,
plötzlich auf dem ARM nicht mehr lief. Bei mir ARM-Cortex M3
Dazu gehört z.B. atomarer Code. Nur mit Verrenkungen geht das überhaupt.
Das betrifft pre und postincrement, das kann er nicht atomar.

Habe auch I2C Interrupts bekommen mit Status 0xF8.
den gibt es garnicht, das wäre nämlich "idle modus" alles erledigt.
Interrupt Problem, tritt nur mit C-Compiler O3 Option auf. Auch hier ein typisches Cortex-M3 Phänomen
durch die internen Write Buffer.

Da bei HaWe aber schon diverse andere Chips am I2C laufen, müssen es wohl noch andere Problem geben.
Ich tippe auch auf die LIB.

Siro

[HaWe]

Ich tippe auch auf die LIB.

@Siro: welche LIB??
uxomms Code nutzt keine LIB, nur das ganz normale Arduino-Wire() für i2c, und was anderes gibt es für Arduino standardmäßig nicht!

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