Wired Pro Controller emulation #1
Comments
|
@javmarina thanks for sharing! I'll be sure to check it out. I took a little bit of a break on this project because I got stuck. |
|
@javmarina Using your code I managed to get a bit further although I still can't get the Switch to detect my device as a controller. I have the following conversation between the switch and my STM32F4-Discovery board. (Output all in Hex) After this if I start sending reports like the following it still doesn't do anything Can you see anything obvious that is going wrong? |
|
I realized I wasn't sending the full buffer, when I do this it causes the switch to crash! Gives
|
|
That should definitely not happen. I wonder what triggered that crash. You might want to use Wireshark in order to analyze the USB traffic between your computer and the controller. If you have Chrome installed, it will try to communicate with the Pro Controller and all the messages will appear in Wireshark. The way I fixed my code was comparing the USB traffic with a real Pro Controller and the traffic with my Arduino board. You can also check https://mzyy94.com/blog/2020/03/20/nintendo-switch-pro-controller-usb-gadget/ and https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering. |
|
One thing that might confuse the Switch is the fact that the counter is not incremented after every packet. In my project I increment the counter by 3 after every reply, but seems like you do that every two packets. I read a long ago that the counter should increment very quickly and could cause issues. |
|
WIP branch is here: https://github.com/rossmacarthur/rephrase/tree/try-comms-again |
Never mind, my bad. I leave that for reference. |
|
The one thing I wasn't sure about was at what point do I start sending regular reports? Or should I only send them if the Switch requests them? |
|
I'm going to fix the counter issue, and try again. |
|
I didn't implement the SPI commands which I'm guessing is going to be necessary to get this working 😅. |
|
You are right, didn't notice that. |
To be fair, it's not clear when you have to send regular reports. The Switch won't usually send a request packet, but instead will generate a USB interrupt. In my project, I send a regular report if I didn't receive any packet from Switch since the last interrupt. Seems to work fine. Otherwise, if you receive a request from the console, you have to send the reply to that request in the next interrupt and the regular report will hopefully make it to the next interrupt. See |
|
Hi Ross! How is everything going? |
I have seen that one of the items in your to-do list is "Emulate a wired Switch Pro Controller and correctly interface with the Switch console". I just wanted to contact you because I recently published a firmware for AVR microcontrollers that emulates a Pro Controller. As far as I know, Pro Controller emulation with microcontrollers hasn't been a thing until now, as most projects (some of which are very influential, such as https://github.com/shinyquagsire23/Switch-Fightstick) just emulate a Horipad S controller. Some repositories emulate a Pro Controller, but use Raspberry Pi/Python scripts and therefore don't mind about the low-level stuff, which is probably the hard part for your project.
My project was initially based in a similar firmware, but I wanted to unlock all the features that Pro Controller has compared to other USB controllers (custom colors, IMU, NFC, IR...). I started the transition more than one month ago and made some interesting discoveries about low-level USB communication and sync protocol.
I thought it could be useful to you, and I guess the ST USB library will be similar to the one I use (LUFA library). You can check my project here. Thanks in advance!
The text was updated successfully, but these errors were encountered: