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!
Hi Brian, good to see you again.
To be honest I haven't looked at this codebase in quite some time. Look towards the setDataMode() function of the ClassicControllerBase class. The code does some funky things because there is a "low resolution" and "high resolution" mode of the controller. First party controllers can switch between the two but third party controllers are typically hardwired one way or the other - low resolution for "Classic" controllers, and high resolution for "Mini" controllers.
My guess is that there is an issue with either reading or writing from the register which sets that mode. If you want to debug further, trace through that function and figure out where things are going sideways.
I confirm that it works by changing line 117 of the ClassicController.cpp file
return setDataMode(true);to return setDataMode(false);
Thanks for responding @julienrat. If you find the time, could you please do the following:
- Trace through the
setDataModefunction and figure out where it's returning 'false' - Run the
DebugPrintexample with a call toprintDebugRaw()and post the result
In theory at least that function shouldn't return 'false' unless there is a communication error of some sort.