USBHost_t36 Adding New Joysticks Acting Strangely

mjs513

Senior Member+
While playing with the Arduino USBHost lib and adding a lib for wired Joysticks I was working with the 2 new controllers that I added to USBHost_t36. PS: The Teensy USBHost_t36 is heads and shoulders more flexible and my 2 cents better (Giga does not support Bluetooth 2.0 only BLE). Also another big difference is that on the Giga I am dealing with HID data only not USB device data like on the Teensy USBHost_t36.

Any now for the issue at hand. While working with the XBOX360 controller with a separate receiver that plugs into the USBHost port found that the Teensy USBHost_t36 picks up the receiver PID/VID instead of the XBOX360 PID/VID. On the GIGA it shows on connection:
Code:
New Gamepad device: VID:045e PID:028e [dev: 0x2400cb74 - intf: 0]Match PID/VID:

Joystick (45E:28E): connected

  Joystick Data: 01 03 0e
  Joystick Data: 02 03 00
Manufacturer: Microsoft
  Joystick Data: 03 03 03
Product: Xbox 360 Controller for Windows
  Joystick Data: 08 03 00
Serial Number: 1126ED72
and set Rumble and set Leds work without an issue.

However, on the Teensy (3.6, Micromod) it only works if I include the Receiver PID/VID:
Code:
USB Host Joystick Testing
*** Device HID1 62a:38da - connected ***
  manufacturer: MosArt
  product: Wireless Gamepad
    JoystickController claim collection
*** HID Device joystick[0H] 62a:38da - connected ***
  manufacturer: MosArt
  product: Wireless Gamepad
it never sees the PID/VID of the XBOX controller. If I include in the device PID/VID list we will see our normal controller type data:
Code:
 0:128 1:139 2:128 5:128 9:15 10:0 11:0 12:0 13:0 14:0 15:0 16:0 17:0 18:0 19:0 20:0 21:0 22:512 23:400 24:512 25:512
Joystick(0): buttons = 0
lx: 128, ly: 139, rx: 128, ry: 128
DPAD: 15 -> None
but set Rumble and/or LEDs don't work for some reason. Have to figure that one out. Maybe its me so more work is required there but have a feeling it is because its not seeing the Controller only the receiver.

Now the second controller I added was the USB Version of the classic NES controller. This case is a bit different between Teensy 3.6 and Micromod. On the Micromod it works no problem, i.e., works the way I intended the data to be seen:
Code:
 0:255 1:255 2:6 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0 11:1 12:1
Joystick(0): buttons = 300
DPAD: 6 -> SE
Select Button Pressed
Start Button Pressed

However, on the T3.6 it starts out no issues, identifies the controller
Code:
USB Host Joystick Testing
*** Device HID1 79:11 - connected ***
  product: USB Gamepad
    JoystickController claim collection
*** HID Device joystick[0H] 79:11 - connected ***
  product: USB Gamepad
 0:127 1:127
Note this is the same on both the T3.6 and Mircomod.

But prints data for about 5 seconds and stops dead. The sketch is still running because if I pull out the NES Controller the Sermon shows device disconnected and I can then plug in a different controller and it runs.

Note: if I turn on debug nothing shows up saying I got an error so I am totally at a loss on this one.

If interested the updated USBHost_t36 library and the sketch I am using (joystick_new) is in my branch on github: https://github.com/mjs513/USBHost_t36/tree/NES_XBOX360
 
Good morning @mjs513,

I guess I should probably dig out a T3.6 to see if we can get any clues on the difference between it and the Micromod. Although I don't think I have those controllers.

The Teensy USBHost_t36 is heads and shoulders more flexible and my 2 cents better (Giga does not support Bluetooth 2.0 only BLE). Also another big difference is that on the Giga I am dealing with HID data only not USB device data like on the Teensy USBHost_t36.
I completely agree with you, that their current USBHost stuff for the GIGA and Portenta H7, is not working overly well, likewise for many of their other peripherals, like SD, USB and Hardware Serial. For example, I don't believe any of their current code uses DMA, by default Hardware Serial is blocking, ditto for outputs to Serial... So some of their performance is needing of a lot of work.


But it is not all bad. For example, I find certain things easier. For example, if I need to send out 6 messages to initialize a device, I can simply send the message and wait for the result, to then decide what to do next, versus, trying to setup state machines, where maybe 6 different devices send the same message and then having to know that this response was from this device and then figure out what to do with it... And if I don't want my waiting to block the processor, I can always simply create a thread...

As you mentioned, they currently only support BLE. Note: on the Arduino UNO R4 WIFI, I believe that the ESP32 that they are using, only supports BLE. I have not checked yet on the GIGA or Portenta, if they can support classic Bluetooth or not. And ArduinoBLE is nice in that they do have things implemented that we don't, for example, I believe that you can setup communications between your board and your phone.... Need to play more to understand what they can or cannot do.
 
Back
Top