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.
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.
WIP - I captured the USB packet information for the startup of a Bluetooth adapter. I am now in the process of understanding the data that is being sent back and forth and have the device now partially configured.
Nothing works yet!
Changed from claim at device level to interface level. such that the Microsoft Wireless controller can support multiple joysticks...
Tested with one joystick as I only have 1 (I think)...
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.
The main issue was I used a setup structure on the stack which turned into garbage. Earlier I thought the data was copied, but it was not...
Found that fixing this resolved the earlier issue where I needed to defer the update. So removed the defered code, plus use member variable for the one byte output instead of static variable.
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.
Added support for a another Serial type CH341.
Wip - But I do have it working so far at least with a loop back test (RX shorted to TX)
Also 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.
Will test more. I have several more cheap USB to serial adapter arriving tomorrow.
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.
Have some support in place for the CDCACM serial class code.
It appears to be working for talking to a
Teensy that is programmed USB=Serial
or USB=Serial+...
Also test with an USB2AX board which is a Servo controller for Dynamixel servos (AX-12), that is an Atmega32u2 board programmed using LUFA as the USB library.
instead of having each HUB have 7 buffers, which can eat up space. We have each main object contribute currently one string buffer, which than when we initialize a Device_t we try to allocate one for it, likewise we release it when the Device is released.
Hopefully less memory needed.
Also updated such that the HIDInput classes can not retrieve these strings.
Changed test program to now also have list of HIDInput objects and when I detect a new one, I again print out info on it...
Added the ability to query the
Manufactur, product name and serial number strings from a device.
WIP - Eats up lots of memory, next up experiment move from Device_t object to maybe top level objects. Probably fewer than them as each hub allocates something like 7 Device objects
This delta, adds an extra keyboard object to handle those keys that are not part of the main keyboard class. In particular there are separate HID reports for some of the keys, such as Power keys, and multimedia keys.
These reports might be on separate Interface or in cases where the mouse and keyboard are on the same device, the extra reports may be on the Mouse Interface.
So far I have not tried to combine with Keyboard object as might require multiple inheritance which I would like to avoid.
Also I extended the special key mapping table to map several other keys like F1-12, Arrow, Home/end... To special values where the 0x80 bit is set. I used the same values as used for the Arduino Keyboard library. I did not use their defines as they used defines like KEY_F1, which already exists in core, but in core it is the scan code from the keyboard and not the end user value.
PaulStoffregen
Kurt Eckhardt
neroroxxx