T3.6 USB Host - Bluetooth

I am using a different dongle so this is what I get and then it just hangs after that:
Code:
USB Host Testing
960
*** Device Bluet a12:1 - connected ***
BluetoothController::find_driver  driver 200040d8
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
If I use a CSR 4.0 dongle I get this far now:
Code:
USB Host Testing
960
*** Device Bluet a12:1 - connected ***
  product: CSR8510 A10
BluetoothController::find_driver  driver 200040d8
JoystickController::claim_bluetooth TRUE
    *** Claimed ***
01 84 7f 7e 7f 08 10 01 00 00 
LX: 132, LY: 127, RX: 126, RY: 127 
L-Trig: 0, R-Trig: 0, Trig-Button: 16 
Buttons: 8, PS: 1

Joystick update Rumble/LEDs*** Device Bluet a12:1 - connected ***
  product: CSR8510 A10

Now to get back to defragster debug library :)
 
Yeah, that was what I was thinking but today is one of those days that I keep getting sidetracked with other projects around the house that I have to get done. Or it could be a power problem since I am coming off a USB2 port on the PC. Have to debug but time is limited today. Probably get to it tonight.

I connected one of the PJRC USB cable plugs I just got on a T_3.6 so I can test on that and 'other T$' unit. If I went through swapping the _usbH_debug for debug_tt as trace it would let me confirm the 'new' code still works on T_3.'s at the same time exploring this new use case for debug_tt.

I put a Bt dongle in Amazon (Kurt's?) cart but did not push order. I found two of same "Bt Dual Mode PANBT400" here and a MSFT Bt mouse & Keyboard and a Logitech K480 tri-switch {3 device selector} keyboard. Hope the dongles work - it seems they were not the best for PC's when I got them.

Given a pointer to the ideal starting code Kurt? or Mike? I might find energy to focus on that.
 
Tim
Use Kurt's repository version - he merged my changes in so both should match unless Kurt pushed something today.

BTW: I just finished updating core, hope I did it correctly, but I get a compile error when I try this, know I am doing it wrong:
Code:
#ifdef DEBUG_BT_VERBOSE
deb_tt( 4, pending_control_ );
    debTrace_tt( (uint32_t)pending_control_, __LINE__, "DBGPrintf("    Control callback (bluetooth): %d : ", pending_control_);" );
	//DBGPrintf("    Control callback (bluetooth): %d : ", pending_control_);
	uint8_t *buffer = (uint8_t*)transfer->buffer;
	for (uint8_t i=0; i < transfer->length; i++) {
deb_tt( 4, buffer[i] );
    debTrace_tt( (uint32_t)buffer[i], __LINE__, "DBGPrintf("%x ", buffer[i]);" );
		//DBGPrintf("%x ", buffer[i]);
	}
	DBGPrintf("\n");
#endif
Don't think it likes the pararens:
Code:
F:\arduino-1.8.8-t4\hardware\teensy\avr\libraries\USBHost_t36-WIP2-Bluetooth\bluetooth.cpp:319:72: error: expected ')' before 'Control'
     debTrace_tt( (uint32_t)pending_control_, __LINE__, "DBGPrintf("    Control callback (bluetooth): %d : ", pending_control_);" );
                                                                        ^
F:\arduino-1.8.8-t4\hardware\teensy\avr\cores\teensy4/debug_ttc.h:9:91: note: in definition of macro 'debTrace_tt'
 #define debTrace_tt( a, b, c ) { debTrace_ttf( (uint32_t) a, (uint32_t) b, (const char *) c, __LINE__, __func__); lastF_tt=(char*)__func__; lastL_tt=__LINE__; }

PS: Have no idea where _usbH_debug comes from - I am working in Bluetooth.cpp with the debugs set up as:
Code:
#ifndef DEBUG_BT
#undef DEBUG_BT_VERBOSE
void DBGPrintf(...) {};
#else
#define DBGPrintf Serial.printf
#endif

#ifndef DEBUG_BT_VERBOSE
void VDBGPrintf(...) {};
#else
#define VDBGPrintf Serial.printf
#endif
 
Mike - looking at the post. First note - maybe it helps:

The macro ::
Code:
#define debTrace_tt( a, b, c ) { debTrace_ttf( (uint32_t) a, (uint32_t) b, (const char *) c, __LINE__, __func__); lastF_tt=(char*)__func__; lastL_tt=__LINE__; }

Actually calls the _ttf() function - and it passes line and func as hidden params 4 and 5. It is also saving those hidden values in case something faults to track the last _tt call.

So that frees up Params 1 and 2 as uint32_t's and param #3 as (const char *).

So Param #3 is a (const char *) fixed C string.

The strings that a printf formatters are only on display's debTraceShow_tt
 
Got it - WEB fork and Desktop Clone of that - then WIP2-Bt branch and ' OPEN IN SUBLIME TEXT' - and it opens that folder with the indicated Bt examples.

If I'm parsing the intent perhaps this?
Code:
debTrace_tt( (uint32_t)pending_control_, 42 , "Concallback(Bt)" ); // Param #2 unused

Not sure how this was to resolve to a string for param #3?: >> "DBGPrintf(" Control callback (bluetooth): %d : ", pending_control_);"
 
Ok Tim. The bad news is with your changes the T4 got really bricked - I under the changes I made to debugprint.c and HardwareSerial and then it started working again. Thought followed them - I uncommented and inserted the changes per instructions.
 
Odd - should that be 'undid the changes'? Is that for higher baud on Serial#4 and the 'flush' code?

Ok. I think faster than my fingers can follow. Yes it should be "undid the changes". The answer is yes it was- higher baud rate on Serial4 and new "flush" code. Just in case I messed up I tried one of the examples and same thing had to press the button to upload then it would just hang as soon as I plugged it in - same thing that the BT lib was doing. I then tried to upload the standard BLINK - it said it uploaded but nothing ran. So I did the 15sec reset and removed the debug_tt changes. THen it worked.
 
Very Odd - using TyComm as only SerMon and uploader/ I've seen my share of oddities - but that doesn't sound right. And your serial port device ( Teensy running EchoBoth in my case ) was given the same baud rate? And it wasn't 'broken' out there to debug a fault or something?
 
Are we on a T4 issue? Does the Bt code run/fail the same on T_3.6 as T4? If T_3.6 is as good a test bed I could set that up and make sure the debug_tt stuff is good to go there. On T_3's I only ever got as far as using USB Serial for output, using &Serial was new for the beta - it was intended but not done until was forced to use Serial#'s on beta.
 
Tim
Not sure - will solder up a header to the T3.6 in the morning and give the sketch a try. Will also go back and give it another go to try and duplicate. I will post my steps as I go so you can see what I am doing but too late now to start this. Unless I can't sleep.
 
I think I'm awake enough to get it to work on T_3.6 and test USB at least with debug_tt.

<edit> Mike - unless the T4 faults the Serial#.prints should work without trouble and don't use the .flush() code?
 
Last edited:
Tim - My eyes are closing right now but I can't resist trouble shooting, that's the fun part. I will give it a try again.
 
Tim - My eyes are closing right now but I can't resist trouble shooting, that's the fun part. I will give it a try again.

I should get it set up here shortly after dinner and can see what I findAnd make sure the _tt helpers are working right and not adding trouble ...
 
I should get it set up here shortly after dinner and can see what I findAnd make sure the _tt helpers are working right and not adding trouble ...
Ok. Couldn't sleep thinking about this so I put in just the baud rate change and reran the trace_tt.ino example sketch. This time it worked fine, just like advertised.
Code:
j ___ ASSERT FAILED ___ FILE >> C:\Users\Merli\AppData\Local\Temp\arduino_modified_sketch_556351\Trace_tt.ino
 ___ in function >> setup()  at LINE# >> 63
 Expression >> 0

 >>>> ASSERT  >>>> ASSERT FAILED   
 >>>> debug_fault   >>>> debug_fault   >>>> TYPE:ASSERT
Debug Info:
lastL_tt:62  lastF_tt:setup
2 => 23171860	0x1619314	[L#85_C#1 _<< last func::setup

--- Halting >>>>  'y' to continue ...
	 'd' to call Debug_Dump()
	 'b' Teensy Bootloader
	 'r' Restart Teensy
	 'z' Zero Debug logs
usb_cdc_line_coding, baud=0
usb_cdc_line_coding, baud=115200
usb_cdc_line_coding, baud=115200

Even was able to upload blink with no issue. The only problem I had was I couldn't issue commands from the T3.2 to the T4 like 'd'. Nothing happened.

So I guess the bottom line is, you don't need to change .flush().

EDIT: its 11pm here so I may be done unless.... Think I will leave T3.6 until tomorrow though.
 
Good to see that came out usably.
I'll look at that and see what I see. As an Assert interrupts are running - this is just a normal code break. If the key entry like 'd' doesn't work I suspect your 'Terminal unit' is possibly getting in the way? - or perhaps since it looks like this is on the default Debug Serial4 it is intermixing with PJRC Debug Spew? As you could see in the sample I was using a separate path on Serial1.
 
I posted on T4 thread - USB T4 Joytstick and Mouse code worked.
Just plugged in the same mouse to T_3.6 and it works the same - recognized and worked except for the wheel:
*** HID Device Mouse1 46d:c044 - connected ***
manufacturer: Logitech
product: USB-PS/2 Optical Mouse

Both my Bt dongles seem to act the same. Without DEBUG - Nothing is printed.

Here is what I get from my Bt Dongle on T_3.6. :
Code:
USB Host Testing
960
sizeof Device = 36
sizeof Pipe = 96
sizeof Transfer = 64
power up USBHS PHY
 reset waited 4
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 1FFF5000
periodictable = 1FFF5000
port change: 10001803
    connect
  begin reset
port change: 10001805
  port enabled
  end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
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:
enumeration:
Manufacturer: Broadcom Corp
enumeration:
Product: BCM20702A0
enumeration:
Serial Number: 5CF37082D1E0
enumeration:
Config data length = 218
enumeration:
Configuration Descriptor:
  09 02 DA 00 04 01 00 E0 00 
    NumInterfaces = 4
    ConfigurationValue = 1
  09 04 00 00 03 FF 01 01 00 
    Interface = 0
    Number of endpoints = 3
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 81 03 10 00 01 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 16
    Polling Interval = 1
  07 05 82 02 40 00 01 
    Endpoint = 2 IN
    Type = Bulk
    Max Size = 64
    Polling Interval = 1
  07 05 02 02 40 00 01 
    Endpoint = 2 OUT
    Type = Bulk
    Max Size = 64
    Polling Interval = 1
  09 04 01 00 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 00 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 0
    Polling Interval = 1
  07 05 03 01 00 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 0
    Polling Interval = 1
  09 04 01 01 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 09 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  07 05 03 01 09 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 9
    Polling Interval = 1
  09 04 01 02 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 11 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  07 05 03 01 11 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 17
    Polling Interval = 1
  09 04 01 03 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 19 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  07 05 03 01 19 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 25
    Polling Interval = 1
  09 04 01 04 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 21 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  07 05 03 01 21 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 33
    Polling Interval = 1
  09 04 01 05 02 FF 01 01 00 
    Interface = 1
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 1 / 1
  07 05 83 01 31 00 01 
    Endpoint = 3 IN
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
  07 05 03 01 31 00 01 
    Endpoint = 3 OUT
    Type = Isochronous
    Max Size = 49
    Polling Interval = 1
  09 04 02 00 02 FF FF FF 00 
    Interface = 2
    Number of endpoints = 2
    Class/Subclass/Protocol = 255 / 255 / 255
  07 05 84 02 20 00 01 
    Endpoint = 4 IN
    Type = Bulk
    Max Size = 32
    Polling Interval = 1
  07 05 04 02 20 00 01 
    Endpoint = 4 OUT
    Type = Bulk
    Max Size = 32
    Polling Interval = 1
  09 04 03 00 00 FE 01 01 00 
    Interface = 3
    Number of endpoints = 0
    Class/Subclass/Protocol = 254 / 1 / 1
  09 21 05 88 13 40 00 10 01 
    HID, 64 report descriptors
enumeration:
USBHub memory usage = 960
USBHub claim_device this=1FFF22A0
USBHub memory usage = 960
USBHub claim_device this=1FFF2660
KeyboardController claim this=1FFF2020
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 00 00 03 FF 01 01 00 07 05 81 03 10 00 01 07 05 82 02 40 00 01 07 05 02 02 40 00 01 09 04 01 00 02 FF 01 01 00 07 05 83 01 00 00 01 07 05 03 01 00 00 01 09 04 01 01 02 FF 01 01 00 07 05 83 01 09 00 01 07 05 03 01 09 00 01 09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 01 00 02 FF 01 01 00 07 05 83 01 00 00 01 07 05 03 01 00 00 01 09 04 01 01 02 FF 01 01 00 07 05 83 01 09 00 01 07 05 03 01 09 00 01 09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 01 01 02 FF 01 01 00 07 05 83 01 09 00 01 07 05 03 01 09 00 01 09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 01 02 02 FF 01 01 00 07 05 83 01 11 00 01 07 05 03 01 11 00 01 09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 01 03 02 FF 01 01 00 07 05 83 01 19 00 01 07 05 03 01 19 00 01 09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 01 04 02 FF 01 01 00 07 05 83 01 21 00 01 07 05 03 01 21 00 01 09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 01 05 02 FF 01 01 00 07 05 83 01 31 00 01 07 05 03 01 31 00 01 09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
09 04 02 00 02 FF FF FF 00 07 05 84 02 20 00 01 07 05 04 02 20 00 01 09 04 03 00 00 FE 01 01 00 09 21 05 88 13 40 00 10 01 
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
KeyboardController claim this=1FFF2020
HIDParser claim this=1FFF2A20
HIDParser claim this=1FFF2F20
HIDParser claim this=1FFF44A0
HIDParser claim this=1FFF3420
HIDParser claim this=1FFF3920
BluetoothController claim this=1FFF3E20
Descriptor 33 = HID

And removal:
Code:
port change: 1C00100A
    disconnect
disconnect_Device:
USBDriver (available_drivers) list: 1FFF22A0 -> 1FFF2660 -> 1FFF2020 -> 1FFF2A20 -> 1FFF2F20 -> 1FFF44A0 -> 1FFF3420 -> 1FFF3920 -> 1FFF3E20
USBDriver (dev->drivers) list: (empty
USBDriver (available_drivers) list: 1FFF22A0 -> 1FFF2660 -> 1FFF2020 -> 1FFF2A20 -> 1FFF2F20 -> 1FFF44A0 -> 1FFF3420 -> 1FFF3920 -> 1FFF3E20
delete_Pipe 1FFF5400
  shut down async schedule
  Free transfers
  Free transfers attached to QH
    * 536827200
* Delete Pipe completed
removed Device_t from devlist
  disable
 
Kurt - ordered the Bt Dongle you are working with. You posted this last year - hopefully working? - this is an updated version Rii FMKBTL1-IV1 i8+ BT Mini Wireless Bluetooth . Got that and a Bt Logitech mouse and a generic cheap PS3 RumblePad. Amazon delivery Tuesday.

Let me know if the Bt dongles I have are usable - odd they get so much info w/debug and nothing without? KurtE I could send/give you one and still have one - ordered two of the new Bt_4's.

Will see if I get as far as adding _tt code - Looks like I could put it into the std USB code and see it run. Only thing odd would be the long claim string of claim ~200 byte values, not as compact as single digit row … and lots of them - about 24 sets - just for the dongle powering up with Mouse.ino.

Then I'll have to see how a Bt device is paired for use - which I can't see yet.

<edit>: Confirming debug_tt is not usable on T_3.6 - there isn't a #include "debug/printf.h" there. And other stuff needs #ifdef 1052.

<EDIT 2>: The error below was from copied macros lines 21 and 22 missing closing brace - that gets me to the REAL issues where I did have T$ code exposed to T_3.6. So the picture below is illustrative but problem there solved.

I can confirm though the USBHost code seems to be working the same with my old Bt on both MCU's I have with the current KurtE branch of WIP-2Bt.

Getting the hang of TyComm with 5 Teensy's and doing all builds from within Sublime w/Tset - double click on error line and whatever file it is opens with bold - and ' F4 ' jumps to next error. Seeing this where the warnings should not be and the error WAS puzzling - this is T_3.6 build where same code compiles no trouble on T$ - as noted above this is understood/fixed now:
T36usbH_tt.jpg
TTFN
 
Last edited:
Okay I can sleep now - updated T4_demo/... debug_tt compiles at least for T_3.6.

Works up to a point where Serial goes bonkers? Had to remove the T$ specific FAULT with GPT1_CNT in sketch as shown. The attempt to print the __func__ string fails.
This may be a memory issue that affects the whole of Trace as done? I was seeing something funny on T$'s first couple of chars in static string - but fine after that ???
Print below from code shows 'T4 connected' but it really is a T_3.6::
Code:
T:\tCode\libraries\debug_tt\examples\DebugMin_tt\DebugMin_tt.ino Feb 17 2019 05:03:46

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

>>> Reason for 'reset': 40 ExtResetPin :: done Reason
F_CPU==180000000   F_BUS==60000000
 FreeMem(); 235396
foo95() stack var: 2002FF94
foo addr: 46D
&ii addr: 2002FF90
&jj addr: 2002FF94
setup66() stack var: 2002FFC0
 ___ ASSERT FAILED ___ FILE >> T:\tCode\libraries\debug_tt\examples\DebugMin_tt\DebugMin_tt.ino
 ___ in function >> setup()  at LINE# >> 69
 Expression >> 0

 >>>> ASSERT  >>>> ASSERT FAILED   debug_tt Info:/t [Last debug_tt helper() L#:6

Goes to garbage after the :6 above.
 
Last edited:
T3.6 and Bluetooth

@KurtE/@defragster

I soldered up the USB header to the T3.6 and used the USB Cable from PRJC to connect a dongle. I uncommented verbose and it compiled and ran no issues - no hanging whatsoever. The only thing I noticed with the CSR dongle is that it keeps not connecting to the PS4:
Code:
*** Device Bluet a12:1 - connected ***
  product: CSR8510 A10
02 0F 01 4E 13 00 00 7A C0 01 02 00 04 04 24 0B 
BT rx_data(16): 2 f 1 4e 13 0 0 7a c0 1 2 0 4 4 24 b 
4D 
BT rx_data(1): 4d 
    Inquiry Result - Count: 1
      BD:4e:13:0:0:7a:c0, PS:1, class: 240404
02 0F 01 0A F0 F0 7F 3C 00 01 02 00 04 04 20 F9 
BT rx_data(16): 2 f 1 a f0 f0 7f 3c 0 1 2 0 4 4 20 f9 
6E 
BT rx_data(1): 6e 
    Inquiry Result - Count: 1
      BD:a:f0:f0:7f:3c:0, PS:1, class: 200404
02 0F 01 EA 94 9B E2 1F 00 01 02 00 04 04 20 26 
BT rx_data(16): 2 f 1 ea 94 9b e2 1f 0 1 2 0 4 4 20 26 
6E 
BT rx_data(1): 6e 
    Inquiry Result - Count: 1
      BD:ea:94:9b:e2:1f:0, PS:1, class: 200404
 
Hi guys,

Yep - the majority of the time, I have issues connecting as well some of the time it does connect, but most of the time not.

Note: to see that joystick has connected as part of Bluetooth, the current lists/code does not show it for a couple of reasons.

a) The bool() operator is not virtual, so when you have a list of devices, it uses the default operator to see if connected...
(device pointer != nullptr)...

b) Then the hid list is only testing for the hit device poitner not NULL, so again not match..

So In one test I added another list of BTHid devices...

Then found I was not yet setting the pointer in the BTHID for backchannel... So test was still failing...

I set this and it can show up on those few times it connects... But then thinking I have another back channel variable in the actual joystick object, that is for the Bluetooth object instead of just a generic device pointer. Was thinking of combining, but may then have to move a few class methods out of header into c++ file.

Had problems the first time I tried it, will try it again... Might have to move some functions from header file into C++ file (as to not use incomplete forward class definition...)


@defragster - Which bluetooth controller are you trying that does not work?
It would be interesting to see what the data is that is currently the tests for controller are:
Code:
// Lets try to support the main USB Bluetooth class...
	// http://www.usb.org/developers/defined_class/#BaseClassE0h
	if (dev->bDeviceClass != 0xe0) return false;	// not base class wireless controller
	if ((dev->bDeviceSubClass != 1) || (dev->bDeviceProtocol != 1)) return false; // Bluetooth Programming Interface
	if (type != 0) return false;
So wondering if it is failing one of these tests?

Now back to playing

What is the state of your using debug library stuff?

I was thinking of just changing a few things in the library to allow it to use different serial object.

That is maybe in header define something like #define USBHostDebugSerial Serial and allow this to be updated...
Then change a few places in the code that I am interested in. to use this constant.
In particular in print.cpp and then probably start off with changing any references to Serial in joystick.cpp and bluetooth.cpp to use this define... so setting the debug print in most places would redirect...
 
That is maybe in header define something like #define USBHostDebugSerial Serial and allow this to be updated...
Then change a few places in the code that I am interested in. to use this constant.
In particular in print.cpp and then probably start off with changing any references to Serial in joystick.cpp and bluetooth.cpp to use this define... so setting the debug print in most places would redirect...

Morning Kurt

May be a good idea and to see what happens. I have been posting over on the T4 thread about my trials and tribulations with the debug_BT and verbose. May want to take a look.

EDIT:
Bluetooth dongles tested:
https://www.amazon.com/Generic-Smal...&sr=8-4&keywords=generic+bluetooth+2.0+dongle

https://www.amazon.com/gp/product/B00VWEK4IG/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

https://www.amazon.com/gp/product/B076FP4KQD/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

That last one haven't had much success with.
 
What is interesting is I have at least 4 dongles, but all of them appear to be the same one. 2 of them just have on side marking: CSR 4.0 or CSR V4.0, One just says H.Guard on the front of it. And one that came with the Rii Keyboard, that did not have any markings. Ordered a couple others from Amazon, which who knows maybe ends up being the same...

It might be interesting to compare which dongles work with which libraries... Example here is a list of one that work with USB Host Shield 2:
https://github.com/felis/USB_Host_Shield_2.0/wiki/Bluetooth-dongles
 
Back
Top