Wii Nunchuk und Atmega88P - Daten nur 0xFF

[A. B. (developer_x)]

Liebes Forum,
ich bins mal wieder. Ich habe folgendes vor:
Ich habe einen Atmega88P mit UART Verbindung zum PC, ein 
Terminalprogramm namens H-Term, ein originales WII Nun Chuck und einen 
Wii Nun Chuk Adapter.
Ich will die Daten des Nun Chuk auslesen, dazu benutze ich den Code 
folgender Website:
http://davidegironi.blogspot.it/2012/11/avr-atmega-wii-nunchuck-library-01.html#.VBxOlRY2x_R
Ich habe am Code folgendes geändert: F_CPU = 8000000L
(8Mhz ist wirklich richtig, der MC läuft mit dieser Geschwindigkeit)

In meiner Konsole von HTerm erhalte ich folgende Ausgabe von meinem MC:

Hello world...<\r>
<\n>Reading Byte 0: 255<\r>
<\n>Reading Byte 1: 255<\r>
<\n>Reading Byte 2: 255<\r>
<\n>Reading Byte 3: 255<\r>
<\n>Reading Byte 4: 255<\r>
<\n>Reading Byte 5: 255<\r>
<\n>Reading Byte 6: 255<\r>
<\n>Byte 0 sent: 1<\r>
<\n>Byte 1 sent: 2<\r>
<\n>Byte 2 sent: 3<\r>
<\n>Byte 3 sent: 4<\r>
<\n>Byte 4 sent: 5<\r>
<\n>Byte 5 sent: 6<\r>
<\n>Reading Byte 0: 255<\r>
<\n>Reading Byte 1: 255<\r>
<\n>Reading Byte 2: 255<\r>
<\n>Reading Byte 3: 255<\r>
<\n>Reading Byte 4: 255<\r>
<\n>Reading Byte 5: 255<\r>
<\n>Reading Byte 6: 255<\r>
<\n>Byte 0 sent: 7<\r>
<\n>Byte 1 sent: 8<\r>
<\n>Byte 2 sent: 9<\r>
<\n>Byte 3 sent: 10<\r>
<\n>Byte 4 sent: 11<\r>
<\n>Byte 5 sent: 12<\r>
<\n>Reading Byte 0: 255<\r>
<\n>Reading Byte 1: 255<\r>
<\n>Reading Byte 2: 255<\r>
<\n>Reading Byte 3: 255<\r>
<\n>Reading Byte 4: 255<\r>
<\n>Reading Byte 5: 255<\r>
<\n>Reading Byte 6: 255<\r>
...

Das Problem immer ein und denselben Wert zu empfangen, habe nicht nur 
ich, wenn man im Internet danach sucht stößt man oft auf dieses Problem, 
aber ich habe in all den Threads keine richtige Antwort finden können.

Ich habe auch schon ein zweites Nunchuck ausprobiert, beide 
funktionieren an meiner Konsole definitiv.

Ich habe auch schon Pullup widerstände angeschlossen, habe auch mal das 
Programm ohne angeschlossenen Nunchuk getestet, da hat das Programm es 
aber erkannt, was ja am Quellcode sichtbar ist.

Was genau kann man da jetzt machen, habt ihr noch irgendwie was im 
Internet gefunden bzw. eine Idee?

Danke,
m.f.G.: K.R.

[A. B. (developer_x)]

Dieser Artikel beispielsweise (hab ich erst jetzt entdeckt)
schließt damit, dass man zwischen den einzelnen Abfragen der Bytes 
pausieren soll, und eine TWI Frequenz von 100kHz nutzen sollte:
http://www.mikroe.com/forum/viewtopic.php?t=11121

/*
 * get new data
 */
void wiinunchuck_update() 
{
  uint8_t i=0;
  uint8_t buff[WIINUNCHUCK_READBYTES];
  memset(buff, 0, sizeof(buff));

  //request data
  i2c_start_wait(WIINUNCHUCK_ADDR | I2C_WRITE);
  i2c_write(0x00);
  i2c_stop();
  i2c_start_wait(WIINUNCHUCK_ADDR | I2C_READ);
  for(i=0; i<WIINUNCHUCK_READBYTES; i++) 
  {
    if(i==WIINUNCHUCK_READBYTES-1)
      buff[i] = i2c_readNak();
    else
      buff[i] = i2c_readAck();
    _delay_us(500); // HIER!
  }
  i2c_stop();

  //decodebyte
  #if WIINUNCHUCK_DECODEBYTE == 1
  for(i=0; i<WIINUNCHUCK_READBYTES; i++) {
    buff[i] = wiinunchuck_decode(buff[i]);
  }
  #endif

  //record old records
  #if WIINUNCHUCK_PULSEBUTTON == 1
  wiinunchuck_lastbuttonZ = wiinunchuck_buttonZ;
  wiinunchuck_lastbuttonC = wiinunchuck_buttonC;
  #endif

  //get joypad
  wiinunchuck_joyX = buff[0];
  wiinunchuck_joyY = buff[1];

  //get button
  wiinunchuck_buttonZ = !(buff[5] & 0b00000001);
  wiinunchuck_buttonC = !((buff[5] & 0b00000010) >> 1);

  //get angle
  wiinunchuck_angleX = (buff[2] << 2) + ((buff[5] & (0b00000011 << (1*2)) >> (1*2)));
  wiinunchuck_angleY = (buff[3] << 2) + ((buff[5] & (0b00000011 << (2*2)) >> (2*2)));
  wiinunchuck_angleZ = (buff[4] << 2) + ((buff[5] & (0b00000011 << (3*2)) >> (3*2)));

  //filter angle
  #if WIINUNCHUCK_ANGLEFILTER == 1
  wiinunchuck_angleX = wiinunchuck_avaragefilter(wiinunchuck_angleX, (int *)wiinunchuck_avarageangleX);
  wiinunchuck_angleY = wiinunchuck_avaragefilter(wiinunchuck_angleY, (int *)wiinunchuck_avarageangleY);
  wiinunchuck_angleZ = wiinunchuck_avaragefilter(wiinunchuck_angleZ, (int *)wiinunchuck_avarageangleZ);
  #endif
}

Es will aber immer noch nicht, Vorschläge?
Ich habe auch schon Pausierungen von 1ms, 2ms und 10ms getestet.

[Marc V. (Firma: Vescomp) (logarithmus)]

K. R. schrieb:
> Es will aber immer noch nicht, Vorschläge?
> Ich habe auch schon Pausierungen von 1ms, 2ms und 10ms getestet.

 Antwortet Nunchuk(nie gehört) auch ?
 ACK, NACK richtig ?
 Werden da auch tatsächlich FFs als Antwort gesendet ?
 FF kriegst du ja auch mit Pullup.

 Wenn ja, muss da beim Nunchuk(nie gehört) vielleicht etwas
 voreingestellt werden, irgendwelche Register beschrieben
 oder so was ?

[Oliver R. (orb)]

Marc Vesely schrieb:
> Nunchuk(nie gehört)

Warum antwortest Du wenn Du keine Ahnung hast worum es geht?
Das Nunchuk ist eine Erweiterung für den WII-Controller mit Joystick, 
Tasten und einem 3-Achsen-Beschleunigungssensor. Angesprochen wird der 
über I2C.

Genaueres findest Du unter 
http://www.cc-zwei.de/wiki/index.php?title=Wii-Nunchuk_Hintergrundwissen

[Nop (Gast)]

Ist doch Sch***egal.
I2C ist I2C.
Und ich hätte auch darauf getippt das er erst garnicht antwortet und 
deshalb FFen kommen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Oliver R. schrieb:
> Warum antwortest Du wenn Du keine Ahnung hast worum es geht?
 Ich hab schon Ahnung worum es geht, nur kenne ich das Teil nicht.

Nop schrieb:
> Ist doch Sch***egal.
> I2C ist I2C.
 Genau.

Oliver R. schrieb:
> Genaueres findest Du unter...
 Gefunden. Und jetzt ?

[A. B. (developer_x)]

Also gut, ich bin wieder da.
Ich habe den Artikel vom CCC schon gelesen,
und weiter? Es will immer noch nicht.

Hat denn niemand eine Idee woran es liegen könnte?

[Bernhard F. (bernhard_fr)]

K. R. schrieb:
> was ja am Quellcode sichtbar ist.

Welcher Quellcode? Ich kann deinen Quellcode nicht sehen...

Ich bin mal dem Link gefolgt. Da findet sich dann auch eine Datei:
avr_lib_wiinunchuck_02.zip
Ist das aus dem Code den du auch hast?

/* define CPU frequency in Mhz here if not defined in Makefile */
#ifndef F_CPU
#define F_CPU 4000000UL
#endif

/* I2C clock in Hz */
#define SCL_CLOCK  10000L


/*************************************************************************
 Initialization of the I2C bus interface. Need to be called only once
*************************************************************************/
void i2c_init(void)
{
  /* initialize TWI clock: 100 kHz clock, TWPS = 0 => prescaler = 1 */
  
  TWSR = 0;                         /* no prescaler */
  TWBR = ((F_CPU/SCL_CLOCK)-16)/2;  /* must be > 10 for stable operation */

}/* i2c_init */

Da scheint ein kleiner Tippfehler zu sein bei der Definition von 
SCL_Clock
K. R. schrieb:
> und eine TWI Frequenz von 100kHz nutzen sollte:

Wenn du den Code so übernommen hast, ist das z.B. nicht erfüllt.
Grundsätzlich kann man den I²C natürlich mit 10kHz nutzen. Aber wenn 
hier 100khz angedacht sind, sollte man das vieleicht versuchen?

Genauso hast du auf die Frage von Marc Vesely nicht geantwortet.
Du sprichst das Wii-Teil (Nuwasauchimmer) mit

 //request data
  i2c_start_wait(WIINUNCHUCK_ADDR | I2C_WRITE);
  i2c_write(0x00);
  i2c_stop();

an.
Auf den ersten Blick sieht das nicht so aus, als ob da irgendwo auf ein 
"ACK" bzw "NACK" abgefragt wird... und wenn, wird das überhaupt 
ausgewertet? Hast du das mal verifiziert?
Kannst du dich mal bitte durch die entsprechenden Funktionen wühlen oder 
sie bereitstellen wie sie in deinem Projekt implementiert sind, wenn das 
schon wer anderes für dich machen soll?

[A. B. (developer_x)]

1. Ja genau diesen Code nutze ich.

2. Ich habe das mit der Frequenz auch schon n paar mal gemacht.

3. Ja, Ack und Nack gibt es zwar als Funktionen
(ganz unten in der Datei twimaster.c)

Wenn du in die wiinunchuk.c guckst, in die letzten beiden Funktionen,
dort werden die verwendet in "wiinunchuck_update()" und 
"wiinunchuck_init()"
Dort kommen die beiden Funktionen auch relativ gut zum Einsatz.
Und dort funktioniert die Kommunikation wie im Tutorial vom CCC

4.
Könntest du mir vielleicht sagen, wie man konkret mit dem Nunchuk 
kommunizieren könnte?
http://www.cc-zwei.de/wiki/index.php?title=Wii-Nunchuk_Hintergrundwissen#Daten.C3.BCbertragung

Bzw. warum funktioniert der Code des Tutorials nicht, ich wüsste nicht 
wie ich es anders machen sollte.


Danke,
m.f.G.: Developer_X

[Marc V. (Firma: Vescomp) (logarithmus)]

Bernhard F. schrieb:
> Auf den ersten Blick sieht das nicht so aus, als ob da irgendwo auf ein
> "ACK" bzw "NACK" abgefragt wird... und wenn, wird das überhaupt
> ausgewertet? Hast du das mal verifiziert?

K. R. schrieb:
> 3. Ja, Ack und Nack gibt es zwar als Funktionen
> (ganz unten in der Datei twimaster.c)

 Das war nicht die Frage.
 Wenn du irgendeine Device auf dem Bus adressierst, muss diese Device
 das auch bestätigen. Und zwar so, dass die adressierte Device SDA auf
 LOW zieht. Das nennt man ACK.
 Wenn keine Device anwesend ist, oder die Adresse nicht richtig ist,
 kriegst du (durch die Pullups an der SDA) FF als Antwort und danach
 NACK (SDA bleibt HIGH).
 Also:
 Woher weisst du ob du ACK oder NACK erhalten hast ?

[A. B. (developer_x)]

Also, wenn ich das NunChuk raus ziehe und das Programm starte meldet er 
mir dies.

Zum Thema Code, so wird initialisiert:
wiinunchuk.c

/*
 * init wiinunchuck
 */
void wiinunchuck_init() {
  #if WIINUNCHUCK_I2CINIT == 1
  //init i2c
  i2c_init();
  _delay_us(100);
  #endif

  //standard init: 0x40 -> 0x00
  //alternative init: 0xF0 -> 0x55 followed by 0xFB -> 0x00, lets us use 3rd party nunchucks
  //no longer need to decode bytes in _nunchuk_decode_byte
  i2c_start_wait(WIINUNCHUCK_ADDR | I2C_WRITE);
  i2c_write(0xF0);
  i2c_write(0x55);
  i2c_stop();
  i2c_start_wait(WIINUNCHUCK_ADDR | I2C_WRITE);
  i2c_write(0xFB);
  i2c_write(0x00);
  i2c_stop();
  //update
  wiinunchuck_update();
}

So sieht i2c_init aus, in twimaster.c

unsigned char i2c_start(unsigned char address)
{
    uint8_t   twst;

  // send START condition
  TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);

  // wait until transmission completed
  while(!(TWCR & (1<<TWINT)));

  // check value of TWI Status Register. Mask prescaler bits.
  twst = TW_STATUS & 0xF8;
  if ( (twst != TW_START) && (twst != TW_REP_START)) return 1;

  // send device address
  TWDR = address;
  TWCR = (1<<TWINT) | (1<<TWEN);

  // wail until transmission completed and ACK/NACK has been received
  while(!(TWCR & (1<<TWINT)));

  // check value of TWI Status Register. Mask prescaler bits.
  twst = TW_STATUS & 0xF8;
  if ( (twst != TW_MT_SLA_ACK) && (twst != TW_MR_SLA_ACK) ) return 1;

  return 0;

}/* i2c_start */

[Marc V. (Firma: Vescomp) (logarithmus)]

K. R. schrieb:
> Also, wenn ich das NunChuk raus ziehe und das Programm starte meldet er
> mir dies.
 Was ?

 Und noch:

  #if WIINUNCHUCK_I2CINIT == 1
  //init i2c
  i2c_init();
  _delay_us(100);
  #endif

 Soll heissen:
 Wenn WIINUNCHUCK_I2CINIT fehlerhaft, mache normales I2C_Init.
 Danach wird aber auch nicht auf Resultat abgefragt.

[A. B. (developer_x)]

Lol. Ich habe den kompletten Code durchsucht, tatsächlich dürfte
keine Fehlermeldung kommen, allerdings bekomme ich tatsächlich folgenden 
String übermittelt:

<\n>Could not start TWI Bus for READ<\r>

Vielleicht ist der Atmega so schlau dass er standardmäßig sowas sendet.

Ich bin echt am Ende, und weiß net weiter woran es liegen könnte.

Wenn ich mitten im laufenden Programm das Nunchuk entferne kommt diese 
Fehlermeldung, sobald der Nunchuk wieder drin ist, kommen diese "FF" 
Bytes.

[A. B. (developer_x)]

mh