Dazzler ... support Wii Analog Stick?

[core]

Given the GD 3X Dazzler support for the Wii Classic Controller... will it also support the Wii Analog Stick?  The Classic Controller seems like a superset of inputs vs. Analog Stick.

I looked at the code having 2 instances of the _wii structure (GD2.h).

struct _wii {
   byte active;
   xy l, r;
   uint16_t buttons;
};

So, then maybe the Analog Stick is one of 'l' or 'r' and a subset of the 'buttons' bits.

Thanks.

[jamesbowman]

Right, those buttons are:

• l: left direction pad
• r: right joystick
• buttons: bitmask of all buttons

The code to fill in these fields is here:

github.com/jamesbowman/gd2-lib/blob/master/GD2.cpp#L1599-L1613

The Wii support is all I2C based. This page lists all the I2C controllers - including the Classic Pro:

wiibrew.org/wiki/Wiimote/Extension_Controllers

I don't see an Analog Joystick mentioned.

[core]

Excellent. I really meant "The Nunchuck". (I got confused, the analog stick is just the joystick part of it.)

[jamesbowman]

Aha, got it.

The Nunchuck returns 6 bytes of data just like the Classic Pro, except that the bits are in different places:

wiibrew.org/wiki/Wiimote/Extension_Controllers/Nunchuck

The Dazzler will report these 6 bytes back to gd2-lib. With a slightly different block of code, it can read out Nunchuck data.

Right now there is no easy way to tell the difference between a Classic Pro and a Nunchuck, so this will need to be handled as an add-on.

[core]

OK.  I see what you mean about the different encodings.  And there is some wording about an identifier that should distinguish.

On wiibrew.org/wiki/Wiimote/Extension_Controllers/Classic_Controller...

The Classic Controller is identified by the 16-bit constant 0x0101 (0xFDFD encrypted) at register address 0xa400fe.

On wiibrew.org/wiki/Wiimote/Extension_Controllers/Nunchuck...

The Nunchuk is identified by the 16-bit constant 0x0000 (0xFEFE encrypted) at register address 0xa400fe.

If you want to be explicit in structure so that developers can get at the individual buttons by name and know what is connected, maybe create a union of two structures and rearrange the order putting buttons first.

It seems that according to the C spec, order and packing of bit fields is left for compilers to choose.  But I've used this a lot and whether it turned out as expected could be verified by test.

#import <asm/byteorder.h>
#if defined(__GNUC__) && defined(__LITTLE_ENDIAN_BITFIELD)
#define WII_BUTTON_BITFIELDS_LE
#endif

#define WII_EXTENSION_NONE 0
#define WII_EXTENSION_CLASSIC 1
#define WII_EXTENSION_NUNCHUK 2
struct _wii {
   byte extension; // one of WII_EXTENSION_*
   union {
       uint16_t buttons;
       struct __attribute__((packed)) {
           // C spec allows bit field order and packing as a compiler implementation detail  
#if defined(WII_BUTTON_BITFIELDS_LE)
           uint16_t _rsvd_0:1;
           uint16_t rt:1; // trigger right
           uint16_t plus:1;
           uint16_t home:1;
           uint16_t minus:1;
           uint16_t lt:1;  // trigger left
           uint16_t dd:1; // down
           uint16_t dr:1; // right
           uint16_t du:1; // up
           uint16_t dl:1; // left
           uint16_t zr:1;
           uint16_t x:1;
           uint16_t a:1;
           uint16_t y:1;
           uint16_t b:1;
           uint16_t zl:1;
#else
           uint16_t buttons; // per button fields currently unsupported
#endif
           xy l, r;
       } classic;
       struct __attribute__((packed)) {
#if defined(WII_BUTTON_BITFIELDS_LE)
           uint16_t z:1;
           uint16_t c:1;
           uint16_t _unused_15_2:14;
#else
           uint16_t buttons; // per button fields currently unsupported
#endif
           xy s;
           uint16_t ax, ay, az;  // accelerometers
       } nunchuk;
   } data;
};

and 

if (...classic...) {
   w->extension = WII_EXTENSION_CLASSIC;
   w->data.buttons = r[4] | (r[5] << 8);
   w->data.classic.l.x = (r[0] & 63);
   w->data.classic.l.y = (r[1] & 63);
   w->data.classic.r.x = (((r[0] >> 6) & 3) << 3) |
            (((r[1] >> 6) & 3) << 1) |
            (((r[2] >> 7) & 1));
   w->data.classic.r.y = (r[2] & 31);
} else if (...nunchuk...) {
   w->extension = WII_EXTENSION_NUNCHUK;
   w->data.buttons = (r[5] & 3);
   w->data.nunchuk.s.x = r[0];
   w->data.nunchuk.s.y = r[1];
   w->data.nunchuk.ax = (r[2] << 2) | ((r[5] >> 2) & 3);
   w->data.nunchuk.ay = (r[3] << 2) | ((r[5] >> 4) & 3);
   w->data.nunchuk.az = (r[4] << 2) | ((r[5] >> 6) & 3);
} else {
   w->extension = WII_EXTENSION_NONE;
}

For safety, a runtime test could check that compiler is packing and ordering as expected (on Arduino, maybe won't be able to see an assertion, I've never tried it.  Maybe push to serial using something as in 1, 2)
#include <assert.h>

#define checkWiiClassicButtonFields(fieldName, bitPos) { \
   wii.data.buttons = (1 << bitPos); \
   assert(wii.data.classic.fieldName == 1); \
}

   checkWiiClassicButtonFields(rt, 1)
   checkWiiClassicButtonFields(plus, 2)
   checkWiiClassicButtonFields(home, 3)
   checkWiiClassicButtonFields(minus, 4)
   checkWiiClassicButtonFields(lt, 5)
   checkWiiClassicButtonFields(dd, 6)
   checkWiiClassicButtonFields(dr, 7)
   checkWiiClassicButtonFields(du, 8)
   checkWiiClassicButtonFields(dl, 9)
   checkWiiClassicButtonFields(zr, 10)
   checkWiiClassicButtonFields(x, 11)
   checkWiiClassicButtonFields(a, 12)
   checkWiiClassicButtonFields(y, 13)
   checkWiiClassicButtonFields(b, 14)
   checkWiiClassicButtonFields(zl, 15)

#define checkWiiNunchukButtonFields(fieldName, bitPos) { \
   wii.data.buttons = (1 << bitPos); \
   assert(wii.data.nunchuk.fieldName == 1); \
}

   checkWiiNunchukButtonFields(z, 0)
   checkWiiNunchukButtonFields(c, 1)