Fix typo

Fix typo

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

It shows up with name XBox360 for Windows (at least the version I have)...

But at least it is starting to give some data

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

Turns out they are a lot different than other PS3 controllers.

When plugged into USB, it appears like these units do not send
any reports.  They do allow us to do pairing (which is differnt)
than other PS3, as well as set the Bulb LED color, which I now
have it alternating colors every few seconds and also it tries
to pair it with a BT dongle

When connected to Bluetooth, it now is setup to generate reports,
as well as again set the bulb color and rumble.

So far it maps the 3 button bytes into the buttons field and then
simply copies most all of the data down into Axis, starting where
the Trigger button is.

JoystickBT.ino was updated, to know about this controller and as
mentioned above in the USB case it tries to pair and plays with the
color of bulb.

In the BT case it tries to display data.  I did a quick and dirty
change of the Accel/Gyro like stuff which is probably totally wrong.

Pressing some of the buttons will set bulb color and pressing trigger
will set rumble.

PS3 Motion controller - very little mapping of axis

Added support for the Sony Playstation Move navigation controller,
and maybe it's alternative one...

Add example app showing Mouse, Tablet, Joystick... Data on an ILI9341 display

Thanks mostly to Mike (@mjs513) - a WIP to support some of the digitizer tablets that are not properly supported by Mouse.

Like Wacom Intous...

Did some quick edits, to try this out on my T4. beta

Decided maybe needed top header to mention this currently requires SPIN, ILI9341_t3n libraries, Also thought I would mention which pins, which I made different for T3.6 versis T4.

Also removed the ili9341_due_config.h file as nothing in it was used.

And added a message to the screen saying it was waiting for Joystick object.

Fixed the order of bytes output when we show a bluetooth address.

Also moved the updated JoystickBT example up one level, such that the new version overwrote the previous version...

Did quick test with PS3...

Trying out using the extended Inquiry data search instead of the real simple one.  This allows us to hopefully get the name of the device as part of this, which now allows the PS4 to know it is a PS4 on the Pair type constructor.

Still WIP to understand XBox one...

Support to pair PS3 if it knows the BTADDR and user presses select and PS button and plugged in USB.

Remembers remote name, and tries to get it when PAIR version of code is running.  (Currently fails).

Does some mapping of PS3 Bluetooth data to match USB HID data.

Warning: as part of debuggigng why joystickType value was changing, I changed the class to make it a function you call instead of just a member variable.  Should mark it inline...  I think I caught all of the places in example code that was accessing it.  If we find we want ability for user probram to update it, should add another member to explicityly set it.

I have some PS3 support working... Hope I did not break PS4.... ;)

Also This assumes that you did a bind of the dongle to PS3 external, no support yet, I did this on RPI3...

Rumble needs work!

PS4 starting to work, Still some rumble issues.

Also some WIP parts for caching remote name

Some of these changes also came from @mjs513

The first gigabyte fix, was to always force the keyboard into boot protocol mode, which appeared to work well for all of the keyboards I tried.

Unforationally it caused issues with some wireless keyboard/mouse combo packages, including some logitech and some microsoft keyboards.

This version instead, I created a list (currently only one vendor id), of vendor id:product id, that need to be forced into boot mode.  Knowing that if there is one keyboard vendor with this N key rollover feature, there are probably others.  So while this list can be expanded, this requires users to update library.  So added a method forceBootProtocol method to keyboard class that allows the user to try it out without needing to update the library sources.

The mouse test program has example of either setting it before the keyboard is initiated, as well as another way that when a connection is found it asks for the vendor id, and if it is the one of my gigabyte keyboard, it calls the function then.

While doing this I found some of the query functions like idVendor on the keyboard class would not compile as the keyboard object has multiple inheritence and both base classes have this.  So like the joystick objects I added these to the top level function and these functions will direct the calls to the approrpriate places.

Support for using the Microsoft XBox 360 wireless receiver for windows
to be able to communicate with XBox 360 wireless controllers.

In theory this should support up to 4 controllers.  So far I have only
tested with one as I only have one.

Added a joystick only test that should support up to 4 joystick objects.

With this update, I can now talk to the keyboard without having to repair each time.

Still WIP

Code is still WIP, needs lots of reorg and fix up and lots more to figure out.

But started working toward the Bluetooth HID devices and have the messages going back and forth from my BT dongle to a small BT keyboard.
It is finally showing keys being pressed and the like.

Code needs lots of work.  Like does pairing everytime, need to make that optional.

Also need to figure out where to split off the HID stuff from Root BT stuff.  ...

Plus it mainly prints lots of debug information.

Decided to have a joystick only test that has 4 joystick objects, to test XBox 360 wireless controller

WIP - So far i am getting the basic values for 1 XBox 360 controller.  The device should handle up to 4 devices, but so far hard coded to only handle 1...

Added support for Joysticks, that on some of them we can not receive more of the Joysticks axis.  So far mainly on PS3 and PS4.  So you can now get the Gyro/accel stuff.  You get feedback on the DS4 touch area, PS3 you can get the pressure values on several of the buttons.  LIke the RT/LT ones.

In addition added some support for Rumble.  So far it appears to be working somewhat on the PS3 and PS4 controllers.  On the PS4 you can also set the RGB LED light values and on the PS3 you can set the 4 LEDS on the front., which are normally used to say which controller it is.

While the other Joystick objects currently supported by the USB Host
code are driven by HID data, the Xbox does not contain HID data and
instead works at the top level.

To handle this I made the Joystick object use multiple InHeritence like:
class JoystickController : public USBDriver, public USBHIDInput

This allowed me to have the object work either way.  This did add some
complexity in that some of the methods like  is the object connected
(The bool operator) had to be overwritten as both of the bases classes
had it.  In addition needed to update the other query functions to be
able to grab the data from mydevice or device depending on which type of
controller was connected.

Since this looked like a valid way, I then merged the Keyboard Extras
code that Keyboard and made it also do a similar multiple inheritance.
In this case however I restricted the HID top level report handle code
to only accept it if on the same object that claimed the keyboard.

The mouse test app was updated as well

Needed HID Parser to support Bidirectional Transfers

The HidParser code was setup such that the claim for a report, the caller could say I want to claim the whole thinig and allowed callback functions for processing of in buffer and out buffer.

Allow RawHID to contribute Transfer_t

Since RawHID may need more resources than most, maybe it should contribute the additional structures

The constructor for a RAWHID object allows you to specify the top usage
that it wishes to connect to.  I used this for example to be able to
connect to a Teensy with the RAWHID associated with emulating the
Serial object.

If a HID Input class says that it wants to claim the whole interface, I
reuse the buffer associated with holding the HID descriptor and use it
for output buffers.

As per the forum posts, worked on combining the claim code for extracting which endpoints are RX and TX and create the pipes and the like.

Also worked on live cases.  Reading and writing to AX servos... Found some issues Probably more to find.

I left in some debug code to help find cases of deleting a pipe may hang.  Also macros in serial.cpp to set or toggle IO pins (when in debug mode). This helps find where things are happing using Logic Analyzer as a way to find the approriate USB packets.

I did a quick test using the Serial test app, where I can type in lines like:
#38400,7E1
And it reopens the serial port at the specified baud and format.  Note the formats the test app looks for is 7E1, 7O1, 8N1, 8N2.

Tested on an FTDI, PL2303 and CH341.  I also tested going to Teensy 3.2 CDCACM.  But as far as I know the teensy could not care less about Baud/Format.

Unless of course there is a way to query the value and use it to set a Hardware Serial port to it.

This commit adds support for at least some of the Serial boards with the
CH341 chipset, tested using a board from sparkfun as well as one from
Amazon.com

The code was rearranged some of the Claim code and added a VID:DID to Serial Type table that I use to map, such that I know some of these devices have multiple valid setups.

Support Begin/End/Begin - Change baud

Added code to support switching baud rates, or more particular be able to call end() and then call begin(...) with same or different baud rate.

Hopefully some support for also releasing DTR when the end is called.

WIP - Start support for the begin(baud, format)

Adding some support to the code to handle some of the different possible format capabilities.

In particualar trying to handle the parity, number of bits and number of stop bits.

hacked up test app, such that if you type in command line like:
"#9600, 7e1"

It will extract the 9600 as the new baud and try to use format 7e1.  I only hard coded a few of these in the test app (8n1, 7e1, 7e2, 8n2)...

Again work in progress.  Took me awhile tofigure out how to do this for ch341 boards as I did not see any documents or code that handled this.  So had to deduce it from differences in USB packets.

This commit should start to allow some Prolific PL2303 devices to work.
Tis device has a rather more complex initialization process than some
of the other devices.

I have tested this some with one device that I used to use to program
some older RS232 based boards plus talk to an SSC-32 device.
Test case is I am able to talk to SSC-32 and if I type in ver<cr>
It does properly return the version number.

The data I am seeing is pretty close to what
was documented in: https://gist.github.com/tommie/89011c5ac06553d5cdb8
as well as what the Linux driver outputs.

I also incorperated Frank's configuration options.