Forum Rule: Always post complete source code & details to reproduce any issue!
Page 103 of 152 FirstFirst ... 3 53 93 101 102 103 104 105 113 ... LastLast
Results 2,551 to 2,575 of 3789

Thread: Teensy 4.0 First Beta Test

  1. #2551
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,509
    FLEXCAN on Pins0/1

    Doing some regression testing on the Flexcan sdk example I had working previously on CAN2 (this is not CAN-FD). This was running back in March timeframe. Now on the 1052 it seems to be hanging and on the 1062 nothing until I disconnect from the USB and then I see a message on the receiving T3.6:
    Code:
    *HEARTBEAT* 364471
    MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 27263 ID: 801 Buffer: 0 1 2 3 4 1 2 3 
    *** MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 27263 ID: 801 Buffer: 0 1 2 3 4 1 2 3 
    *HEARTBEAT* 368494
    *HEARTBEAT* 372834
    *HEARTBEAT* 377174
    *HEARTBEAT* 381514
    *HEARTBEAT* 385854
    *HEARTBEAT* 390079
    MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 50848 ID: 801 Buffer: 0 1 2 3 4 1 2 3 
    *** MB 8  LEN: 8 EXT: 0 REMOTE: 0 TS: 50848 ID: 801 Buffer: 0 1 2 3 4 1 2 3
    which is what I am suppose to see. But the funny thing is the CAN library that @tonton81 is developing works on both the 1052 and the 1062 without a problem. Going to do a little debugging to see what the issue is since it is probably the same issue affecting the CANFD sdk example. So if anyone has any ideas let me know.

    EDIT: OK Found the problem - got the example sdk working minor problem - me being a dummy
    Last edited by mjs513; 04-28-2019 at 04:09 PM.

  2. #2552
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,903
    Quote Originally Posted by PaulStoffregen View Post
    Does anyone want to suggest alternates? Total PCB footprint width needs to be under 13 mm.
    @Paul - this is a long shot, but maybe something like what we use for the other Surface mount pins? Except maybe the .05" version?
    Maybe the single row version?

    Something like: https://www.digikey.com/product-deta...-08-ND/1786403
    It fits the 13mm, but probably take to much room in the other direction...

    Also if went this type of route, question would be do you still need the voltage/gnd pins here or not?...

    But probably the best answer is - Stay with what you have and SHIP IT!

  3. #2553
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Quote Originally Posted by PaulStoffregen View Post
    I've committed the first code to implement Serial.available() and Serial.read().

    https://github.com/PaulStoffregen/co...d8cec244d44b22

    This is still a work-in-progress. It's not efficient. Some functions like Serial.peek() and Serial.readBytes(buffer, len) are still not implemented. But at least basic reception on Serial should be working now.
    Downloaded cores and copied over. Indeed this works:
    Code:
      while ( Serial.available() ) {
        HW_SERIAL.print( (char)Serial.read() );
      }
    Serial prints not guarded like this:
    Code:
        if ( Serial ) {
          Serial.print( " Loop Hz " );
          Serial.println( ii );
        }
    Cause loop() to stall - but debug Serial4 continues to spew "status = 00090080" in that state so the processor is running.

    So testing "if ( Serial )" works.

    And Serial.print when !Serial stalls loop(), but continues when Serial returns.

  4. #2554
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Quote Originally Posted by KurtE View Post
    @Paul - this is a long shot, but maybe something like what we use for the other Surface mount pins? Except maybe the .05" version?
    Maybe the single row version?

    Something like: https://www.digikey.com/product-deta...-08-ND/1786403
    It fits the 13mm, but probably take to much room in the other direction...

    Also if went this type of route, question would be do you still need the voltage/gnd pins here or not?...

    But probably the best answer is - Stay with what you have and SHIP IT!
    Expect SHIP IT is the best answer - unless perhaps another PCB REV is required.
    But something like that - combined with the pads on the other end would allow bringing all those bottom side pads up over SMD components to a daughter board for use - without resorting to POGO or other things since mating a castellated board is out. And indeed seems it would be possible to drop GND and 3V3 pads from the array and have it work in that case bringing them from 'elsewhere'.

  5. #2555
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,665
    @Paul, I have a very big application - TeensyConvolutionSDR which needs more ITCM and more DTCM - any chance that you can inrease both? 256K for both would be fine, as a start..

  6. #2556
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    I switched to TyComm for SerMon as it has a Serial 'On/Off' button without closing a window.

    It is showing very good startup connect times of Serial:
    T:\tCode\T4\BlinkMinNewUSB\BlinkMinNewUSB.ino Apr 28 2019 13:10:38
    Setup First millis=305 // entered SETUP()
    Serial First millis=392 // Serial online for use in 379 to 414 ms in a few trials.
    This was just some old sketch modified :: T:\tCode\T4\BlinkMinNewUSB\BlinkMinNewUSB.ino

    what this is printing is the number of passes through loop:
    Loop Hz 11874357
    >> NO SERIAL Loop Hz 11923986
    That shows 11,874,357 when Serial is present
    and taking Serial offline and skiping those prints to USB and only Serial4 gives 11,923,986

    That is a LOT of passes through loop() !!!!!

    Giving a void yield(){} ups the counts a bit:
    Loop Hz 12446534
    >> NO SERIAL Loop Hz 12498453
    Adding this in that loop:
    Code:
      digitalWriteFast( 13,1 );
      digitalWriteFast( 13,0 );
    results in this while still sending the print strings:
    Loop Hz 11639261
    >> NO SERIAL Loop Hz 11686858
    And change to digitalWrite() with a variable pin# drops to:
    Loop Hz 7113010
    >> NO SERIAL Loop Hz 7142074
    For Comparison a T_3.6 at 240 MHz {need to unlock 256} gives there digitalWriteFast() with a constant in the above code including startup time from above:
    Setup First millis=300
    Serial First millis=365
    Loop Hz 3478245
    and digitalWrite() with var pin# is:
    Setup First millis=300
    Serial First millis=386
    Loop Hz 1951228
    And T_3.6 without the digitalWrite()'s :: Loop Hz 4000044 @240 Mhz

  7. #2557
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,173
    Quote Originally Posted by defragster View Post
    Cause loop() to stall - but debug Serial4 continues to spew "status = 00090080" in that state so the processor is running.
    I am intentionally leaving this behavior until after I've worked out all the cases in the schedule_transfer() function (which was formerly named usb_transmit).

    I know it's inconvenient. Please know I am aware, and the decision to leave this in for now it a very intentional choice on my part. The solution for working around when the PC side isn't listening tends to mask other issues, so fixing this behavior is pretty much the very last thing I intend to do on the USB code.

  8. #2558
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Quote Originally Posted by PaulStoffregen View Post
    I am intentionally leaving this behavior until after I've worked out all the cases in the schedule_transfer() function (which was formerly named usb_transmit).

    I know it's inconvenient. Please know I am aware, and the decision to leave this in for now it a very intentional choice on my part. The solution for working around when the PC side isn't listening tends to mask other issues, so fixing this behavior is pretty much the very last thing I intend to do on the USB code.
    Understood, makes great sense - and excellent to know as it will be worthwhile incorporating into Beta sketches.

    The best thing is "if(!Serial)" working and is an option to prevent the stalling.

    Also thought showing the 'status' value presented might confirm something for you to be as expected.

  9. #2559
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,665
    Quote Originally Posted by defragster View Post
    11923986

    Giving a void yield(){} ups the counts a bit:Loop Hz 12446534
    that's not "a bit"

    it's equivalent to 27MHz. How many UNOs are that? Assuming 8MHz/Uno, > 3 UNOs lost... Or do they use 16MHz? Dunno...

    Edit: yield has to become faster. way faster. and without disabling interrupts 11923986/second.
    Edit: We need to add a flag that tells us if there is any "event" pending and return immediately if not. 99.9999% of software would benefit. everything that does not use events.
    Code:
    void yield () {
    if (!EventPending) return;
    ....
    }
    Last edited by Frank B; 04-28-2019 at 09:44 PM.

  10. #2560
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    @Paul: are there any 'status =' values that worry you that we shouldn't ignore? When we are running debug out they get in the way so I keep doing the below to kill that line. And they intermix with Serial4 usage since it is connected.

    @FrankB >> And has debug :: // if (count > 10) printf("status = %x\n", status);

    8 bit Uno is 16 Mhz

    Without the debug 'status' print and adding yield() back with :: digitalWriteFast( 13, !digitalReadFast( 13 ) );
    I am seeing this many passes through loop() where it alternates between two with Serial on then stabilizes with !Serial::
    Loop Hz 9019501
    Loop Hz 9156013
    >> NO SERIAL Loop Hz 9021564
    >> NO SERIAL Loop Hz 9021562
    >> NO SERIAL Loop Hz 9021564
    @mjs513 - I got my 5 pack of encoders like yours - do you have a sample sketch you could put on github.com/mjs513/WIP ?

  11. #2561
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    serialEvent() also not being called

    Update link to here in Msg #6:
    Not present is recurring call to delay() and normal Arduino loop() cycling::
    Code:
    // Normal T_3.x 
    main() {
      setup();
      while(1){
        loop();
        delay();
      }
    }
    Last edited by defragster; 05-29-2019 at 06:53 AM.

  12. #2562
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,509
    Quote Originally Posted by defragster View Post
    @Paul: are there any 'status =' values that worry you that we shouldn't ignore? When we are running debug out they get in the way so I keep doing the below to kill that line. And they intermix with Serial4 usage since it is connected.

    @FrankB >> And has debug :: // if (count > 10) printf("status = %x\n", status);

    8 bit Uno is 16 Mhz

    Without the debug 'status' print and adding yield() back with :: digitalWriteFast( 13, !digitalReadFast( 13 ) );
    I am seeing this many passes through loop() where it alternates between two with Serial on then stabilizes with !Serial::


    @mjs513 - I got my 5 pack of encoders like yours - do you have a sample sketch you could put on github.com/mjs513/WIP ?
    There were two sketches I used. The first is the basic encoder sketch from the Encoder library. + can go to 3.3v and the DT&Clk are your signals. The middle pin is actually a switch you can use. The sketch I tested with was the encoder sdk sketch which is already on GitHub. Here is one just for the fun of it:
    Code:
    /* Arduino New Rotary Encoder Pin states
    Created by Yvan / https://Brainy-Bits.com
    This code is in the public domain...
    You can: copy it, use it, modify it, share it or just plain ignore it!
    Thx!
    */
    
    volatile boolean TurnDetected;  // need volatile for Interrupts
    
    // Rotary Encoder Module connections
    const int PinCLK=0;   // Generating interrupts using CLK signal
    const int PinDT=1;    // Reading DT signal
    
    // Interrupt routine runs if CLK pin changes state
    void rotarydetect ()  {
      TurnDetected = true;  // set variable to true
    }
    
    void setup ()  {
      Serial.begin(2000000);  // high rate to assure good capture
      attachInterrupt (PinDT,rotarydetect,CHANGE); // interrupt 0 always connected to pin 2 on Arduino UNO
    }
    
    void loop ()  {
      if (TurnDetected)  { // rotary has been moved
          TurnDetected = false;  // do NOT repeat IF loop until new rotation detected 
          Serial.print("CLK Pin: ");
          Serial.println(digitalRead(PinCLK));
          Serial.print("DT Pin: ");
          Serial.println(digitalRead(PinDT));
          Serial.println();
          //delay(5);
      }
    }

  13. #2563
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Left this running while out for lunch - Under 2 hours since last post - came back and computer USB CHIMES device OUT?? I wasn't doing anything ...
    Code:
    // https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=193998&viewfull=1#post193998
    // https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=194174&viewfull=1#post194174
    
    #define HW_SERIAL Serial4 // pin 17 debug Tx only
    
    void yield() {}
    
    uint32_t SFirstIn = 0;
    uint32_t SFirst = 0;
    uint32_t ii = 0;
    elapsedMillis noDelay;
    void setup() {
      SFirstIn = millis();
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWrite( LED_BUILTIN, HIGH );
      Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
      HW_SERIAL.begin( 115200 );
      //Serial4.begin( 1843200 );
      HW_SERIAL.print( "   millis=" );
      HW_SERIAL.println( millis() );
      Serial.print( "   millis=" );
      Serial.println( millis() );
      while ( !Serial ) {
        Serial.println( millis() );
        ii++;
      }
      Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
      Serial.println( millis() );
      SFirst = millis();
      Serial.print( "   Setup First millis=" );
      Serial.println( SFirstIn );
      Serial.print( "   Serial First millis=" );
      Serial.println( SFirst );
      Serial.print( "   while Count ii=" );
      Serial.println( ii );
      delayMicroseconds( 100 );
      ii = 0;
      noDelay = 0;
    }
    
    int x13 = 13;
    bool flip = true;
    bool unGuarded = false;
    void loop() {
      ii++;
      //digitalWriteFast( x13,flip );
      //  digitalWriteFast( x13,1 );
      //  digitalWriteFast( x13,0 );
      //digitalWriteFast( 13, !digitalReadFast( 13 ) );
      if ( noDelay > 1000 ) {
        noDelay -= 1000;
        //digitalWrite( LED_BUILTIN, flip );
        flip = !flip;
        HW_SERIAL.print( " Loop Hz " );
        HW_SERIAL.println( ii );
        if ( Serial || unGuarded ) {
          Serial.print( " Loop Hz " );
          Serial.println( ii );
        }
        else {
          HW_SERIAL.print( " >> NO SERIAL " );
        }
        ii = 0;
      }
      if ( Serial.available() ) {
        unGuarded = !unGuarded;
        if ( unGuarded )
          HW_SERIAL.print( "\n\n UNGarded SERIAL " );
        else
          HW_SERIAL.print( "\n\n Garded SERIAL " );
        while ( Serial.available() ) {
          HW_SERIAL.print( (char)Serial.read() );
        }
      }
    }
    T42 not blinking ** - no data write on connected USB ... or the Serial4 as I was sharing it above.
    <edit> ** - just noticed this code did not have and LED blink effect.

    Debug Serial4 showed::
    // ...
    Loop Hz 12494027
    Loop Hz 12494029
    Loop Hz 12493965
    Loop Hz 12496162
    Loop Hz 12493834
    usb_cdc_line_coding, baud=0
    usb_cdc_line_coding, baud=115200
    usb_cdc_line_coding, baud=115200
    usb_cdc_line_coding, baud=115200
    From USB I entered "66666" with TyComm and Serial4 showed this - I think the 115200 lines came along:
    usb_cdc_line_coding, baud=115200
    usb_cdc_line_coding, baud=115200
    run_callbacks
    rx event, len=6, i=0
    Which shows USB got the five 6's and NewLine. Entering more text in TyComm gave: "[send@5794870-Teensy] I/O error while writing to '\\.\COM25'"

    Code did not respond - no blink and no I/O USB or Serial4. And nothing since on Serial4/DEBUG.

    I opened TLoader Verbose and here is the tail of that when I heard USB Chime and saw it was nto running:
    Code:
    15:57:33.359 (ports 5): callback C115
    15:57:35.398 (ports 5): callback C115
    15:57:36.561 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    15:57:36.562 (ports 5): nothing new, skipping HID & Ports enum
    15:57:37.414 (ports 5): callback C115
    15:57:39.392 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    15:57:39.393 (ports 5): nothing new, skipping HID & Ports enum
    15:57:39.422 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    15:57:39.423 (ports 5): nothing new, skipping HID & Ports enum
    15:57:39.437 (ports 5): callback C115
    15:57:41.467 (ports 5): callback C115
    15:57:43.487 (ports 5): callback C115
    
    16:12:32.870 (ports 5): callback C115
    16:12:34.889 (ports 5): callback C115
    16:12:36.909 (ports 5): callback C115
    16:12:38.929 (ports 5): callback C115
    16:12:39.751 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:12:39.752 (ports 5): nothing new, skipping HID & Ports enum
    16:12:40.022 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:12:40.023 (ports 5): nothing new, skipping HID & Ports enum
    16:12:40.038 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:12:40.039 (ports 5): nothing new, skipping HID & Ports enum
    16:12:40.058 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:12:40.059 (ports 5): nothing new, skipping HID & Ports enum
    16:12:40.944 (ports 5): callback C115
    16:12:42.559 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:12:42.560 (ports 5): nothing new, skipping HID & Ports enum
    16:12:42.577 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:12:42.578 (ports 5): nothing new, skipping HID & Ports enum
    16:12:42.967 (ports 5): callback C115
    16:12:44.992 (ports 5): callback C115
    16:12:47.013 (ports 5): callback C115
    
    16:27:37.930 (ports 5): callback C115
    16:27:39.955 (ports 5): callback C115
    16:27:41.981 (ports 5): callback C115
    16:27:42.856 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:27:42.857 (ports 5): nothing new, skipping HID & Ports enum
    16:27:44.011 (ports 5): callback C115
    16:27:44.415 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:27:44.415 (ports 5): nothing new, skipping HID & Ports enum
    16:27:44.430 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:27:44.431 (ports 5): nothing new, skipping HID & Ports enum
    16:27:46.027 (ports 5): callback C115
    16:27:48.045 (ports 5): callback C115
    
    16:42:41.940 (ports 5): callback C115
    16:42:43.968 (ports 5): callback C115
    16:42:45.960 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:42:45.961 (ports 5): nothing new, skipping HID & Ports enum
    16:42:46.000 (ports 5): callback C115
    16:42:48.029 (ports 5): callback C115
    16:42:48.302 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:42:48.303 (ports 5): nothing new, skipping HID & Ports enum
    16:42:48.318 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:42:48.319 (ports 5): nothing new, skipping HID & Ports enum
    16:42:50.055 (ports 5): callback C115
    16:42:52.079 (ports 5): callback C115
    16:57:43.375 (ports 5): callback C115
    16:57:45.395 (ports 5): callback C115
    16:57:46.119 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:57:46.120 (ports 5): nothing new, skipping HID & Ports enum
    16:57:47.416 (ports 5): callback C115
    16:57:47.468 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:57:47.469 (ports 5): nothing new, skipping HID & Ports enum
    16:57:47.482 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    16:57:47.483 (ports 5): nothing new, skipping HID & Ports enum
    16:57:49.457 (ports 5): callback C115
    16:57:51.467 (ports 5): callback C115
    16:57:53.494 (ports 5): callback C115
    17:01:39.686 (ports 5): callback C115
    17:01:41.705 (ports 5): callback C115
    17:01:43.536 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    17:01:43.537 (ports 5): remove: loc=usb:0/140000/0/8/7
    17:01:43.537 (ports 5): usb_remove: usb:0/140000/0/8/7
    17:01:43.537 (ports 5): remove: loc=usb:0/140000/0/8/1
    17:01:43.537 (ports 5): usb_remove: usb:0/140000/0/8/1
    17:01:43.537 (ports 5): nothing new, skipping HID & Ports enum
    17:01:43.537 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    17:01:43.538 (ports 5): nothing new, skipping HID & Ports enum
    17:01:43.547 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    17:01:43.548 (ports 5): nothing new, skipping HID & Ports enum
    17:01:43.554 (ports 5): WM_DEVICECHANGE DBT_DEVICEREMOVECOMPLETE
    17:01:43.554 (ports 5): nothing new, skipping HID & Ports enum
    17:01:43.745 (ports 5): callback C115
    17:01:43.745 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    17:01:43.745 (ports 5): nothing new, skipping HID & Ports enum
    17:01:43.968 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    17:01:43.968 (ports 5): nothing new, skipping HID & Ports enum
    17:01:44.172 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    17:01:44.174 (ports 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#863660#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    17:01:44.174 (ports 5): found_usb_device, loc=usb:0/140000/0/8/1    Port_#0001.Hub_#0009
    17:01:44.174 (ports 5): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0275
    17:01:44.174 (ports 5): found_usb_device, devinst=00000005
    17:01:44.174 (ports 5): add: loc=usb:0/140000/0/8/1, class=Ports, vid=16C0, pid=0483, ver=0275, serial=863660, dev=\\?\usb#vid_16c0&pid_0483#863660#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    17:01:44.174 (ports 5):   comport_from_devinst_list attempt
    17:01:44.174 (ports 5):   found Ports in classguid_list at index=0
    17:01:44.174 (ports 5):   port COM19 found from devnode
    17:01:44.174 (ports 5): found_usb_device complete
    17:01:44.175 (ports 5): usb_add: usb:0/140000/0/8/1  COM19 (Teensy 3.2) Serial
    17:01:44.181 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    17:01:44.181 (ports 5): nothing new, skipping HID & Ports enum
    17:01:44.187 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    17:01:44.188 (ports 5): nothing new, skipping HID & Ports enum
    17:01:44.214 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    17:01:44.215 (ports 5): nothing new, skipping HID & Ports enum
    17:01:44.238 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    17:01:44.239 (ports 5): found_usb_device, id=\\?\usb#vid_16c0&pid_0483#5794870#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    17:01:44.239 (ports 5): found_usb_device, loc=usb:0/140000/0/8/7    Port_#0007.Hub_#0009
    17:01:44.239 (ports 5): found_usb_device, hwid=USB\VID_16C0&PID_0483&REV_0279
    17:01:44.239 (ports 5): found_usb_device, devinst=00000022
    17:01:44.239 (ports 5): add: loc=usb:0/140000/0/8/7, class=Ports, vid=16C0, pid=0483, ver=0279, serial=5794870, dev=\\?\usb#vid_16c0&pid_0483#5794870#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
    17:01:44.239 (ports 5):   comport_from_devinst_list attempt
    17:01:44.239 (ports 5):   found Ports in classguid_list at index=0
    17:01:44.239 (ports 5):   port COM25 found from devnode
    17:01:44.239 (ports 5): found_usb_device complete
    17:01:44.241 (ports 5): usb_add: usb:0/140000/0/8/7  COM25 (Teensy 4-Beta2) Serial
    17:01:44.271 (ports 5): WM_DEVICECHANGE DBT_DEVICEARRIVAL
    17:01:44.272 (ports 5): nothing new, skipping HID & Ports enum
    17:01:44.463 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    17:01:44.464 (ports 5): nothing new, skipping HID & Ports enum
    17:01:45.771 (ports 5): callback C115

    These '17:01:45.771 (ports 5): callback C115' in verbose really clutter and make TLoader Verbose hard to use.

    For the above here is TyComm's untime stamped notes on USB Event:
    Code:
    Examining device node 'USB\VID_16C0&PID_0483\5794870'
    Found port number of 'USB\VID_16C0&PID_0483\5794870': 7
    Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
    Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
    Add serial device 'USB\VID_16C0&PID_0483\5794870' on iface 0
      - USB VID/PID = 16c0:0483, USB location = usb-1-8-7
      - USB manufacturer = Teensyduino, product = USB Serial, S/N = 5794870
    Unknown Teensy model with bcdDevice value 0x279
    Received arrival notification for device 'USB\VID_16C0&PID_0483\5794870'
    Examining device node 'USB\VID_16C0&PID_0483\5794870'
    Found port number of 'USB\VID_16C0&PID_0483\5794870': 7
    Found port number of 'USB\VID_1A40&PID_0201\5&38BA1A52&0&8': 8
    Found controller ID for 'USB\ROOT_HUB30\4&362721B3&0&0': 1
    Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    [send@5794870-Teensy] I/O error while writing to '\\.\COM25'
    Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received removal notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Received arrival notification for device 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Examining device node 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Unknown device type for 'SWD\DAFUPNPPROVIDER\UUID:6242E31B-9813-9616-FFFF-FFFFAC5FEE5E'
    Pushed Button and code reloaded and TyComm picked up running like this - no "status ="
    Code:
    usb_cdc_line_coding, baud=115200
    run_callbacks
    rx event, len=6, i=0
    
    ***********IMXRT Startup**********
    test 1 -1234567 3
    CCM_ANALOG_PLL_USB1=80003000
      enable USB clocks
    CCM_ANALOG_PLL_USB1=80003040
    Increasing voltage to 1250 mV
    need to switch to alternate clock during reconfigure of ARM PLL
    USB PLL is running, so we can use 120 MHz
    Freq: 12 MHz * 100 / 2 / 1
    ARM PLL=80002042
    ARM PLL needs reconfigure
    ARM PLL=80002064
    New Frequency: ARM=600000000, IPG=150000000
    USB reset took 3 loops
    analogInit
    usb_serial_reset
    usb_serial_configure
    usb_cdc_line_coding, baud=0
    before C++ constructors
    after C++ constructors
    before setup
       millis=340
    usb_cdc_line_coding, baud=0
    usb_cdc_line_coding, baud=115200
    usb_cdc_line_coding, baud=115200
    after setup
     Loop Hz 12491217
    Last edited by defragster; 04-29-2019 at 12:58 AM.

  14. #2564
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,173
    Quote Originally Posted by defragster View Post
    @Paul: are there any 'status =' values that worry you that we shouldn't ignore?
    Good question. I really don't have a conclusive answer at this time. But I can tell you I'm working on the USB stuff now.

    One thing is absolutely clear: there just aren't clear answers yet. NXP's documentation had the wrong definition for USBCMD ATDTW until the latest rev (and appears to have been wrong for ~5 years on prior chips), and version 2.5.0 of their SDK has it defined according to the wrong docs. I also have some serious doubts about the "case 2" process on page 2468 of the latest manual and seems to be followed by NXP's code, documenting how to use ATDTW. The semaphore is only used to guard access to the ENDPTSTAT, not the earlier write to the transfer descriptor. What happens if the EHCI fetches the next TD between steps 1-3?

    Another big unknown is whether polling the QH or TD structures can work at all. All the docs and examples are based on keeping a separate linked list, requiring one interrupt per TD to maintain linked lists separate from the EHCI structs. I'm hoping to avoid all that extra overhead for transmitting.

    So how exactly the interpret those status bits is still not 100% clear to me. As you can see in the early code, I had to use some pretty kludgey delays.

  15. #2565
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Let me know - turning them off could miss something … I suppose I'll bring them back if they can help - and move user debug to Serial and Serial1 like before with another Teensy - and then just understand T4 won't cold start with them active.

    Also if you see anything in the post #2563 that helps get to whatever halted …

    I'll leave that code and add in encoders ...

  16. #2566
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Paul - you noted you are working on USB - anything specific to test that would help find or resolve concerns?

    The TRIO stopped again once - my hand was near the breakout Serial wires ... nothing interesting on the Sermon(s). I've been hearing the Windows USB OUT chime at times when my computer has sound on - but never clear what changed. Serial4 on T_3.1 with status back on.

    TyComm can do a Send File - I have a 900KB TLoader verbose.log from above. Works sending in and out T4 USB - through T_3.5 on Serial2 … so Serial2 @ 2Mbps working too.

    > Can send that with USB out Serial1 debug @2Mbps T_3.5 to T4 Serial2 @2Mbps out USB with T4 - and it works with readBytes() - was lossy with read().
    Code:
      if ( Serial2.available() ) {
        char rdBuff[1025];
        int ii;
        while ( ii = Serial2.available() ) {
          if ( ii > 1024 )ii = 1024;
          Serial2.readBytes( rdBuff, ii);
          rdBuff[ii] = 0;
          Serial.print( rdBuff );
        }
      }
    > Can send that with USB out Serial2 debug @2Mbps T4 to T_3.5 that then send out USB from T_3.5 - and it works with read()
    Code:
      if ( Serial.available() ) {
        while ( Serial.available() ) {
          HW_SERIAL.print( (char)Serial.read() );
        }
      }
    Added Encoder code from @mjs513 - and put Bounce on the button and that works.

  17. #2567
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,173
    Quote Originally Posted by defragster View Post
    anything specific to test that would help find or resolve concerns?
    Yeah, but hard to say exactly what to test or how.

    Long ago, there was a thread about sending a huge amount of pseudo-random data in both directions and verifying a checksum after several megabytes. Any maybe measuring the speed along the way. Was going to try to recreate that. If anyone wants to give it a try, please jump in and write a little code on both sides. Otherwise, I'll probably do it in a day or two....

  18. #2568
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    @KurtE did some good tests of data integrity for Serial#. Quick search didn't find note on pseudorandom.

    I walked away and returned - I want to say I touched nothing - Win USB Chime away - TyCommander shows three Teeny Running Teensy : T4, T_3.1 on Serial4 debug @115Kb, T_3.5 on Serial2 @2Mb for sketch debug/output.

    Send from TyComm Sermon to T4 ignored.

    I hooked into the Encoder interrupt as presented by @mjs513 to toggle a pin tied to T_3.5 and rotating the knob still isr() still triggering and seen by the T_3.5, but all else stalled and appears frozen. Encoder and encoder button click report in loop() and they are silent link the 1 second LED toggle and loop() Hz.

    Paul: Is there anything I could do in that interrupt to ping the USB system? I'll see if PJRC debug Serial4 output works from there.


    T4 is spewing the last line - caught the buffer spot where that started - the 90080 is overwhelming the output as printing:
    Code:
    status = 00090080
    status = 00090080
    status = 00090080
    status = 00090080
    status =usb_cdc_line_coding, baud=0
     00090080
    status = 00090080
    status = 00090080
    status = 00090080
    status = 00090usb_cdc_line_coding, baud=115200
    080
    status = 00090080
    status = 00090080
    status = 00090080
    status = 00090080
    statuusb_cdc_line_coding, baud=115200
    s = 00090080
    status = 00090080
    status = 00090080
    status = 00090080
    status = 00090080
    <edit>Will this safely reduce the "status =" spew rate?
    Code:
    		if (count > 10) {
    			printf("status = %x\n", status);
    			count = 0;
    		}
    Here is a save of the TeensyLoader Verbose at that point 780KB then zipped:: Only new entries since the save is this unpromted:
    00:44:09.213 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    00:44:09.214 (ports 5): nothing new, skipping HID & Ports enum
    00:44:09.306 (ports 5): callback C115
    00:44:09.650 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    00:44:09.651 (ports 5): nothing new, skipping HID & Ports enum
    00:44:09.670 (ports 5): WM_DEVICECHANGE DBT_DEVNODES_CHANGED
    00:44:09.671 (ports 5): nothing new, skipping HID & Ports enum
    00:44:11.325 (ports 5): callback C115
    00:44:13.348 (ports 5): callback C115
    00:44:15.379 (ports 5): callback C115
    00:44:17.402 (ports 5): callback C115

  19. #2569
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    I walked up the hall and back in my dry house - wearing a cashmere sweater, did not pet the cat - came to computer and waved my hand over the Teensy on my monitor stand and :: status = 001E0080

    That is all that is printing - repeatedly - at an extreme rate. I repeated this twice more with no effect.

    Other loop() activity stopped - encoder pin interrupt still working to toggle the bit to debug T_3.5, and now sending this out Serial4 to T_3.1 :: printf_debug( "\n~~\n" );

    I am seeing spurious output from the encoder interrupt firing?

    I did this to compress the "status =" messages:
    Code:
    	int count=0;
    	static int ccnt = 0;
    	//digitalWriteFast(13, HIGH);
    	while (1) {
    		uint32_t status = txtransfer.status;
    		if (count > 10) {
    			ccnt++;
    			if ( 0x00070080 == status )
    				printf("7*");
    			else if ( 0x00090080 == status )
    				printf("9*");
    			else if ( 0x001E0080 == status )
    				printf("1E*");
    			else if ( 0x00010080 == status )
    				printf("1*");
    			else if ( 0 == status )
    				printf("0*");
    			else  {
    				printf("\nstatus = %x\t", status);
    				ccnt=0;
    			}
    			if (ccnt > 32) {
    				printf("\nst=");
    				ccnt=0;
    			}
    		}
    Results look like this:
    status = 00030080 0*0*after setup
    7*7*0*7*0*7*7*0*7*7*0*7*7*0*7*7*0*7*7*0*7*7*0*0*7* 7*0*7*7*0*7*
    st=0*7*7*0*7*7*0*7*7*0*7*7*0*7*7*7*0*7*7*0*7*7*0*
    status = 000F0080 0*
    status = 00010080 0*0*
    status = 000F0080 0*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7*0*7*7*7* 0*7*7*7*0*7*7*7*
    st=0*7*7*7*7*0*7*7*7*7*0*7*7*0*7*7*0*7*7*7*7*0*7*7 *7*7*0*7*7*7*0*7*7*
    st=0*7*7*0*7*7*7*7*0*7*7*7*7*0*7*7*7*7*0*7*7*7*0*
    status = 000F0080 0*
    status = 000F0080 0*0*7*7*7*7*0*7*7*7*7*0*7*7*7*7*0*
    ~~ // Here is the untouched encoder indication - funny because it didn't have same associated status
    9*9*9*0*9*9*0*7*7*0*7*7*0*7*7*7*
    <edit> Adding this - no signs of errors or issues:
    Sending encoder message 'on purpose' made a lot of noise too so I added 1*:
    ~~
    1*1*0*1*0*1*1*
    st=0*1*0*9*0*1*1*0*1*1*1*0*1*0*1*1*1*0*0*9*0*9*0*1 *1*1*0*1*0*1*1*0*1*
    st=0*0*9*0*1*1*0*1*0*9*0*1*1*1*0*0*1*1*1*0*1*0*9*9 *0*1*0*1*1*1*0*1*0*
    st=9*0*9*0*0*1*0*1*1*0*1*0*9*0*0*1*1*1*0*1*0*9*0*9 *0*1*1*0*1*0*1*1*0*
    st=1*1*0*0*1*1*0*1*0*9*0*9*0*1*1*0*1*0*1*1*0*1*0*1 *1*1*0*0*0*9*0*1*1*
    st=0*1*0*0*1*0*1*1*1*0*1*0*9*0*9*0*0*1*0*7*7*0*
    ~~
    9*0*1*1*0*1*1*0*1*1*0*
    st=1*0*1*0*1*1*0*0*0*9*0*9*9*0*9*9*0*0*1*0*1*0*1*0 *1*0*0*1*0*0*1*1*1*
    st=0*1*0*9*9*0*

  20. #2570
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,173
    Quote Originally Posted by defragster View Post
    T4 is spewing the last line - caught the buffer spot where that started - the 90080 is overwhelming the output as printing:
    I'm working on the transfer descriptor status problems now. Turns out USBCMD ATDTW is looking like the proper answer. Those delays I put in the code don't always work, and even when they do they're a pretty terrible kludge.

    NXP's rather scant documentation about ATDTW isn't very helpful. I'm pretty sure whoever wrote "41.5.6.6.3 Executing A Transfer Descriptor" on page 2468 (RT1060 ref manual, rev 1, 12/2018) had absolutely no idea how ATDTW really works, so they just documented what's in the SDK code. I have serious doubts that code is really correct, but probably works out due to the timing of how the USB controller generates interrupts and the ARM core responds.

    On the next page, "41.5.6.6.4 Transfer Completion" makes absolutely no mention of ATDTW. It says "or alternately, the DCD can poll the endpoint complete register to find when the dTD had been executed". That's exactly what the code does now. Indeed we are getting wrong info in some cases. The "spew" also is correct behavior in other cases. USB is complicated....

    In my dream world, I'd be able to connect a very high speed logic analyzer to the ATDTW signal deep inside the chip, and also watch the 600 MHz bus - or at least some signals about bus arbitration to get an idea when the USB controller is reading & writing the QH and TD structs. But sadly, the only way to learn is writing little functions that capture simple stats while working with the registers, and then print the info after the fact. This stuff all happens on very short time scales, only a few iterations of a loop which does a few register reads is able to run before it's all over. Pretty hard to see what's really going on.

    My best guesswork on ATDTW is the USB controller forces it low during certain operations that access the TD and maybe also the QH struct. During that time, which appears to be only about 10 to 50 ns, you can't change it. Writes seem to be ignored, so it stays low for the duration of some internal operation. After the operation is over, ATDTW becomes writable again. So far, I've never observed a case where it was low and then when I was able to set it high, the TD still had its active bit set. Not sure if that means it's only low when the TD is written back? I've only been testing with small transfers which requires a single USB packet. Might try some longer tests later and see if I can craft code that observes the QH update, and see if ATDTW low correlates with those moments or only when the TD is written with the final result.

    I took out the delays and rearranged stuff to make the TD status read problems *much* worse. I can usually get it to go very wrong only milliseconds after USB enumeration completes. I started using ATDTW to retry reading the TD status (not the ENDPTSTATUS register as documented on page 2468) and it does indeed seem to fix the problem. I've had that code which crashes within milliseconds after enumeration running successfully for a couple hours and still going. Going to commit that (and the process from page 2468 - though I'm deeply suspicious it's not fully correct) to github now.

  21. #2571
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,173
    Ok, I've committed the code. This is still very much a work in progress... and trying to reverse engineer how to really use ATDTW....

    https://github.com/PaulStoffregen/co...81959acf863f95

    Just to be clear, you absolutely should expect to see "spew" like this on Serial4 in two cases.

    status = 0###0080
    status = 0###0080
    status = 0###0080

    Where "###" varies depending on how much data Teensy wants to send to your PC, but can't. There are 2 valid reasons why this could happen:

    1: If you close (or never open) the Arduino Serial Monitor, then no driver on your PC is sending USB IN tokens which allow Teensy to transmit data. In that case, you should see this message print as rapidly as the Serial4 baud rate allows. There is currently no timeout built into usb_serial_write(), which means your Arduino sketch will hang forever in Serial.print() - or at least "forever" until your PC starts sending USB IN tokens.

    2: If Teensy sends data faster than your PC can accept it, the driver on your PC will cause your motherboard's USB controller to stop sending IN tokens, until it has buffers available to accept Teensy's data. This is normal and correct flow control which is fundamentally built into the USB protocol. When you see this happen, each PC-not-ready event should have 1 or more "status = 0###0080" messages and 1 "status = 00000000", meaning your PC became ready for more data.

    Something that should definitely *NOT* happen is Teensy failing to print to the serial monitor while it's still open, and a never-ending stream of "status = 0###0080" (or any other message) on Serial4 when data should be flowing.

    Just remember, when your PC isn't listening or isn't able to handle the incoming speed, you *ARE* supposed to see those status messages "spew" to Serial4. That is absolutely normal and correct if your PC isn't ready to receive.

    Eventually I will put a timeout into usb_serial_write(), as we have on all other Teensy models, so printing won't stall your program if the PC isn't listening. But that code tends to mask these sorts of problems, so I'm not putting the timeout into the code until I'm sure this status stuff really is working.

  22. #2572
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Downloading and will start it up on my busy sketch to run the next few hours. Then I'll come back and finish reading the above like it makes perfect sense.

    I do expect spew - just trying to minimize the impact of stuff getting buried in screen after screen and putting filler between the events or hiding patterns.

  23. #2573
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    My sketch up and running - way less debug spew - basically none unless as noted [#1] drop the Serial connect on Sermon {tycomm} and try to Serial.print. Turning the encoder knob gets an intermittent couple on occasion, but that is on isr() out debug serial while other code is doing its thing.
    ~~
    ~~
    status = 00010080
    status = 00000000
    ~~
    status = 00010080
    status = 00000000
    ~~
    ~~
    status = 00010080
    status = 00000000
    status = 00010080
    status = 00000000
    ~~
    ~~
    I've got a feeling the only breaks I caught were from static charge or such proximity to my wire loops with 3 Teensy connected by Rx/Tx/Gnd and the 5 added encoder wires to breadboard. Very odd though 'only' loop seemed to be stopped.

    Did a quick search of ATDTW so I'd at least know the words behind the TLA - found the Dec 2018 NXP.forum post where recent 5 years of manuals [and SDK's] declared it as bit 12 when it is and always has been - as prior manuals declared at bit 14 … not nice. I then saw you were using #14.

    Yes 12Mbps or pushing to 400 doesn't happen slowly or leave much time for poking around … I hear sipping from a firehose is similarly problematic.

    Using TyComm to send that 900kb file over USB to T4 works - in 10-11 seconds - though I only visually see it looking right. And pushing it to T_3.5 to send over Serial2 @2Mbps for resend out T4 USB also 'looks' decent - and causes no notes on writing and only a stream of these on reading:
    run_callbacks
    rx event, len=512, i=0
    run_callbacks
    rx event, len=512, i=0

  24. #2574
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,827
    Paul - I just did a 15s Restore on my T4-2 as I found I had Win SDK USBview.exe installed.

    Hopefully this will show you some fixable difference. CodeCompare shows the names confused: Click image for larger version. 

Name:	usbViewNames.jpg 
Views:	12 
Size:	103.5 KB 
ID:	16506

    Highlighted some of the DIFFS...

    After the Restore this is what it tells me about the T4-2:
    Code:
    [Port6]  :  USB Composite Device
    
    
    Is Port User Connectable:         yes
    Is Port Debug Capable:            no
    Companion Port Number:            0
    Companion Hub Symbolic Link Name: 
    Protocols Supported:
     USB 1.1:                         yes
     USB 2.0:                         yes
     USB 3.0:                         no
    
    Device Power State:               PowerDeviceD3
    
           ---===>Device Information<===---
    English product name: "Teens?????????????"
    
    ConnectionStatus:                  
    Current Config Value:              0x01  -> Device Bus Speed: High (is not SuperSpeed or higher capable)
    Device Address:                    0x32
    Open Pipes:                           4
    
              ===>Device Descriptor<===
    bLength:                           0x12
    bDescriptorType:                   0x01
    bcdUSB:                          0x0110
    bDeviceClass:                      0x00  -> This is an Interface Class Defined Device
    bDeviceSubClass:                   0x00
    bDeviceProtocol:                   0x00
    bMaxPacketSize0:                   0x40 = (64) Bytes
    idVendor:                        0x16C0 = Van Ooijen Technische Informatica
    idProduct:                       0x0486
    bcdDevice:                       0x0279
    iManufacturer:                     0x01
    String Descriptor for index 1 not available while device is in low power state.
    iProduct:                          0x02
         English (United States)  "Teens?????????????"
    iSerialNumber:                     0x03
         English (United States)  "5794870"
    bNumConfigurations:                0x01
    
              ---===>Open Pipes<===---
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x04  -> Direction: OUT - EndpointID: 4
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0020 = 1 transactions per microframe, 0x20 max bytes
    bInterval:                         0x02
    
           ---===>Full Configuration Descriptor<===---
    
              ===>Configuration Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x02
    wTotalLength:                    0x0049  -> Validated
    bNumInterfaces:                    0x02
    bConfigurationValue:               0x01
    iConfiguration:                    0x00
    bmAttributes:                      0xC0  -> Self Powered
    MaxPower:                          0x32 = 100 mA
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x00
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x02
    bInterfaceClass:                   0x03  -> HID Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>HID Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x21
    bcdHID:                          0x0111
    bCountryCode:                      0x00
    bNumDescriptors:                   0x01
    bDescriptorType:                   0x22 (Report Descriptor)
    wDescriptorLength:               0x001C
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x04  -> Direction: OUT - EndpointID: 4
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x01
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x02
    bInterfaceClass:                   0x03  -> HID Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>HID Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x21
    bcdHID:                          0x0111
    bCountryCode:                      0x00
    bNumDescriptors:                   0x01
    bDescriptorType:                   0x22 (Report Descriptor)
    wDescriptorLength:               0x0021
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0020 = 1 transactions per microframe, 0x20 max bytes
    bInterval:                         0x02
    When TeensyLoader uploads the provided minimal.hex is then shows this:
    Code:
    [Port6]  :  USB Composite Device
    
    
    Is Port User Connectable:         yes
    Is Port Debug Capable:            no
    Companion Port Number:            0
    Companion Hub Symbolic Link Name: 
    Protocols Supported:
     USB 1.1:                         yes
     USB 2.0:                         yes
     USB 3.0:                         no
    
    Device Power State:               PowerDeviceD0
    
           ---===>Device Information<===---
    English product name: "Teensyduino RawHID"
    
    ConnectionStatus:                  
    Current Config Value:              0x01  -> Device Bus Speed: High (is not SuperSpeed or higher capable)
    Device Address:                    0x38
    Open Pipes:                           4
    
              ===>Device Descriptor<===
    bLength:                           0x12
    bDescriptorType:                   0x01
    bcdUSB:                          0x0110
    bDeviceClass:                      0x00  -> This is an Interface Class Defined Device
    bDeviceSubClass:                   0x00
    bDeviceProtocol:                   0x00
    bMaxPacketSize0:                   0x40 = (64) Bytes
    idVendor:                        0x16C0 = Van Ooijen Technische Informatica
    idProduct:                       0x0486
    bcdDevice:                       0x0279
    iManufacturer:                     0x01
         English (United States)  "Teensyduino"
    iProduct:                          0x02
         English (United States)  "Teensyduino RawHID"
    iSerialNumber:                     0x03
         English (United States)  "5794870"
    bNumConfigurations:                0x01
    
              ---===>Open Pipes<===---
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x04  -> Direction: OUT - EndpointID: 4
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0020 = 1 transactions per microframe, 0x20 max bytes
    bInterval:                         0x02
    
           ---===>Full Configuration Descriptor<===---
    
              ===>Configuration Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x02
    wTotalLength:                    0x0049  -> Validated
    bNumInterfaces:                    0x02
    bConfigurationValue:               0x01
    iConfiguration:                    0x00
    bmAttributes:                      0xC0  -> Self Powered
    MaxPower:                          0x32 = 100 mA
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x00
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x02
    bInterfaceClass:                   0x03  -> HID Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>HID Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x21
    bcdHID:                          0x0111
    bCountryCode:                      0x00
    bNumDescriptors:                   0x01
    bDescriptorType:                   0x22 (Report Descriptor)
    wDescriptorLength:               0x001C
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x83  -> Direction: IN - EndpointID: 3
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x04  -> Direction: OUT - EndpointID: 4
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Interface Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x04
    bInterfaceNumber:                  0x01
    bAlternateSetting:                 0x00
    bNumEndpoints:                     0x02
    bInterfaceClass:                   0x03  -> HID Interface Class
    bInterfaceSubClass:                0x00
    bInterfaceProtocol:                0x00
    iInterface:                        0x00
    
              ===>HID Descriptor<===
    bLength:                           0x09
    bDescriptorType:                   0x21
    bcdHID:                          0x0111
    bCountryCode:                      0x00
    bNumDescriptors:                   0x01
    bDescriptorType:                   0x22 (Report Descriptor)
    wDescriptorLength:               0x0021
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x81  -> Direction: IN - EndpointID: 1
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0040 = 1 transactions per microframe, 0x40 max bytes
    bInterval:                         0x01
    
              ===>Endpoint Descriptor<===
    bLength:                           0x07
    bDescriptorType:                   0x05
    bEndpointAddress:                  0x02  -> Direction: OUT - EndpointID: 2
    bmAttributes:                      0x03  -> Interrupt Transfer Type
    wMaxPacketSize:                  0x0020 = 1 transactions per microframe, 0x20 max bytes
    bInterval:                         0x02

  25. #2575
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,173
    Quote Originally Posted by defragster View Post
    Yes 12Mbps or pushing to 400 doesn't happen slowly or leave much time for poking around
    I started doing some benchmarking. There's no optimization at all so far. The USB Serial.print() throughput is dismal, about 1/3rd the speed of Teensy 3.6. I tested several boards and was quite surprised how very slow Arduino's products are with native USB, especially Arduino Zero and MKR1000. Arduino Due is the only one with decent performance, just slightly faster than T4 is at this moment.

    Going to start working on optimizations next...

Posting Permissions

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