T3.6 USB Host - Bluetooth

Good to know Serial1 really works - as I knew it does - I added something ODD somewhere - doing output over multiple code paths print and printf. That bit me before on T$ as it was using the PJRC debug path w/printf and I had to add #undef.

I'll set aside what I have and pull over a fresh olde from github and make that work on T_3.6 as USB Serial:: debBegin_tt( (HardwareSerial*)&Serial, LED_BUILTIN, 12);

Perhaps that will be useful until I get the Serial1 cleaned up and my Bt hardware arrives Tuesday.

Just remembered today is my Wife's birthday … I knew last week … but mind has been a fog/tired. Her sister called this AM and … opps …

Kurt: yeah not sure TyComm will do baud setting xmit for Serial Terminal - it seems it was in once when I asked talking to the STM Ladybug or something … but that may just have been accept generic device not supply a baud.

Is this the right source for 9bis.net/kitty/? I have a powered Hub with 5 Teensy's on where 3 are as Serial<>USB converters - and it is a 7 port hub - so I could add more.

Mike - what OS do you run? Editor? Kurt told me about Sublime and it is basically great - and for Windows with Tset/Compile.cmd I can tab from Sketch to Sketch and hit "F7" to build and upload through TyComm. And with its regex parsing of console output - it walks through [with "F4"] any build errors across user/cores files with big red boxes holding the Error text on the problem line.
 
Well that was Trivial for T_3.6 to use USB Serial for output: https://github.com/Defragster/T4_demo/tree/master/debug_tt

Two working samples are the _tt ones :: DebugMin_tt and Trace_tt

They seem to setup and work on T_3.6 Serial and they were working for me before on T$ Serial1.

<edit> Then switch back to Serial1 and works a bit then garbage out …
___ ASSERT FAILED ___ FILE >> T:\tCode\libraries\debug_tt\examples\Trace_tt\Trace_tt.ino
___ in function >> setup() at LINE# >> 64
Expression >> 0

>>>> ASSERT��
...

Gotta return a computer and buy a cake ...
 
Last edited:
Tim: Happy Birthday to your wife - enjoy the rest of the day..

Right now I am using notepad++ and Arduino ide. May eventually switch over to sublime text but for now, know me I would screw something up so I am leaving it alone for now.

Tim-Kurt; Found a bug in the code that may have been causing the problem. Here is the corrected code that should connect better:View attachment USBHost_t36-WIP2-Bluetooth.zip

EDIT: forgot to ask will debug_tt now work with both T$ and T3.6
 
@KurtE
Just as a heads up for future use - I just tried an xbox controller and it doesn't want to pair. Will have to try wired approach.
 
Tim: Happy Birthday to your wife - enjoy the rest of the day..

Right now I am using notepad++ and Arduino ide. May eventually switch over to sublime text but for now, know me I would screw something up so I am leaving it alone for now.

Tim-Kurt; Found a bug in the code that may have been causing the problem. Here is the corrected code that should connect better:View attachment 15957

EDIT: forgot to ask will debug_tt now work with both T$ and T3.6

Debug_tt good (to try) on T_3.6 w/USB Serial, won't work on T$ for lack of Serial Read - both still broken on Serial1. Maybe I should try Serial2 for fun in case I added something

Sublime has some spectacular features ( i.e. learning curve for parts ) - but generally can be used like Notepad++. One Awesome thing is 'Open Folder' - puts all files/subdirs in left pane. Can do it for Teensy or USBHost and navigate to any file - and anything open there is open to Ctrl+Shift+F "FIND" - you can grep all of cores\teensy4 for anything and any use of it. And it scans the 'folder' and will offer color coding and right click 'jump to definition'. The rest just grows on you. The github TSet has readme that shows updating it to use Build Env to create and kickoff the compile.cmd - No OPEN IDE needed!

Amazon shipped my Bt stuff - will have it tomorrow.

Managed to return a computer - teach an old couple some new tricks and brought their 1603 build of Win 10 home to update past 1803 to 1809 and beyond. So wife got their cash with a birthday card and a pair of desserts - and a Steak Robert boxed dinner she picked … and gets to make.

Oh - Mike - when your T$ acts odd if on the pogo's give it a push. I'll walk through the prints in debug_tt and she what I can fix.
 
Making headway on T_3.6 [local copy no github update] - replacing the variety of prints with a call to printf_tt() which is just a cloned copy of the minimal PJRC vararg debug_printf. Output looks the same on USB Serial.

Some areas left to rewrite are still messing up the output to Serial1, but with those commented out is working far better so far :) The register dump is missing as is the original 'log' list, but the ASSERT expression and function names are printing, and it won't work when faulted - there is a PJRC FLUSH on all ports that I turned off - needs to be enabled in FAULT case only.
Here is a run with User input twice of 'd':Dump then 'y': continue ::
Code:
T:\tCode\libraries\debug_tt\examples\DebugMin_tt\DebugMin_tt.ino Feb 19 2019 04:13:47

********
 T4 connected Serial_1 *******  ONE

>>> Reason for 'reset': 40 ExtResetPin :: done Reason
F_CPU==180000000   F_BUS==60000000
 FreeMem(); 234988
foo102() stack var: 2002FF94
foo addr: 46D
&ii addr: 2002FF90
&jj addr: 2002FF94
setup68() stack var: 2002FFC0
TESTING 1 2 3 ...456... xyz
123456	TESTING ABC.
[COLOR="#FF0000"] ___ ASSERT FAILED ___ FILE >> T:\tCode\libraries\debug_tt\examples\DebugMin_tt\DebugMin_tt.ino[/COLOR]
 ___ in function >> setup() at LINE# >> 76 Expression >> (100 - 98 - 2)
 ___ ASSERT FAILED ___ 'y' to continue ...
	 'd' to call Debug_Dump()
	 'b' Teensy Bootloader
	 'r' Restart Teensy
	 'z' Zero Debug logs
Debug_Dump32() stack var: 2002FF7C
 User Custom Debug Dump. Micros==5166915
#1: CycCnt 3718074482	line 111	func foo	in F():foo [ii:4]l#:111
#2: CycCnt 3718074482	line 108	func foo	in F():foo [ii:3]l#:108
#3: CycCnt 3718074482	line 105	func foo	in F():foo [ii:2]l#:105
#4: CycCnt 3718074482	line 103	func foo	in F():foo [ii:1]l#:103
#5: CycCnt 3718074482	line 100	func foo	in F():foo [ii:0]l#:100
setup addr: 725
&ii addr: 2002FFC0
_:L=121: DebugTest2
_:L=90: setup
_:L=93: setup
[COLOR="#FF0000"] ___ ASSERT FAILED ___ FILE >> T:\tCode\libraries\debug_tt\examples\DebugMin_tt\DebugMin_tt.ino[/COLOR]
 ___ in function >> setup() at LINE# >> 94 Expression >> (0 * micros())
 ___ ASSERT FAILED ___ 'y' to continue ...
	 'd' to call Debug_Dump()
	 'b' Teensy Bootloader
	 'r' Restart Teensy
	 'z' Zero Debug logs
Debug_Dump32() stack var: 2002FF7C
 User Custom Debug Dump. Micros==18539882
#1: CycCnt 1233456678	line 92	func setup	in F():setup [ii:5]l#:92
#2: CycCnt 1233456584	line 92	func setup	in F():setup [ii:4]l#:92
#3: CycCnt 1233456490	line 92	func setup	in F():setup [ii:3]l#:92
#4: CycCnt 1233456396	line 92	func setup	in F():setup [ii:2]l#:92
#5: CycCnt 1233456087	line 92	func setup	in F():setup [ii:1]l#:92
#6: CycCnt 1233443883	line 84	func You 'r here	in F():setup [ii:0]l#:84
 
Hi Mike and Defragster - was mostly busy yesterday with other stuff. I did try to rewire the Usb host 2 board to the T3.5 and the SPI on it did not want to talk at all. I also remember trying it with an Arduino mini like board a year or so ago and no response then either, so figured board is probably a dud and ordered another one... Will arrive probably Thursday.

Mike I pulled down your changes and not sure if I am seeing much in changes. Will try more today.
I know awhile ago I tried XBox one controller, but don't remember how well it worked, probably worked USB, but I know I was hacking on making it work with BT as I know I had to repair it with our actual XBox...

As I think I mentioned, the XBox 360 I believe has it's own wireless communications (not BT) and for example they sell a PC adapter for them so you can use them wireless with PC, so I did not take it any further.

Now back to playing

Update tried again and changed the dongle and now PS4 controller appears to bind correctly :D Looks like there still is an issue with setting the rumble?
 
Last edited:
Hi Mike and Defragster

Mike I pulled down your changes and not sure if I am seeing much in changes. Will try more today.
I know awhile ago I tried XBox one controller, but don't remember how well it worked, probably worked USB, but I know I was hacking on making it work with BT as I know I had to repair it with our actual XBox...

As I think I mentioned, the XBox 360 I believe has it's own wireless communications (not BT) and for example they sell a PC adapter for them so you can use them wireless with PC, so I did not take it any further.

Now back to playing

Update tried again and changed the dongle and now PS4 controller appears to bind correctly :D Looks like there still is an issue with setting the rumble?

I was making a bunch of changes yesterday to see why the PS4 was having trouble connecting. Traced to the sketch. (1) I had 64 elements for getaxisps4 - had to change this to 10 and (2) joystickdataclear was hanging somewhere - could trace to where the problem was so just uncommented it and then all worked again

Yes, rumble still doesn't work. Can't figure that one out yet. :)
 
RUMBLE - Getting closer

After looking a the output between the uhs2 and ours using sendl2command. Fixed something dumb I did and added 42,0 for scid. It works once, but then doesn't. have to see if I have to reset something. Heres the correct rumble code
Code:
		uint8_t packet[79];
	    memset(packet, 0, sizeof(packet));
	    packet[0] = 0x52; 
	    packet[1] = 0x11;      // Report ID
		packet[2] = 0x80;
		packet[4] = 0xFF;

	    packet[7] = lValue; // Small Rumble
	    packet[8] = rValue; // Big rumble
	    packet[9] = 0; // RGB value 
	    packet[10] = 0; 
	    packet[11] = 0;

	    // 9, 10 flash ON, OFF times in 100ths of sedond?  2.5 seconds = 255
	    USBHDBGSerial.printf("\n Joystick update Rumble/LEDs \n");
     	btdriver_->sendL2CapCommand(packet, sizeof(packet), 0x42, 0x00);
 
@mjs513 - PS4 - I am completely hacking (or unhacking the code) depending on how you look at it...

I am removing all of the new PS4 functions...

What I have done is to add a member function to BTHIDInput
virtual void remoteNameComplete(const uint8_t *remoteName) {};

Where the Joystick code implements it:
Code:
void JoystickController::remoteNameComplete(const uint8_t *remoteName) 
{
	// Sort of a hack, but try to map the name given from remote to a type...
	if (!remoteName) return;

	if (strncmp((const char *)remoteName, "Wireless Controller", 19) == 0) {
		USBHDBGSerial.printf("  JoystickController::remoteNameComplete %s - set to PS4\n", remoteName);
		joystickType = PS4;
	}

}
Then the rest of the code knows that it is a PS4....

So now the process hid data looks like:
Code:
bool JoystickController::process_bluetooth_HID_data(const uint8_t *data, uint16_t length) 
{
	// Example data from PS4 controller
	//01 7e 7f 82 84 08 00 00 00 00
	//   LX LY RX RY BT BT PS LT RT
	//USBHDBGSerial.printf("JoystickController::process_bluetooth_HID_data\n");
	// May have to look at this one with other controllers...
	if (data[0] != 1) return false;
	
	//print("  Joystick Data: ");
	//print_hexbytes(data, length);
	//USBHDBGSerial.printf("  Joystick Data: ");
	uint64_t mask = 0x1;
	axis_mask_ = 0;
	axis_changed_mask_ = 0;
	for (uint16_t i = 0; i < length; i++ ) {
		axis_mask_ |= mask;
		if(data[i] != axis[i]) { 
			axis_changed_mask_ |= mask;
			axis[i] = data[i];
		} 
		mask <<= 1;	// shift down the mask.
		//USBHDBGSerial.printf("%02x ", axisPS4[i]);
	}
	//USBHDBGSerial.printf("\n");
    joystickEvent = true;
	connected_ = true;
	return true;
}
So now the test app is looking like the normal test app, like:
Code:
  if (joystick1.available()) {
      if (first_joystick_message) {
        Serial.printf("*** First Joystick message %x:%x ***\n", 
            joystick1.idVendor(), joystick1.idProduct());
        first_joystick_message = false;

        const uint8_t *psz = joystick1.manufacturer();
        if (psz && *psz) Serial.printf("  manufacturer: %s\n", psz);
        psz = joystick1.product();
        if (psz && *psz) Serial.printf("  product: %s\n", psz);
        psz =joystick1.serialNumber();
        if (psz && *psz) Serial.printf("  Serial: %s\n", psz);        
      }
      
      for (uint8_t i = 0; i<10; i++) {
          psAxis[i] = joystick1.getAxis(i);
      }

      Serial.printf("LX: %d, LY: %d, RX: %d, RY: %d \r\n", psAxis[1], psAxis[2], psAxis[3], psAxis[4]);
      Serial.printf("L-Trig: %d, R-Trig: %d, Trig-Button: %d \r\n", psAxis[8], psAxis[9], psAxis[6]);
      Serial.printf("Buttons: %d, PS: %d\r\n", psAxis[5], psAxis[7]);
      Serial.println();
  
    uint8_t ltv;
    uint8_t rtv;

        ltv = joystick1.getAxis(8);
        rtv = joystick1.getAxis(9);

        if ((ltv != joystick_left_trigger_value) || (rtv != joystick_right_trigger_value)) {
          joystick_left_trigger_value = ltv;
          joystick_right_trigger_value = rtv;
          joystick1.setRumble(ltv, rtv);
        }
        
     joystick1.joystickDataClear();
  }
And all of thie appears to be working (except rumble), I moved your PS4 rumble code into the earlier feedback function: transmitPS4UserFeedbackMsg
And I have most of the PS4 specific functions and data member removed or commented out.

Will post an updated version soon (or maybe check in?)
 
Here is the updated version, see what you think?
 

Attachments

  • USBHost_t36.zip
    136.4 KB · Views: 61
Jeez KurtE.
This is getting more and more complicated. Let me give the zip a test and then check-in :).

Rumble still giving me a problem - sometimes it works. It could be something with scid or the HCI handle. Those are the two things that are different between UHS2 and the packet we send.
 
@KurtE

Just had a chance to look more closely - had to go into the garage and straighten up in there awhile today.

Glad you were able to get the ps4 specific stuff incorporated - figured we could do that at some point. Just one issue I am having now that I didn't dig into. After I substitute your sketch changes and update the library I get this error from the sketch:
Code:
JoystickBT:137: error: 'first_joystick_message' was not declared in this scope
       if (first_joystick_message) {

Any ideas?

EDIT: NEVER MIND - MY ERROR>didn't look at your whole sketch

EDIT2: Ok got it to compile and run. It does identify the ps4 on Serial1. But the strange thing is, while it connects (the blue light stays on and serial1 indicates that its connected) nothing is printed from the sketch unless I uncomment the debug defines in Bluetooth.

EDIT3: I left everything unplugged a while and now it works fine. Must be me loading things too fast
EDIT4: Ok back to not working
 
Last edited:
@mjs513 - The check for which controller PS4 was inspired by the host shield 2 code that did the string compare... So decided to do the same thing.

The first joystick message stuff can easily be removed, I was curious if I was grabbing in proper names and the like. The answer is NO... I am thinking in that callback that does the string compare, I will probably stuff out the string into one of our logical string objects, and probably stuff it in and maybe retrun it in the product() member...

Currently if it was working the members for manufacturer, product, serialNumber would return information about the BT dongle and not the actual device you are interacting with.

Not sure why yours is working off and on. I do notice that the time it takes for the connection to happen is not consistent. Sometimes it happens quick other times, several seconds, some time it feels like I have to hold the PS button down... But I sort of remember similar issues when connecting on Linux...

I am thinking about going ahead and push it back to github...
 
Amazon boxes were on the front porch - hopefully PS3 was a good USBHost supported investment? The Rii and PS3 plugged in and charging. Logitec Mouse and two Bt CSR 4.0 dongles at the ready.

Got another couple hours until I can get back to where I was last night with debug_tt, then power this Bt stuff up. Let me know where the latest is if it changes. As of last night the Trace code - the most useful/low overhead for recording the USBHost connect events looked to be ready to record live events and display after the dust settles so it can hopefully be always on during development and then selectively queried - including an _isr() button break.

With the change to all printf_tt() it offers better printing format so swapping that in over the prior single/multiple (string)&(value) overlapped .print()'s can be cleaner looking in the end. Since this isn't Faulting I can work that in later at the single point of code that is included
 
Likewise some packages arrived at my mailbox this morning...

Including my two new dongles arrived today. The one ZexMTE looks like another instance of the other ones I have:
*** Device Bluet a12:1 - connected ***
product: CSR8510 A10

The other one labeled Techkey 4.0+EDR does not appear to be recognized…
Device Descriptor:
12 01 00 02 FF 01 01 40 5C 0A E8 21 12 01 01 02 03 01
VendorID = 0A5C, ProductID = 21E8, Version = 0112
Class/Subclass/Protocol = 255 / 1 / 1
Number of Configurations = 1
enumeration:
Sound familiar? Wonder if I need to add VID:pID table to work around?

Is this the same ones that don't work for you as well? Note: I turned on the debug printing and this was part of the earlier stuff...
I may have to debug what the configuration data is...

Right now I am hacking on adding the remote name to a string object... So a calling app can get to it as well. The last zip file is pretty close to what I have now, just playing with the strings stuff...

Then I may get distracted some with the second package that arrived today:
IMG_0710.jpg
 
Kurt
Here is where I am right not with the testing. On startup it is not returning any info on the PS4. This is all I see:
Code:
*** Device Bluet a12:1 - connected ***
*** First Joystick message 0:0 ***

Right now I am just leaving the debug prints turned because the PS4 connects right up without an issue. Maybe like you said its a timing issue.

I would go ahead and push your changes, since that is pretty much where we want to be.

Tim
Glad you got your amazon packages :). Going to have fun testing everything.

Good you got debug_tt working. Good idea to go over to print_tt(). Nicer formatting.
 
Kurt
Our messages crossed. Very cool spider -- will have to do that one of these days - think that will be a good project for the T4.
Sound familiar? Wonder if I need to add VID:pID table to work around?
Sounds very familiar. The EDR dongle I have doesn't work either

EDIT: Just for reference the CSR4.0 dongle, product: CSR8510 A10, does work. Just tested with all the changes we been making.

Oh, forgot where did you get the spider
 
@KurtE
Ok.. Last post; for the edr dongle I noticed in uhs2 code:
Code:
// These dongles do not present themselves correctly, so we have to check for them manually
#define IOGEAR_GBU521_VID       0x0A5C
#define IOGEAR_GBU521_PID       0x21E8
#define BELKIN_F8T065BF_VID     0x050D
#define BELKIN_F8T065BF_PID     0x065A
 
Okay - using you ZIP p#87 above new Bt dongle shows:
*** Device Bluet a12:1 - connected ***
product: CSR8510 A10

I put batteries in the mouse - how do I get T_3.6 to own it? Mouse is sitting with blinking lights ...

I see the 0xFF Vender Specific on the TechKey :( … I packed up the Olde PANBT400 ones to ignore for now - if that matches it should show in prior post.

I did not get a free Bt dongle with the Ver:0d+BT/A/2.8 of the Rii unit.
 
Hi Tim
Think you need to modify this line usbhost_t36
Code:
class MouseController : public USBHIDInput {

to
Code:
class MouseController : public USBHIDInput, public BTHIDInput {

I think Kurt mentioned that awhile ago in the other thread or someplace - cant remember where. Have to fix mine as well
 
Thanks - have not been following such details yet - hoping the debug_tt would be working by now.

I made this edit - is that to auto connect the ready Bt mouse?
Code:
// T:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\USBHost_t36\USBHost_t36.h
//class MouseController : public USBHIDInput {
class MouseController : public USBHIDInput, public BTHIDInput {
public:
 
Thanks - have not been following such details yet - hoping the debug_tt would be working by now.

I made this edit - is that to auto connect the ready Bt mouse?
Code:
// T:\arduino-1.8.8T4_146\hardware\teensy\avr\libraries\USBHost_t36\USBHost_t36.h
//class MouseController : public USBHIDInput {
class MouseController : public USBHIDInput, public BTHIDInput {
public:
That should do it.
 
Was poking around the UHS2 code to see why our version of rumble wouldn't be working, thought maybe it needed a little delay. But any, awhile ago I mentioned that the PS4 controller should be sending out not only the joysticks and buttons but also the accelerometer, gyro, pad data. In the uhs code I came across this function:
Code:
        void enable_sixaxis() { // Command used to make the PS4 controller send out the entire output report
                uint8_t buf[2];
                buf[0] = 0x43; // HID BT Get_report (0x40) | Report Type (Feature 0x03)
                buf[1] = 0x02; // Report ID

                HID_Command(buf, 2);
        };
Maybe we need to check this out.
 
Back
Top