Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 28 FirstFirst 1 2 3 4 12 ... LastLast
Results 26 to 50 of 683

Thread: T3.6 USB Host - Bluetooth

  1. #26
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    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

  2. #27
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    Quote Originally Posted by mjs513 View Post
    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.

  3. #28
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    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

  4. #29
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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

  5. #30
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    Looking at github KurtE is this the right branch:: USBHost_t36/tree/WIP2-Bluetooth - 3 days since update?

  6. #31
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    Quote Originally Posted by defragster View Post
    Looking at github KurtE is this the right branch:: USBHost_t36/tree/WIP2-Bluetooth - 3 days since update?
    Yep. You should see a couple of BT examples (joystickBT and mouseBT)

  7. #32
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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_);"

  8. #33
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    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.

  9. #34
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    Odd - should that be 'undid the changes'? Is that for higher baud on Serial#4 and the 'flush' code?

  10. #35
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    Quote Originally Posted by defragster View Post
    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.

  11. #36
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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?

  12. #37
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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.

  13. #38
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    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.

  14. #39
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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 by defragster; 02-17-2019 at 02:21 AM.

  15. #40
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    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.

  16. #41
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    Quote Originally Posted by mjs513 View Post
    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 ...

  17. #42
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    Quote Originally Posted by defragster View Post
    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.

  18. #43
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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.

  19. #44
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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

  20. #45
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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:
    Click image for larger version. 

Name:	T36usbH_tt.jpg 
Views:	16 
Size:	78.2 KB 
ID:	15942
    TTFN
    Last edited by defragster; 02-17-2019 at 11:23 AM.

  21. #46
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,799
    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 by defragster; 02-17-2019 at 12:12 PM.

  22. #47
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    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

  23. #48
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,870
    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...

  24. #49
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,472
    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-Small...oth+2.0+dongle

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

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

    That last one haven't had much success with.

  25. #50
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,870
    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_Sh...etooth-dongles

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •