KurtE
Senior Member+
Another quick Bluetooth update:
I have been tearing apart some of this code and probably screwing up everything
In particular, I have now broken up bluetooth.cpp into two files. More specifically the BluetoothController object used to have an array of structures, where each record in the array corresponds to one connection to a BT device. I have now converted that struct into a class and moved a lot of the code associated with a connection, to be methods on the new class. The new class was moved to a new file BluetoothConnection.cpp. Also, a new header file, was created with a lot of the defines that are used in the two files.
The new file now has the code to talk to SDP (and L2CAP). The BLuetooth Claim code now asks each of the BTHID objects if they wish to claim the connection directly. If no one claims it, it thentries to connect up to SDP and if so, tries to retrieve the HID Descriptor. If that succeeds, then it has a copy of parse() that it then walks through the descriptor and again asks each of the BTHID objecs if they
wish to claim a collection or not... (like HID except I added BT_ to the start of the HID methods). If a report descriptor is not found, it calls again to each of the BTHID objects with a different value for option and sees if anyone wishes to claim it now.
UPdated Keyboard and Mouse so far.
I now have the Rii mini-keyboard working with this. And now if the sketch has both Mouse and Keyboard, they will both claim topusage reports from this object.
Tested some with a couple of others.
Still lots more testing to go. Also have not gone through the Paring code path. yet so probably busted. I am hoping as part of this, will be able to add a Paring method, such that you won't need to necessarily change the code and rebuild to support pairing a new device.
Also need other cleanup and extension. Like I know I have a name for the device, but don't think we save it anywhere.
I am also seeing if I can get rid of a few HACKS in the code. For example, we know the PS4, expects us to send the L2CAP commands to make connections, where most all other devices initiate the connection calls.
The code currently detects that it is a PS4 and special cases it by VID/PID.
But now thinking I can do it by some standard BT mechanism.
That is: When we send the HCI_ACCEPT_CONNECT, we receive back the event: Connection Complete.
Now if at that point I send out the request: HCI_ROLE_DISCOVERY,
We should get the event Command Complete, with some additional information:
Which in the PS4: case I see:
For some other device like a BT Mouse I see something like:
So for this command (the 09 08) there are 4 returned bytes:
00 Succeeded
(next two are connection handle)
The last byte is the interesting one:
00 for Mouse (and keyboard...) - 0x00 Current Role is Master for this Connection_Handle.
01 for PS4 - 0x01 Current Role is Slave for this Connection_Handle.
PS3 - <<(01):0E 07 01 09 08 00 48 00 00 (again shows as master)
Lots more experimenting!
But tomorrow is another day.
I have been tearing apart some of this code and probably screwing up everything
In particular, I have now broken up bluetooth.cpp into two files. More specifically the BluetoothController object used to have an array of structures, where each record in the array corresponds to one connection to a BT device. I have now converted that struct into a class and moved a lot of the code associated with a connection, to be methods on the new class. The new class was moved to a new file BluetoothConnection.cpp. Also, a new header file, was created with a lot of the defines that are used in the two files.
The new file now has the code to talk to SDP (and L2CAP). The BLuetooth Claim code now asks each of the BTHID objects if they wish to claim the connection directly. If no one claims it, it thentries to connect up to SDP and if so, tries to retrieve the HID Descriptor. If that succeeds, then it has a copy of parse() that it then walks through the descriptor and again asks each of the BTHID objecs if they
wish to claim a collection or not... (like HID except I added BT_ to the start of the HID methods). If a report descriptor is not found, it calls again to each of the BTHID objects with a different value for option and sees if anyone wishes to claim it now.
UPdated Keyboard and Mouse so far.
I now have the Rii mini-keyboard working with this. And now if the sketch has both Mouse and Keyboard, they will both claim topusage reports from this object.
Tested some with a couple of others.
Still lots more testing to go. Also have not gone through the Paring code path. yet so probably busted. I am hoping as part of this, will be able to add a Paring method, such that you won't need to necessarily change the code and rebuild to support pairing a new device.
Also need other cleanup and extension. Like I know I have a name for the device, but don't think we save it anywhere.
I am also seeing if I can get rid of a few HACKS in the code. For example, we know the PS4, expects us to send the L2CAP commands to make connections, where most all other devices initiate the connection calls.
The code currently detects that it is a PS4 and special cases it by VID/PID.
But now thinking I can do it by some standard BT mechanism.
That is: When we send the HCI_ACCEPT_CONNECT, we receive back the event: Connection Complete.
Now if at that point I send out the request: HCI_ROLE_DISCOVERY,
We should get the event Command Complete, with some additional information:
Which in the PS4: case I see:
Code:
<<(01):0E 07 01 09 08 00 47 00 01
Command Completed!
Code:
<<(01):0E 07 01 09 08 00 48 00 00
Command Completed!00 Succeeded
(next two are connection handle)
The last byte is the interesting one:
00 for Mouse (and keyboard...) - 0x00 Current Role is Master for this Connection_Handle.
01 for PS4 - 0x01 Current Role is Slave for this Connection_Handle.
PS3 - <<(01):0E 07 01 09 08 00 48 00 00 (again shows as master)
Lots more experimenting!
But tomorrow is another day.