3rd Party NES Classic with ESP32 Issues

[skyeperry1]

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.

[dmadison]

Thanks for submitting this!

This is a known problem. It's actually a bug in the controller itself, which is why the first batch of knockoff NES Classic controllers didn't work properly with either the mini console or the Wii.

The first two bytes, which center the left and right joysticks, are repeated twice. If you request 8 bytes and discard the first 2 everything works fine. The issue is that every other controller in the library works on a 6 byte packet, so at the moment there's no easy way to get it to work without affecting other things.

I went back and forth on this, but I ended up not building support for the knockoff NES controllers because it would require a number of special cases in the code just for them. I think now it would be a useful feature to add in, I just need to figure-out exactly how I want to do it without affecting the other code.

[skyeperry1]

This is great! thanks for the help. With your advice, I was able to get my 3rd party Orzly controller working by making the following two changes to the library:

In extentensionController.h I increased the requested data from 6 to 8 bytes:
static const uint8_t ControlDataSize = 8; // Enough for 3rd party controller request size

and In extensionController.cpp, I hardcoded an offset where we return the array data:

uint8_t ExtensionController::getControlData(uint8_t controlIndex) const {
	return controlData[controlIndex +2]; // add 2 to the data index to account for the 2 bonus bytes we get from the 3rd party ctlr
}

I'll probably take a second pass and implement this in a more elegant manor, but this gets me up and running in the meantime. Library works great.

[dmadison]

Fantastic, glad you got it working!

I'm going to keep this issue open for the time-being, see if I can't find a good way to get these working with everything else.

[dmadison]

Knockoff NES Mini controllers are now supported (see #37) and will be included in the next release.

Please test the NES Mini examples in the latest version on master and let me know if you have any issues.

[skyeperry1]

Thanks for adding the support! Works great.

[dmadison]

Sorry to do this, but I've re-written the library's back-end and modified how the 3rd party support works. It's still there! It just works slightly differently.

Rather than having the data manipulation be inline for each control surface, you now need to call a dedicated function, fixKnockoffData, once after each successful update. If the control data matches the signature of a knockoff controller, the function will transpose the button data into the correct array indices and replace the rest of the data with what a genuine NES Mini controller reports.

This method has a number of advantages, namely that it's more lightweight, allows you to use the ClassicController class for all Mini controllers, and its implementation is completely optional.

Check out this commit to test it, or see PR #40 for more information. I'll push the release out later today.

[skyeperry1]

Hey, no problem. Thanks for the update, I'll take a look and test it out over the holidays.

On a side note - I've been running into some strange issues with electrical interference when I have a 12v DC line running anywhere near the controller (12v is not connected to the NodeMCU). I am running the controller + extension cable (around 4m length) that's stripped and running straight into the NodeMCU ESP32. Have you run into anything similar?

[dmadison]

I haven't run into anything similar with my own controllers, but it doesn't surprise me. I²C was never meant to go long distances, which is one of the reasons why Nintendo never made official "extension" cables (to my knowledge). For the mini consoles I also believe Nintendo set them to do a 21 byte request and throw out any data updates if a single bit past the control data reads "high", to avoid accidental button presses.

One thing I would check is the pull-up resistors on the data and clock lines. Pull-ups are on the controller and not the Wiimote because it's the controller's cable length that defines the bus capacitance, and I do know that some 3rd party controllers don't include pull-up resistors like they should. You could also add your own pull-ups on top of the existing ones and see if that improves reliability. (An oscilloscope would help if you have one accessible.)

[dmadison]

It's been a month without any updates. I'm assuming this is solved - feel free to re-open it if you're having issues.

[skyeperry1]

Hey @dmadison, sorry for the radio silence. Adding a 470Ω pull up resistor on the SDA and SCL lines alleviated the any issues with controller connectivity/interference. I haven't tested the latest library yet but every previous version have worked flawlessly with a 3rd party controller, following the comments above. I will be digging back into my project that uses your library and l will confirm once I get the latest version working, but I think it's safe to close the issue. Thanks again for all the support, this library is excellent!