dmadison / nintendoextensionctrl

Arduino library for communicating with Nintendo extension controllers

Nintendo Extension Controller Library

This is an Arduino library that makes it easy to read data from Nintendo extension controllers such as the Wii Nunchuk and Classic Controller.

"Extension controller" is the name given to devices that extend the functionality of the Wiimote, plugging into the expansion port at the bottom of the device. While originally designed for Wiimote accessories, the port and communication protocol is now also being used for the controllers of Nintendo's new line of "Mini" consoles.

Getting Started

Make Your Connections

Before anything else, you need to connect your controller to the Arduino. The easist way to do this is with a breakout board, which slides in to the extension controller plug and doesn't require dismantaling your controller. I recommend the Nunchucky breakout, which is inexpensive and available at Adafruit.

Controllers require 3.3V power. If you don't have 3.3V power available on your board, you will need to use an external regulator. Using 5V power can result in erratic data and risks damaging your controller. For this reason it's recommended not to use so-called "inline" adapters that attach to the Arduino Uno's analog pins.

The "data" and "clock" lines on the breakout go to the SDA and SCL pins (respectively) on the microcontroller. For the Arduino Uno, these are pins A4 and A5. If you're not using an Uno, look here to find the I²C pins for your Arduino board.

Run an Example

After installing the library, load an example by going to File -> Examples -> NintendoExtensionCtrl in the Arduino IDE and selecting an example specific to your controller. I recommend the DebugPrint examples to start, as they give you a nice overview of what data is available for your controller.

Plug in your controller, upload the example to your board, and have fun!

Supported Controllers

Wii

• Nunchuk
• Classic Controller

Wii Instruments

• Guitar Hero Guitar
• Guitar Hero World Tour Drums
• DJ Hero Turntable

Wii Drawing Tablets

• uDraw Tablet
• Drawsome Tablet

Mini Console

• NES Mini Controller
• SNES Mini Controller

Currently the library supports any extension controller using unencrypted communication. If you'd like to add support for another controller, I've written a short guide that should be helpful.

License

This library is licensed under the terms of the GNU Lesser General Public License (LGPL), either version 3 of the License, or (at your option) any later version.

nintendoextensionctrl's Issues

Support Question

Hi, really like the library, its written very well. I currently have an NES mini connected to an adafruit feather m0 dev board. The problem I'm having (running the example code) is that the controller is never recognized. any advice you could offer would really be helpful. There is communication over i2c, and if I drop out of the controller check loop the buttons are being read, but it consistently displays the disconnected message on the "term" while displaying valid button data. I was wondering if this might be a clock speed issue? I have ruled out pull up resistors as the culprit. I suspect the library was never meant to run on arm, but it almost dose. Looking forward to hearing back from you.

Specifying Serial port for .print functions during declaration?

So, I've been working on a project with your library that basically connects a Classic Controller to a Nintendo Switch via progmem's excellent work here and the Arduino version by fluffymadness here.

The thing is, it requires using LUFA which removes the Serial port in favor of Serial1 and Serial2.

Now, I can change it in the NXC_Comms.h header, but when I want to use the library/test something with normal Serial and I forget that I changed the port, I get no output until I revert the change.

---

Copy from issue #46

I've seen that you can choose the Wire "port" with Class controller(Wire1);

I'd love to have that same functionality, but with the Serial port. So by default it'd be Serial and Wire, but if I just need to change the Serial port, it could be controller(Wire, Serial1) so that way you don't have too many different overloads. :)

Not an issue - but...

I'm using your excellent library with an ESP32 - after using it with Arduinos before. It seems, that you changed some files within the current version 0.7.4. These changes effect the users of ESP platform heavily, and many of them would not expect changes within one version. Please build a 0.7.5, so that ESP users get the latest changes (which are working like charme).

I2C pins a beginner's question

Thank you for all the work you have done to create this library.

I would like to get the nunchuk working on my esp-01. only then does the ESP not see the nunchuk. are the I2C pins fixed in the standard I2C pins of an ESP in your code? Can I change it or do I have to do it another way?

Now I have it working on a "regular" ESP8266 with indicated I2C pins. I can use it to control my robot via the UDP.
But I like to keep it as small as possible, to be able to put everything in the nunchuk (Li-Po + ESP)

Thanks for reading my post, it will be totally awesome if you push me in the right direction a bit

Mini Controller Implementation Should Use "High Resolution" Mode

As @nullstalgia discovered in #56 (link), the NES Mini and SNES Mini controllers use a special "high resolution" mode of the Classic Controller for sending data. This is why knockoff NES Mini controllers were reporting their data incorrectly - they assume that the high resolution mode has already been enabled by the console (i.e. Arduino) even when it wasn't.

It would be better to implement this properly, writing the "high res" register if the mode is called for and not trying to "fix" the data by shifting it in the array after it has been received. It's cleaner, more robust, and would have the same data outputs for both OEM and 3rd party controllers.

Setting the "high resolution" mode is accomplished by writing 0x03 to address 0xFE.

Standard data format:

		7	6	5	4	3	2	1	0
	0	RX<4:3>	LX<5:0>
	1	RX<2:1>	LY<5:0>
	2	RX<0>	LT<4:3>	RY<4:0>
	3	LT<2:0>	RT<4:0>
	4	BDR	BDD	BLT	B-	BH	B+	BRT	1
	5	BZL	BB	BY	BA	BX	BZR	BDL	BDU

High resolution data format:

		7	6	5	4	3	2	1	0
	0	LX<7:0>
	1	RX<7:0>
	2	LY<7:0>
	3	RY<7:0>
	4	LT<7:0>
	5	RT<7:0>
	6	BDR	BDD	BLT	B-	BH	B+	BRT	1
	7	BZL	BB	BY	BA	BX	BZR	BDL	BDU

Source

Who's software am I using?

I am currently using a library for the Nintendo Wii nunchuck called "Nintendo Extension" in PlatformIO.ini and am looking for documentation. Is it possible that this library changed its name or registration in the last month?

3rd Party NES Classic with ESP32 Issues

Hi,
I'm trying to connect an Orzly brand NES classic controller to my ESP32 board (I've also tried on a NodeMCU esp8266). I'm able to get the library to recognize the board as a 'classic controller', but any keypress data I get back seems to be incorrect (it always displays as all keys are pressed). When I run nes,PrintDebugRaw() I can see this:

----- NES Mini Controller Demo -----
0x81 | 0x81 | 0x81 | 0x81 | 0x00 | 0x00

The output doesn't change regardless of what keys are pressed. I'm way out of my wheelhouse on this one, but could the data positions be different in my 3rd party controller?

In any case, thanks for putting together this library, It's very nicely documented and organized.

Incompatible with Adafruit-PWM-Servo-Driver-Library

Found that this library conflicts with Adafruit-PWM-Servo-Driver-Library
What would be the right way of resolving the issue ?

Issue is that I think I2C settings are contradicting to each other.

Genuine Classic Controller does not Initialize/Connect properly with your XInput AVR Library

Hey, me again :P

(Note, this has only been tested with a custom ATMega32u4-based board)

So I've been using your XInput library (which I didn't notice was yours, even after I used the Classic Controller > XInput example), and I noticed an odd bug.

When I have a normal, genuine Classic Controller plugged in when the AVR resets, the

while (!classic.connect()) {
    digitalWrite(6, !digitalRead(6));
    delay(1000);
  }

Will blink the LED over and over again until I do one of the following:

• Replug the controller
• Reset the chip with a SNES/NES/Knockoff controller plugged in
• Do a full power cycle with the Classic controller plugged in

This seems similar to #50, but it seems to work fine with the NES Classic Controller no matter what. (I have 4.7k Pullup resistors on the board for SDA and SCL)

Unfortunately, it seems to work fine occasionally.

But the ways I've been able to make it mess up seem to be this:

• Have a stick not be centered on reset
• Upload a new sketch
• Sneeze on Tuesday when the moon is waxing

Any help would be appreciated :)

Non genuine classic controller not initialised with classic.begin(); but can get data with controller.begin();

Trying to find out what's wrong with my XBOX controller emulation on chinese arduino micro 32u4 board mimicking as leonardo board

Always get Controller not detected with classic.begin(); but can get data with controller.begin();

All RAW data from controller detected in serial monitor, so it is working.

Also everything is working with Leonardo WiiClassicController GamePad by Nguyen Chi Tam

Issue with non genuine Nes looking classic controller

Not sure if this is a duplicate of #68 as its quite similar i think.

But I have a NES looking controller I got from aliexpress years ago that I'm trying to use with an ESP32

If I run the Identify Controller Example, it is detected as a Classic controller:

Classic Controller connected!
ID: 0x01 0x00 0xA4 0x20 0x01 0x01

But when I run the Classic_DebugPrint, it fails to connect

if I add this to the loop of Identify Controller, it successfully print Debug data to the screen that I can see changing as I press buttons

boolean success = controller.update();  // Get new data from the controller

  if (success == true) {  // We've got data!
    controller.printDebug();  // Print all of the values!
  }
  else {  // Data is bad :(
    Serial.println("Controller Disconnected!");
    delay(1000);
  }

Any idea what could be up or anything I can provide debugging with?

I can definitely hack something together from this point to get it working, but just thought I'd report it in case it was something that could be fixed.

I'm sure it doesn't matter, but just fyi, I'm using non standard I2C pins (this approach works fine for nunchucks anyways!)

Wire.begin(NUNCHUCK_SDA, NUNCHUCK_SCL);
classic.begin();

Hope all is well with you!

8BitDo Retro Receiver gives garbage data

Hi!

I was hoping I could use your code with an 8bitdo Retro Receiver for (S)NES Classics, but I don't get much anything useful from it.

(These were tested with/without I2C pullups with a value of 4.7KOhm)

Output from IdentifyController with Adapter

Classic Controller connected!
ID: 0x00 0x00 0xA4 0x20 0x01 0x01

With Official NES Classic controller

Classic Controller connected!
ID: 0x01 0x00 0xA4 0x20 0x01 0x01

With Official Wii Classic controller

Classic Controller connected!
ID: 0x00 0x00 0xA4 0x20 0x01 0x01

With Official SNES Classic controller

Classic Controller connected!
ID: 0x01 0x00 0xA4 0x20 0x01 0x01

With 3rd party Wii Classic Pro Controller

Classic Controller connected!
ID: 0x00 0x00 0xA4 0x20 0x01 0x01

Output from Classic Controller Debug Print

With Official SNES

Classic ____ | ___ | ____ L:(31, 31) R:(15, 15) | LT: 0_ RT: 0_ Z:__

With 8BitDo

Classic <^v> | -H+ | ABXY L:( 4,  6) R:(21,  6) | LT: 4X RT: 6X Z:LR

Output from printDebugRaw

8BitDo

Raw[6]: 0x84 0x86 0x86 0x86 0x00 0x00

8BitDo with 8-sized request data

Raw[8]: 0x84 0x86 0x86 0x86 0x00 0x00 0xFF 0xFF

SNES

Raw[6]: 0x5F 0xDF 0x8F 0x00 0xFF 0xFF

Genuine NES Classic Controller hangs at connection time. Any ideas?

Hi, I'm having trouble getting a genuine NES classic controller to connect on a genuine Arduino UNO board. I annotated the related print-debug sketch as follows.

void setup() {
  Serial.begin(115200);
  Serial.println("beginning nes");
  nes.begin();
  Serial.println("nes has begun");

  Serial.println("connecting controller");
  while (!nes.connect()) {
    Serial.println("Classic Controller not detected!");
    delay(1000);
  }
  Serial.println("controller has connected");

  Serial.println("detecting 3rd party");
  if (nes.isThirdParty()) {  // Uh oh, looks like your controller isn't genuine?
    nes.setRequestSize(8);  // Requires 8 or more bytes for third party controllers
  }
  Serial.println("detection complete");
}

This produces the following output when run with the controller connected.

15:55:39.474 -> beginning nes
15:55:39.474 -> nes has begun
15:55:39.474 -> connecting controller

This leads me to believe there's something hanging in the connection step.

Given everyone else's success with the lib, I'm sure something in my setup is incorrect, but as far as I have found, I'm wired up correctly. Basically I bought an extender, then snipped and stripped that to make a female port on the breadboard. I then plug the controller into that. Here's a shot of Fritzing for reference.

Any help you can provide resolving this is greatly appreciated! Cheers!

Change success condition for getHighRes/setHighRes

First off, great work!

Secondly, setting hi-res on a crappy third party didn't work, but it has an easy solution:

Check to see if the ID of the controller changed to reflect the new mode

On a controller that supports HiRes:

On a controller that doesn't:

Tested with:

Official Classic Controller

Official SNES Mini Controller

8BitDo Retro Reciever

Crappy Classic Pro

Working then non readable data

I am using the Nunchuck_demo example code
----- Nunchuk Demi---- Nunchuk Demo ----- The Z button is released The joystick's Y axis is at 126 The accelerometer's X-ax87) | Buttons: -- ----- Nunchuk Demo ----- The Z button is released The joystick's Y axis is at 126 The accelerometer's X-ax87) | Buttons: -- ----- Nunchuk Demo ----- The Z button is released The joystick's Y axis is at 126 The accelerometer's X-ax+⸮Ȳ⸮P C⸮⸮󋺑v$⸮�x⸮;�L�⸮i⸮⸮H⸮�⸮��c��⸮0H4�⸮R⸮�⸮:⸮K6�W�⸮ (Z3⸮q⸮⸮⸮⸮⸮⸮:⸮h1⸮)⸮S⸮⸮ !Q⸮S⸮�⸮B0⸮⸮r,2Ky⸮Z�H�⸮RP⸮B<�M��⸮⸮ ⸮⸮5� ⸮⸮⸮⸮⸮��⸮0�⸮�⸮ (J9⸮I⸮⸮⸮⸮⸮⸮8⸮⸮1⸮⸮�S⸮ �N⸮⸮⸮I⸮⸮⸮[5⸮R⸮⸮�-��⸮Iq⸮ӨFp⸮X(⸮⸮4⸮�$⸮u⸮�F
after that i stopped it
i am using arduino uno

Classic Controller not detected on Wemos D1 mini boards

Hey Dave,
some days ago I found your lib and it works like a charm with my cheap chinese classic controller pad. For my first test I used an Arduino Micro.

For the main project (a self coded tetris clone) I want to use an ESP8266 (Wemos D1 mini) especially for its wifi support. Unfortunately same example code (that worked on the Micro) won't work on my D1 board. I think, its not an core i2c or wiring problem, because an BME280 sensor I put on the same i2c line works without problem. I even tried to ad the usual 4k7 pull-ups - without any change. The .connect() always returns false (without any delay), and I have no idea how to fix it.

For debugging I also used the usual i2c-scan sketch that that found an device on 0x52 - obviously the controller. anyway, communication seems not possible on the D1. Do you have any idea why this issue appears on my D1 board? Is that a similar problem as in issues #33?

Cheers.
Olli