Avoid unreferenced Gamepad instances to be created by the compiler

[SukkoPera]

This seems to fix #266 upstream.

Since now only referenced Gamepad instances are actually created by the compiler, I took the liberty of adding Gamepad5 and 6.

[NicoHood]

If I remember correct, only 3 will ever work, as the 32u4 only has 6 usb endpoints, of which 3 are used by the serial?

[SukkoPera]

Correct, but they turn up handy if the CDC serial gets disabled. Since with this modification their presence won't cause any overhead, I thought I'd throw them in.

[NicoHood]

Does it seem to fix, or does it really fix the issue?

[SukkoPera]

It fixes the issue on a project of mine. I need to test on other projects before I can say it definitely does with confidence. Just thought I'd share the patch in the meantime, so that maybe other people could test on their own.

[SukkoPera]

Just noticed an odd side-effect: Gamepad1 no longer corresponds to the first gamepad detected by the system, sigh. Other gamepads might be out of order as well. Controllers seem to be detected in the exact reverse order. Any idea why?

Apart from this problem, I am using 6 controllers together with no issues (of course the CDC Serial was disabled).

[NicoHood]

I think the order of Gamepad creation could be related to:

• First use in the code
• Compiler sorting, possibly by name

So you could try to change the name of the cpp files maybe. Another idea would be to add special attributes to the class to change its construction order. I am not sure if that is possible, but I remember that there could be options like that.

Is it even important to have them in the correct order?

[SukkoPera]

I thought the same, but the first use in my code is in an array which is populated in order.

Files and instances are named in ascending order so I see no way that could lead to the reverse order.

I think users would expect Gamepad1 to be the first controller, I think we should preserve this behavior.

[NicoHood]

I dont know, but I bet you will find it out.

[SukkoPera]

More testing confirms that this solves the initial issue, but still I can't understand why the order of controllers gets reversed.

[RevHarryPowell]

Sorry to revive this old conversation, but I’m having trouble implementing SukkoPera’s fix in my code, which currently has only 2 HID gamepads. The only way I can get rid of the third is by deleting the extra SingleGamepadX.cpp files and removing the lines in SingleGamepad.h. I’d like to be able to dynamically change the number of HID gamepads generated. Is there a way to accomplish this?

[fermino]

Hi! First of all, @NicoHood I know that maintaining a project isn't easy, so thanks a lot for this library!

Is there any chance to have this PR merged? I am experiencing the same issues as in #266, and although creating instances in the lib files is common practice in the arduino environment, it get's kind of annoying when you try to dive a bit deeper.

For what I've been reading the order of compilation is not defined by the C standard, but if there's a GCC behavior we could try to hack around that to make it work for most of the people.