T3.6 USB Host - Bluetooth

@mjs513 - I had a version of the library code, but was using the shield 2 code...

Looks like I need to hack up the https://github.com/felis/USB_Host_Shield code to make it work now...
Like the board example does not compile... Looks like nothing changed in 7 years...
So need to get the pins to be defined, plus update to current stuff: Serial.print(c,BYTE)

EDIT: made the quick and dirty changes... Both of the ones failed with the same answer... May debug later.. Currently more of a diversion...
 
Last edited:
@mjs513 - I had a version of the library code, but was using the shield 2 code...

Looks like I need to hack up the https://github.com/felis/USB_Host_Shield code to make it work now...
Like the board example does not compile... Looks like nothing changed in 7 years...
So need to get the pins to be defined, plus update to current stuff: Serial.print(c,BYTE)

EDIT: made the quick and dirty changes... Both of the ones failed with the same answer... May debug later.. Currently more of a diversion...

Yeah. I just used that code for debugging. Otherwise I am using shield 2.0 code.

In the board_test sketch I changed BYTE to HEX and in Max3421e_constants.h I just hard coded the pin config - 10, 11, 12, 13.

Oops - I forgot - I have been using the mini shields I got direct from tkjelectronics to avoid the issues we are having now. Takes a little while to get but they work.

Oh - here is another connection map for you: https://www.circuitsathome.com/mcu/teensy-3-0-now-supported-by-the-usb-host-library/
 
Yeah. I just used that code for debugging. Otherwise I am using shield 2.0 code.

In the board_test sketch I changed BYTE to HEX and in Max3421e_constants.h I just hard coded the pin config - 10, 11, 12, 13.

Oops - I forgot - I have been using the mini shields I got direct from tkjelectronics to avoid the issues we are having now. Takes a little while to get but they work.

Oh - here is another connection map for you: https://www.circuitsathome.com/mcu/teensy-3-0-now-supported-by-the-usb-host-library/
Actually maybe we are wiring it up wrong... That is look at the bottom of yours: Again assuming:
https://smile.amazon.com/gp/product/B01EWW9R1E/

If you look at the labels on the pins from one edge it looks like: CS SCK MISO MOSI
Which is different... Will try rewiring...
 
Actually maybe we are wiring it up wrong... That is look at the bottom of yours: Again assuming:
https://smile.amazon.com/gp/product/B01EWW9R1E/

If you look at the labels on the pins from one edge it looks like: CS SCK MISO MOSI
Which is different... Will try rewiring...

Forewarning - tried that - but it doesn't work. There was a comment in one of the notes that said ignore that and wire it the way its shown for the real shield. If it works - then I did something wrong
 
@KurtE
Looks like I got Rumble to work somewhat, at least on first run, then it hangs,i.e, the sketch doesn't print anything but still receiving data on Serial1. Here is the output around when it hangs. Notice the change in data length and report type:
Code:
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 83 7c 7f 7e 8 4 0 2 0 
HID HDR Data: len: 11, Type: 1
Joystick update Rumble/LEDs
0b 20 53 00 4f 00 40 00 52 11 80 00 ff 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 83 7c 7f 7e 8 4 0 3 0 
HID HDR Data: len: 11, Type: 1
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 83 7c 7f 7e 8 4 0 b 0 
HID HDR Data: len: 11, Type: 1
Joystick update Rumble/LEDs

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 83 7c 7f 7e 8 4 0 c 0 
HID HDR Data: len: 11, Type: 1
tx_data callback (bluetooth): 0 : b 20 53 0 4f 0 40 0 52 11 80 0 ff 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 83 7c 7f 7e 8 4 0 e 0 
HID HDR Data: len: 11, Type: 1

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 83 7c 7f 7e 8 4 0 f 0 
HID HDR Data: len: 11, Type: 1

=====================
BT rx2_data(19): b 20 f 0 b 0 71 0 a1 1 83 7c 7f 7e 8 4 0 10 0 
HID HDR Data: len: 11, Type: 1

=====================
BT rx2_data(9): b 20 5 0 1 0 70 0 0 

=====================
BT rx2_data(64): b 20 53 0 4f 0 71 0 a1 11 c0 0 83 7c 7f 7e 8 4 8c 14 0 8c b e 65 0 f8 ff 12 0 9e 1 84 1c bd ed 0 0 0 0 0 7 0 0 0 0 80 0 0 0 80 0 0 0 0 80 0 0 0 80 0 0 0 0 
HID HDR Data: len: 79, Type: 17

=====================
BT rx2_data(23): 80 0 0 0 80 0 0 0 0 80 0 0 0 80 0 0 0 0 0 d6 10 13 63 

=====================
BT rx2_data(64): b 20 53 0 4f 0 71 0 a1 11 c0 0 83 7c 7f 7e 8 4 90 14 0 47 c e 68 0 f8 ff 11 0 6f 1 62 1c c7 ed 0 0 0 0 0 7 0 0 0 0 80 0 0 0 80 0 0 0 0 80 0 0 0 80 0 0 0 0 
HID HDR Data: len: 79, Type: 17

=====================
BT rx2_data(23): 80 0 0 0 80 0 0 0 0 80 0 0 0 80 0 0 0 0 0 18 43 3e f8 

=====================
BT rx2_data(64): b 20 53 0 4f 0 71 0 a1 11 c0 0 83 7c 7f 7e 8 4 94 1a 0 f0 f e 6d 0 f6 ff e 0 66 1 59 1c d6 ed 0 0 0 0 0 7 0 0 0 0 80 0 0 0 80 0 0 0 0 80 0 0 0 80 0 0 0 0 
HID HDR Data: len: 79, Type: 17
Instead of 0x41 I used 0x40.....

EDIT: I should add when it works :)
 
Last edited:
@mjs513 - will punt for now on the shield... I have a working one
IMG_0711.jpg

Rumble - sounds like maybe some progress? May have to figure out what SCID that is?
Will try in awhile.

May first look at mouse...
 
@KurtE

Think I am making a little more progress just now. Here are two data points for you.

SixAxis
HID Channels Established
SIXAXIS COMMAND ISSUED:
L2CAP_COMMAND: 0x0B - Channel ID: 00 40
Data: 0B 20 06 00 02 00 40 00 43 02
Note it uses 0x40 again for the SCID.

As for rumble, it looks like after it sends a rumble command it gets something:
RUMBLE COMMAND ISSUED:
L2CAP_COMMAND: 0x0B - Channel ID: 00 40
Data: 0B 20 53 00 4F 00 40 00 52 11 80 00 FF 00 00 2D 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Unknown Report type: 11
L2: 0 R2: 79
L2: 0 R2: 79
L2: 0 R2: 79
L2CAP Control: 00
This comes from a test in void BTHID::ACLData(uint8_t* l2capinbuf) { specifically:
Code:
                } else if(l2capinbuf[6] == control_dcid[0] && l2capinbuf[7] == control_dcid[1]) { // l2cap_control
#ifdef PRINTREPORT
                        Notify(PSTR("\r\nL2CAP Control: "), 0x80);
                        for(uint16_t i = 0; i < ((uint16_t)l2capinbuf[5] << 8 | l2capinbuf[4]); i++) {
                                D_PrintHex<uint8_t > (l2capinbuf[i + 8], 0x80);
                                Notify(PSTR(" "), 0x80);
                        }
#endif
                }
Not sure if it means anything yet.
 
@KurtE

Decided if I could get the sixaxis report working so I put it in the remote name function and tried to print out remotename, but I don't think the function is ever being called. Remote name is never printed to Serial1. Confused. But the one thing - the right rumble seems to be working consistently.
 
I've been paused on adding debug_tt to a branch of the USBHost - seems to be working and there are a plethora of paths and messages … and never sure the code isn't a moving target.

Almost decided to just do it as proof of concept last night but was already late for rest …

If most functions had a Trace call it would at least show an ordered code path and frequency for those things that might recur. Some prints are way deeper than handled in the quick info store - and some see/use strings that I'm not sure won't be gone by the time the ShowTrace might happen?

Mike have you updated much code since Kurt's last update?
 
Sounds like you are making progress... I am playing with figuring out different flow of messages for Mouse when it is not the initial bind...
Looking at what happens on host shield code: I get some debug messages like:
Code:
HID Bluetooth Library Started
Bluetooth Dongle Initialized
No response to HCI Reset
HCI Reset complete
Write class of device
Local Bluetooth Address: 00:1A:7D:DA:71:13
Wait For Incoming Connection Request
Mouse is connecting
Incoming Connection Request
Remote Name: BM30X mouse
Connected to Device: DC:2C:26:B3:58:3E
[COLOR="#FF0000"]L2CAP Connection Request - PSM: 00 11 SCID: 00 45 Identifier: 02[/COLOR]
HID Control Incoming Connection Request
HID Control Successfully Configured
Set protocol mode: 00
[COLOR="#FF0000"]L2CAP Connection Request - PSM: 00 13 SCID: 00 43 Identifier: 04[/COLOR]
HID Interrupt Incoming Connection Request
L2CAP Control: 00 
HID Channels Established
L2CAP Interrupt: A1 02 00 6A 02 00 dx=106 dy=2

L2CAP Interrupt: A1 02 00 00 00 00 
L2CAP Interrupt: A1 02 01 00 00 00 L Butt Dn

L2CAP Interrupt: A1 02 00 00 00 00 L Butt Up

Wait For Incoming Connection Request
L2CAP Interrupt: A1 02 01 00 00 00 L Butt Dn

L2CAP Interrupt: A1 02 00 00 00 00 L Butt Up
What I noticed here was the two connection requests, like I marked in RED. I am getting them as well in current code, but not casing the code on the PSM... That is their is control versus Interrupt... So put in case for that, to respond... But I am still in some place probably not responding correctly...

Code:
BT rx_data(1): 0
    Event: handle_hci_remote_name_complete(0)
    Remote Name: BM30X mouse
HCI_OP_ACCEPT_CONN_REQ called (09 04 07 3e 58 b3 26 2c dc 00 )
    Control callback (bluetooth): 0 : 9 4 7 3e 58 b3 26 2c dc 0
BT rx_data(6): f 4 0 1 9 4
    Command 409 Status 0
BT rx_data(10): 12 8 0 3e 58 b3 26 2c dc 0
BT rx_data(13): 3 b 0 b 0 3e 58 b3 26 2c dc 1 0
    Connection Complete - ST:0 LH:b
BT rx_data(5): 1b 3 b 0 5

=====================
BT rx2_data(16): b 20 c 0 8 0 1 0 2 2 4 0 11 0 43 0
    [COLOR="#FF0000"]L2CAP Connection Request: ID: 2, PSM: 11, SCID: 43[/COLOR]
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 02 08 00 70 00 43 00 01 00 00 00 )
tx_data callback (bluetooth): 201 : b 20 10 0 c 0 1 0 3 2 8 0 70 0 43 0 1 0 0 0
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 02 08 00 70 00 43 00 00 00 00 00 )
tx_data callback (bluetooth): 202 : b 20 10 0 c 0 1 0 3 2 8 0 70 0 43 0 0 0 0 0
L2CAP_ConfigRequest called(0b 20 10 00 0c 00 01 00 04 03 08 00 43 00 00 00 01 02 ff ff )
tx_data callback (bluetooth): 0 : b 20 10 0 c 0 1 0 4 3 8 0 43 0 0 0 1 2 ff ff

=====================
BT rx2_data(20): b 20 10 0 c 0 1 0 4 3 8 0 70 0 0 0 1 2 30 0
    L2CAP config Request: ID: 3, Dest:70, Flags:0,  Options: 1 2 30 0
      Control Configuration request
L2CAP_ConfigResponse called(0b 20 12 00 0e 00 01 00 05 03 0a 00 43 00 00 00 00 00 01 02 a0 02 )
BT rx_data(7): 13 5 1 b 0 2 0

=====================
BT rx2_data(22): b 20 12 0 e 0 1 0 5 3 a 0 70 0 0 0 0 0 1 2 30 0
    L2CAP config Response: ID: 3, Source:70, Flags:0, Result:0, Config: 201
Set HID Protocol 0 (0b 20 05 00 01 00 43 00 70 )
tx_data callback (bluetooth): 200 : b 20 5 0 1 0 43 0 70 3 a 0 43 0 0 0 0 0 1 2 a0 2
`ConnectionRequest called(0b 20 0c 00 08 00 01 00 02 04 04 00 13 00 71 00 )
BT rx_data(7): 13 5 1 b 0 2 0
tx_data callback (bluetooth): 0 : b 20 c 0 8 0 1 0 2
tx_data callback (bluetooth): 0 : b 20 c 0 8 0 1 0 2 4 4 0 13 0 71 0
BT rx_data(7): 13 5 1 b 0 2 0

=====================
BT rx2_data(16): b 20 c 0 8 0 1 0 2 4 4 0 13 0 45 0
[COLOR="#FF0000"]    L2CAP Connection Request: ID: 4, PSM: 13, SCID: 45[/COLOR]
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 04 08 00 71 00 45 00 01 00 00 00 )

=====================
BT rx2_data(9): b 20 5 0 1 0 70 0 0
tx_data callback (bluetooth): 203 : b 20 10 0 c 0 1 0 3 4 8 0 71 0 45 0 1 0 0 0
L2CAP_CMD_CONNECTION_RESPONSE called(0b 20 10 00 0c 00 01 00 03 04 08 00 71 00 45 00 00 00 00 00 )

=====================
[COLOR="#006400"]BT rx2_data(20): b 20 10 0 c 0 1 0 3 4 8 0 40 0 71 0 4 0 0 0
    L2CAP Connection Response: ID: 4, Dest:40, Source:71, Result:4, Status: 0
      Interrupt Response
L2CAP_ConfigRequest called(0b 20 10 00 0c 00 01 00 04 05 08 00 40 00 00 00 01 02 ff ff [/COLOR])
BT rx_data(7): 13 5 1 b 0 2 0
tx_data callback (bluetooth): 0 : b 20 10 0 c 0 1 0 4 5 8 0 40 0 0 0 1 2 ff ff
tx_data callback (bluetooth): 0 : b 20 10 0 c 0 1 0 4 5 8 0 40 0 0 0 1 2 ff ff

=====================
BT rx2_data(16): b 20 c 0 8 0 1 0 6 5 4 0 70 0 43 0
    L2CAP disconnect request: ID: 5, Length:4, Dest:70, Source:43

=====================
BT rx2_data(18): b 20 e 0 a 0 1 0 1 5 6 0 2 0 0 0 0 0
    L2CAP command reject: ID: 5, length:6, Reason:2,  Data: 0 0
BT rx_data(7): 13 5 1 b 0 1 0
BT rx_data(6): 5 4 0 b 0 13
    Event: HCI Disconnect complete(0): handle: b, reason:13
So next looking at the message in Green...
 
I've been paused on adding debug_tt to a branch of the USBHost - seems to be working and there are a plethora of paths and messages … and never sure the code isn't a moving target.

Almost decided to just do it as proof of concept last night but was already late for rest …

If most functions had a Trace call it would at least show an ordered code path and frequency for those things that might recur. Some prints are way deeper than handled in the quick info store - and some see/use strings that I'm not sure won't be gone by the time the ShowTrace might happen?

Mike have you updated much code since Kurt's last update?
Hi Tim,
I really haven't been updating too much code per se. Been going back and forth between ush2.0 on a T$ and the T3.6 code to sort out whats going on with rumble. Think I am getting closer to the solution.

I did have to be in a hack since joysticktype_ is always 0, not being identified correctly.
 
@KurtE and @defragster.
Think I figured out the problem and what the solution may be.

In going through the debug spew (+more debug statements that I added :) ). I noticed that once I got rumble to go off it would return a different report (pretty sure its now the 0x11 report) as shown below:
Code:
BT rx2_data(64): 48 20 53 0 4f 0 71 0 [COLOR="#FF0000"]a1 11 c0[/COLOR] 0 83 7f 81 80 8 0 a0 0 0 bb 70 e c 0 a 0 3a 0 48 ff 8c 21 42 fe 0 0 0 0 0 6 0 0 0 0 80 0 0 0 80 0 0 0 0 80 0 0 0 80 0 0 0 0 
HID HDR Data: len: 79, Type: 17

So I hacked the code just to try and read the output (naturally i got it wrong order)
Code:
  Joystick Data: 11 c0 00 83 7f 81 80 08 00 a0 00 00 bb 70 0e 0c 00 0a 00 3a 00 48 ff 8c 21 42 fe 00 00 00 00 00 06 00 00 00 00 80 00 00 00 80 00 00 00 00 80 00 00 00 80 00 00 00 00 48 20 53 00 4f 00 40 00 52 11 80 00 ff 00 00 00 0c 00 00 00 00
Once I did this rumble worked the way it should but I have all the data elements wrong. I think there is some remap axis function I may have to call to get it right.

BTW: The link to see the input report format is: http://eleccelerator.com/wiki/index.php?title=DualShock_4#0x11

[UPDATE] From https://code.woboq.org/linux/linux/drivers/hid/hid-sony.c.html#dualshock4_parse_report I found that report type 17

* The default behavior of the Dualshock 4 is to send reports using
* report type 1 when running over Bluetooth. However, when feature
* report 2 is requested during the controller initialization it starts
* sending input reports in report 17. Since report 17 is undefined
* in the default HID descriptor, the HID layer won't generate events.
* While it is possible (and this was done before) to fixup the HID
* descriptor to add this mapping, it was better to do this manually.
* The reason is there were various pieces software both open and closed
* source, relying on the descriptors to be the same across various
* operating systems. If the descriptors wouldn't match some
* applications e.g. games on Wine would not be able to function due
* to different descriptors, which such applications are not parsing.
*/
 
Sounds like you are making progress... Wonder if that other command that I was going to figure out how to send to get the "Full Report", would also return this same result?

Still playing with my Mouse issue... Next up figure out maybe to get more debug output from ush2... Try to get more of an idea of actual data differences sent/received...
 
I expect it will work after the last posted update - but won't know until it gets tried :)

Was thinking I could add a second Serial2 port to T_3.6 and EchoBoth to see it work and then output would be able to be separate.

Mike - Good luck on the Rumbling! - scanned your PS4 link : "If you look carefully, it is very similar to the reports sent over USB if you ignore the first 3 bytes."

KurtE - what is 'ush2' ? Have you got local changes for the Mouse progress? Is the 'BM30X mouse' your new Tech unit?

Maybe I'll start with Trace notes on all _isr events and see if it still runs. That may prove interesting with interrupts coming in during the processing which will need attention.
 
Sounds like you are making progress... Wonder if that other command that I was going to figure out how to send to get the "Full Report", would also return this same result?

Still playing with my Mouse issue... Next up figure out maybe to get more debug output from ush2... Try to get more of an idea of actual data differences sent/received...

I have been trying to get it send as well but since the reportname function is not called that command isn't issued.

Mike - Good luck on the Rumbling! - scanned your PS4 link : "If you look carefully, it is very similar to the reports sent over USB if you ignore the first 3 bytes."
It should be exactly the same. Looking through it now. Will have to create a new function since the usb version I dealing with usuage pages but we are not. Think I will work that tomorrow. Getting late now. You know what that means - if I cant sleep will work on it.

Just note once I get rumble working - it means I can get leds working and the dpad and motion stuff as well.
 
@KurtE and @defragter

Well guys here's the good news. Got Rumble working!. The bad news is that is till need to do some work on the report elements, LEDs etc and then for the clean up. Guess that's tomorrow.

Mike
 
@mjs513 :D

Still playing with mouse... I think I am probably missing some Ack or the like... Hopefully soon!
 
@mjs513 :D

Still playing with mouse... I think I am probably missing some Ack or the like... Hopefully soon!

Thanks - still more to do.

Good luck with the mouse - looking at the debug output from uhs20 helped a bit for me on what was suppose to happen.
 
Getting debug_tt working in USBHost - working with some changes pending. I put debug_tt on Serial2 from USBHost T_3.6 and then routed that to a T_3.1 EchoBoth Serial1 then cloned that xfer loop on Serial2 there to catch the write only Serial4 from T$ - confusing enough with 5 Teensy's without adding a 6th :)

With some Trace_tt embedded in Mouse I see activity - but no connection

With Mouse.Bt.ino:: The Logitech Mouse, MSFT mouse and Logitech keyboard that connect in the JoystickBt.ino never complete in Mouse.Bt.ino. Is there a reason for that?

The Trace_tt's show activity - including after entering the '0000' on keyboard - then nothing … unitl the final message when there seems to be a timeout on accepting devices and Bt blink goes solid.
 
Last edited:
MouseBt connected keyboard when I added :: Serial1.begin(1843200);
This was already done in JoystickBt but not MouseBt - both using the same code with all _debug enabled.

I didn't expect these results - it looks like this might be useful in tracking down some errors. My test usage is ham handed just to see it work - but even so it looks to show something? This goes along with failure when _DEBUG is disabled?

Here is a CodeCompare screenshot of the difference in Trace_tt messages from MouseBt.ino where LEFT is YES it works to connect Keyboard with Serial1.begin and RIGHT is NO connect of the keyboard [NO is when Serial.begin() is missing]::
CCYN.jpg
There are minor 'blue' diffs in the values on some otherwise same lines - usually just CycleCounter Values so ignore those.
These lines are printed at the END of each loop() in my use:: debTraceShow_tt( -4, "V1: %u", "\tV2: %u", "\tfunc %s" ); // -4 is NEW - print all lines and clear trace data on exit.
Here is my current Zipped copy of USBHost_t36 - and the two text files and the image file in one - don't feel like gihub now - just put in current debug.tt lib too.

Looking at these three YES only lines - I used different Trace commands in test - NOTE: Oldest is on Top as #3 [first two chars] - the next two came on the next loop() where newest is first, i.e. #2 is before #1 from the same loop()
#3: V1: 536822624 V2: 5439821 func BtC::rx_callback in transfer() L#:349
#1: V1: 15 V2: 6 func rx_data in rxbuf_[0]() L#:391
#2: V1: 536831168 V2: 6 func rx_data in transfer() L#:377
On the right is L# as LINE#:
for #349 V1 is 536822624 - that is from expression "transfer" in class Rx_callback - where I put the func name abbreviated and V2 is CYCCNT
void BluetoothController::rx_callback(const Transfer_t *transfer)
{
debTraceE_tt( transfer, ARM_DWT_CYCCNT, "BtC::rx_callback" );
for #391 V1 is "15" value of rxbuf[1] and V2 is len of 6 and that is in rx_data using __func__
if (rx_packet_data_remaining == 0) { // read started at beginning of packet so get the total length of packet
debTraceE_tt( rxbuf_[0], len, __func__ );
for #377- that is same Rx function and V1==transfer and V2==len
for (uint8_t i=0; i < len; i++) DBGPrintf("%x ", buffer);
DBGPrintf("\n");
debTraceE_tt( transfer, len, __func__ );

That suggests a clear bunch of callbacks missing when there is no Serial1 debug output! Those are just the funcs() I put a Trace on. Included copy of Debug_tt in case it looks fruitful and you can see how it works and customize it for your reading pleasure.

NOTE: I set up debug_tt on Serial2 so it does not interfere with USBHost _debug on Serial1 - other added sketch code is in setup()
NOTE: The code had/has a disable of TRACE logging during printing - this can/will result in loss of any messages coming from an interrupt as written.
NOTE: This is really ugly output as it was done based on the idea - before actual usage -
<add>: I put a master trace++ counter on - and I increment it before leaving when interrupt enters while disabled I see some trace elements getting lost indeed - one group of 7 it seems ( I did it quick&dirty so just approx. cnt). I'll make a way to add entries during print 'snapshot'. There is some correlation to blank printed lines and lost trace records - and that must go along with the floating spare numbers printed - like that 49 in both sides of the codecompare. This could be reduced if not printed while 'active' USB during the startup period - at least not EACH loop() exit until I get it fixed. The _isr pin could be used and put it at priority above USB and then add DebugDump to show the trace log - but that could cause USB to break being gone a few ms.
 
Last edited:
@defragster - Tim: Wow - you were busy last night

@KurtE - Well, rumble and leds work but got it work by kludging the call to setRumble. Do you have any ideas why PS4 is being identified as a joystick type because I am stuck.
 
@defragster - Tim: Wow - you were busy last night

@KurtE - Well, rumble and leds work but got it work by kludging the call to setRumble. Do you have any ideas why PS4 is being identified as a joystick type because I am stuck.
? I would assuming PS4 would be a joystick?

Did you mean it is not detected as a joystick?
I would look at the class data being passed to:
Code:
bool JoystickController::claim_bluetooth(BluetoothController *driver, uint32_t bluetooth_class) 
{
	if ((((bluetooth_class & 0xff00) == 0x2500) || (((bluetooth_class & 0xff00) == 0x500))) && ((bluetooth_class & 0x3C) == 0x08)) {
The value should be something like: 0x2508 or 0x508

Now if the data is not being handled... Then maybe it needs to support 504...

Look at document: https://www.bluetooth.com/specifications/assigned-numbers/baseband
Look for Peripheral devices...
 
Hi Kurt

Thanks for the hint, I will definitely check it out.

That code you added to identify joystickType as PS4 doesn't seem to be working anymore. [EDIT]PS4 gets connected and claimed as joystick but the type is never identified as PS4. So back to square one.

[EDIT2] This never seems to be called:
Code:
void JoystickController::remoteNameComplete(const uint8_t *remoteName)
So joystickType is always 0.
 
Hi Kurt

Thanks for the hint, I will definitely check it out.

That code you added to identify joystickType as PS4 doesn't seem to be working anymore. [EDIT]PS4 gets connected and claimed as joystick but the type is never identified as PS4. So back to square one.

[EDIT2] This never seems to be called:
Code:
void JoystickController::remoteNameComplete(const uint8_t *remoteName)
So joystickType is always 0.
Again check the function: void BluetoothController::handle_hci_remote_name_complete() {
Is it being called: DBGPrintf(" Event: handle_hci_remote_name_complete(%d)\n", rxbuf_[2]);

If so make sure you got my update fix, where remember the call for remoteNameComplete was commented out in the block above it...
 
Back
Top