I was workign on some other USBHost extensions and found I needed debug information that was
being generated by a Teensy plugged into the USB host port that was output using Serial Emulation
to be available. Likewise I wanted the ability to feed data back to that other Teensy.
So I decided to create USBHost_t36 implemention to handle the USB types that include Serial Emulation
USBSerialEmu class.
The USBSerialEmu code was based on the USBSerial code as well as RAWHID. I found that there was a bug
in the Receiving of data that was sent by the remote SEREMU output, I would miss the first character
Fixed.
USBSerial fixed same bug in reading first character
here have been many cases where users plug in some new HID device, which we do not currently support, and we have very little information to go on.
So this sketch simply tries to print out the HID information for each message received from the device.
It has a simple sub-class of the USBHIDInput class, which prints out the data. Which could give us a lot of data on adding support to the library, plus shows how users can write their own sub-class for their own devices.
This also includes a class to display information about the
device that was plugged in. A lot of this is similar to
the data you would see if you turned debug on to the library
I thought maybe showing additional information about the device, like the debug output version of library might help get more detailed information back from users who have devices that are not supported/working
This delta originated to do the work similar to what was done
for the MIDI code base and support two versions of the object.
All of the code was renamed to a new base class USBSerialBase
which has everything, except the main buffer.
Two sub-classes were made that the only difference is the size of the
buffer to hold all of the USB RX and TX information.
This started off to try to support an FT2232H device which transers
512 bytes at a time instead of what most of our devices were transfering
which is 64 bytes.
While doing this, I found that we have a similar issue with the T4.x
boards which now transfer 512 bytes as well and our Serial object would
not handle it.
So there are two sublasses:
```
USBSerial - for those up to 64 byte transfers
USBSerial_BigBuffer - for up to 512 bytes
```
Note: by default the biguffer version will only handle those
devices > 64 bytes, but you can pass in an optional parameter of the
minimum size, so doing something like:
```
USBSerial_BigBuffer userial(myusb, 1);
```
Will handle all up to 512.
Also the FTDI2232H supports two USB to Serial objects, and our code
was setup that in most cases including when we put in VID:PID pair in
our table, the code would claim would claim
the object at device level so only one USB Serial adapter.
So changed table to support saying for this VID:PID claim at
interface level. It now works, but not sure for the device I have as
it is a USB to Serial and JTAG and not sure how to test 2nd one.
But while doing this created a test sketch for Multiple Host USB Serial
objects and the two are claimed by this.
I also created a new version of the Teensy USBToSerial example sketch
that if you configure USB type to Dual Serial or Triple Serial will output
SerialUSB1 to Serial2 and SerialUSB2 to Serial3, which works, and then
tried T4 configured for Dual plugged
into T4.1 with above sketch and could talk to both USB Serial adapters.
The Claim code was rearranged a lot, so hopefully did not break
anything.
But tested with
T4 as mentioned, both Single and Dual Serial
T3.2 with Single Serial, plus: Serial, Joystick, Keyboard...
FTDI - USB to Serial adapter (Sparkfun)
CP2104 - Adafruit
PL2303 - some clones ...
So hopefully most things are still working
Rework the mapping of PS4 buttons field in Bluetooth mode, to be the same as in USB mode. ALthough I left in code to map the HAT buttons to upper word of Butons. Maybe sometime might do same for USB/HID connection of PS4.
WIP for Swtitch controller to try to get leds and rumble to do something.
WIP - Not complete, but beginning to have it start to work when plugged in USB.
Needed to skip some descriptors to find the end point descriptor. Maybe should clean up some as to remove other special case.
Next need to understand the report data as it differs for normal XBOX360... Note It says it is an Xbox 360... Now it shows debug data with the data. Need to decide how best to know the data and inform the ;host code of the new messages
Some of the display may not have enough room on them to show everything, but they can work to show at least some of it.
Also got rid of comments and settings for like Beta1 T4 boards as real real boards exist now.
This is from our WIP2 Bluetooth branch which is about a year out of date.
I copied files to other location, then created this branch and used WinMerge to merge in all related changes,
Without hopefully undoing any of the other changes