Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 12 FirstFirst 1 2 3 4 5 ... LastLast
Results 51 to 75 of 282

Thread: Teensyduino 1.56 Beta #1

  1. #51
    Member
    Join Date
    Sep 2021
    Posts
    70
    I'd say longer tests just show memory problems.
    I bet there is no code that says "If running more than 5 Seconds, call bug()"

    And to have the same prerequisites you have to clear the buffers (in any program) Otherwise you're comparing apples and oranges as they use buffers with different sizes.
    H-term workd every single time for me - but I cleared its buffer and restarted it from time to time.
    Anyhow, again, this test is pointless. But it showed that the teensy monitors' scrollback is way too small. And they all work without garbage if the teensy part respects availableForWrite().
    Last edited by Mcu32; 09-28-2021 at 09:26 AM.

  2. #52
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Quote Originally Posted by Mcu32 View Post
    It is remarkable that H-Term does not log or output random characters.
    That is indeed remarkable, as Coolterm and others do it.

    I downloaded Hterm, but it wants various DLLs my Windows test system doesn't have.

    Click image for larger version. 

Name:	capture.png 
Views:	7 
Size:	16.0 KB 
ID:	26004

    Please keep in mind I'm not a Windows user (I primarily use Linux and occasionally MacOS for video stuff) - my Windows test system has only Arduino and Teensyduino and Coolterm installed. I don't actually use the computer for anything other that testing the Windows version of Teensyduino, so a lot of the software that's commonly installed on well-used Windows systems isn't here.


    The problem of missing lines also seems to occur in H-Term only after a certain amount.
    Yes, with Java-based serial monitor and Coolterm and others, the problems only occur after a huge amount of data has been transferred at sustained high speed.

  3. #53
    Member
    Join Date
    Sep 2021
    Posts
    70
    The output to screen is slow in h-term. But logging to file seems to be very good.
    Maybe Defragster can send you the missing DLLs. For me, it worked out of the box.

  4. #54
    Member
    Join Date
    Sep 2021
    Posts
    70
    Quote Originally Posted by Mcu32 View Post
    The output to screen is slow in h-term. But logging to file seems to be very good.
    Maybe Defragster can send you the missing DLLs. For me, it worked out of the box.
    From the FAQ:
    [quote]
    Startup error on Windows that VCRUNTIME140_1.dll was not found
    Go to Microsoft, download and install vc_redist.x64.exe for Visual Studio 2015, 2017 und 2019
    [/code]

    https://aka.ms/vs/16/release/vc_redist.x64.exe

  5. #55
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    I got Hterm to run after installing VC_redist.x64.exe downloaded from this Microsoft page.

    But then it gave me the same problems Defragster saw.


    Quote Originally Posted by defragster View Post
    But when connected to a T_4.1 running the lines/sec demo ... it never counts or shows a single output byte ... Just the Hour Glass ... then spontaneously closed sometime in about a minute.

    Started again a second time and hour glass and NO data display repeated ... it was unresponsive but didn't terminate until I hit Close.
    I had Teensy 4.1 already running usb_serial_print_speed.ino. Hterm just became unresponsive as soon as I clicked Connect.

  6. #56
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Quote Originally Posted by Mcu32 View Post
    The output to screen is slow in h-term. But logging to file seems to be very good.
    Did you test with Teensy 4.0 or 4.1 running usb_serial_print_speed.ino ?

    Which program you run on Teensy matters. If you run a test like the one Frank showed in msg #38 on this thread, you'll probably see everything work fine.

  7. #57
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    I ran the code from msg #46 (after fixing the missing braces on the for loop) and indeed it works fine. I'm getting the impression you've done all your testing with that program and ignored the fact that usb_serial_print_speed.ino is the program Defragster and I are running.

    Again, you NEED TO RUN usb_serial_print_speed.ino (or something similar) if you want to see the garbage output problem.

    Your program on msg #46 prints only 1 million relatively short lines. That's nowhere near enough to reproduce the problem!

  8. #58
    Member
    Join Date
    Sep 2021
    Posts
    70
    Sorry for the missing braces, had a wrong copy in the clipboard.
    Indeed, the short variant works fine in h-term
    The later posted variants print 10 million lines. Is too less, too? At this size h-term start to fail too and there a some lines missing. I wrote that.
    Then I added the availableForWrite(). I wrote that.
    Then I tested TY and the both Arduino monitors. With that program. I wrote that too. _All_ work with availableForWrite (well - can't say this for teensy monitor as it does not show enough lines - the original does.)

    I said, these test - obviously - show more the performance on the PC side, and I said I don't know what this is good for. The times are very different, for any of the programs.
    I can test your program, too. I'm pretty sure it has the same problem without availableForWrite. The only difference is, that it runs in loop() and has even more additional code than the one I tried. The other difference is, that I use printf.
    Maybe the printf slows it down enough?
    Instead of showing anti-attitude you could at least try to read and to consider the additional information I have given. And that the original monitor works too (with respect of the known problems I mentioned) - with availableForWrite even better than your version. For me. On my PC.

    If 10 million lines is not enough - ok, i can test with more.

    I think we're talking about different topics. I just say, it's a PC (Or Windows, or software) problem. I showed that hterm seems to be different and does it a bit better, maybe because it can log faster.
    I know your test should print as fast as possible. But if the the receiving side is the bottleneck, this leads to nothing and the printed numbers says nothing.
    availableForWrite will slow it down. Yes, I know that. That's not the point. My point was, that everythings works reliable with availableForWrite (or any other delay). No Garbage (with 10MB test)
    Last edited by Mcu32; 09-28-2021 at 11:10 AM.

  9. #59
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Quote Originally Posted by Mcu32 View Post
    If 10 million lines is not enough - ok, i can test with more.
    Is it too much to ask for you run usb_serial_print_speed.ino?

  10. #60
    Member
    Join Date
    Sep 2021
    Posts
    70
    Will do it.

  11. #61
    Member
    Join Date
    Sep 2021
    Posts
    70
    Your monitor shows garbage, the original gets stopped and the whole task deleted (by windows?), hterm shows a hourglass and gets stopped after a while, too.
    And now?

  12. #62
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Quote Originally Posted by Mcu32 View Post
    My point was, that everythings works reliable with availableForWrite (or any other delay). No Garbage (with 10MB test)
    I'm testing with an availableForWrite() check added to usb_serial_print_speed.ino. Also been playing with edits inside usb_serial_write() to disable the check for unresponsive USB host.

    I did see garbage in Coolterm (which only manages several thousand lines/sec speed). Haven't seen anything bad fly by in the Arduino serial monitor yet, but it's only been running for maybe 10 minutes so far.

  13. #63
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    Well, I wasn't planning to dive into this until after MTP... but here I am (at least today) several hours into the USB serial issue.

    Indeed checking availableForWrite() or disabling the usb_serial_write() timeout code makes things work much better. But wow, the performance on Windows is horrible. With Teensy 4.1 overclocked at 816 MHz, my Linux desktop consistently sustains about 644K lines/sec. My Macbook Air manages a consistent 632K. The overall speed appears to be CPU limited on the Teensy side, probably by Serial.print(number). Serial.printf() is much slower. Transmitting fixed strings is much faster, but requires other ways of measuring than simply printing the benchmark.

    But Windows varies wildly from high points around 120K-150K lines/sec to frequent slowdowns at half that speed or less, and sometimes stalls where it wasn't able to send anything to the PC for a few seconds! Remember, this is the speed observed from the Teensy side. Windows Task Manager showing pretty consistent 30% CPU usage and no unusual amount of memory used. I don't understand how Windows can perform this badly when so much CPU power is going unused.

    Then after running for 15 min or more, Windows seems to fall into a pattern of short bursts at normal to sometimes even nearly Mac / Linux speed (again, as observed from the Teensy side) with long times of reporting 1 lines/sec. My best guess at this point is we're filling up a huge buffer on the Windows side and then waiting a long time before its gets drained low enough for data transfer to resume.

    My beliefs at this point...

    1: Something is going very wrong on the Teensy side for the unresponsive host timeout case. I had previously thought this to be a Windows bug, but now I'm not sure. It probably is something wrong on the Teensy side that only manifests when talking to Windows. This very likely could be the source of corrupted data. Maybe?

    2: I don't understand how the Windows performance can be so bad, but wow, it's terrible!

    3: Looks like teensy_serialmon might have another stall condition. I've hit it only a few times with hours of high speed printing from usb_serial_print_speed.ino. When it happens, sending any character causes data flow to resume. I'm pretty sure it's getting hung in WIN32 MsgWaitForMultipleObjects(), but why I have no idea yet. It's a very rare problem which only seems to happens after many hundreds of millions of lines.

    FWIW, here is usb_serial_print_speed.ino with availableForWrite added. @Defragster - can you run this and tell me if you see any data corruption?

    Code:
    uint32_t count, prior_count;
    uint32_t prior_msec;
    uint32_t count_per_second;
    
    // Uncomment this for boards where "SerialUSB" needed for native port
    //#define Serial SerialUSB
    
    void setup() {
      Serial.begin(1000000); // edit for highest baud your board can use
      while (!Serial) ;
      count = 10000000; // starting with 8 digits gives consistent chars/line
      prior_count = count;
      count_per_second = 0;
      prior_msec = millis();
    }
    
    void loop() {
      while( Serial.availableForWrite() < 50 ) {}
      Serial.print("count=");
      Serial.print(count);
      Serial.print(", lines/sec=");
      Serial.println(count_per_second);
      count = count + 1;
      uint32_t msec = millis();
      if (msec - prior_msec > 1000) {
        // when 1 second as elapsed, update the lines/sec count
        prior_msec = prior_msec + 1000;
        count_per_second = count - prior_count;
        prior_count = count;
      }
    }
    Edit: here's the sort of performance I'm seeing.

    Click image for larger version. 

Name:	capture.png 
Views:	16 
Size:	117.0 KB 
ID:	26008
    Last edited by PaulStoffregen; 09-28-2021 at 01:52 PM. Reason: add screenshot

  14. #64
    Member
    Join Date
    Sep 2021
    Posts
    70
    Quote Originally Posted by PaulStoffregen View Post
    It probably is something wrong on the Teensy side that only manifests when talking to Windows. This very likely could be the source of corrupted data. Maybe?
    Hm, but the visible data seems to come from the PC memory.

    I wouldn't invest too much time here.
    For your test program, it's probably easiest to limit it to 3 seconds of runtime. 3-second bursts, and then a long pause to give Windows a chance for garbage collection or whatever it thinks to do.
    In 3 seconds, Windows transfers 10 MB. That's not bad at all. Enough for any real world application, I would say.

    As we've seen, the displayed speed (under Windows) is too dependent on the PC software to provide meaningful numbers.


    Is it the same with rawHID??

  15. #65
    Member
    Join Date
    Sep 2021
    Posts
    70
    I have some messages in the windows error log: "RADAR_PRE_LEAK_64"

    Info from here says:
    RADAR_PRE_LEAK_64 simply means the OS has detected a resource intensive process running which isn't managing its memory very well (it isn't a memory leak, it is "pre-leak", meaning the OS' RADAR function thinks this could become a memory leak. The code you get with it, usually 0xc0000005, is simply a STATUS_ACCESS_VIOLATION, meaning the process tried to access memory it doesn't have (assuming it's a standard Windows HRESULT).


    The windows port of Putty shows this (with garbage)
    Click image for larger version. 

Name:	2021-09-28 17_41_36-Window.png 
Views:	10 
Size:	16.9 KB 
ID:	26011
    And wow, it skips "a few" lines :
    Code:
    count=10000776, lines/se0
    count=10015316, lines/sec=0
    Last edited by Mcu32; 09-28-2021 at 03:59 PM.

  16. #66
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Quote Originally Posted by PaulStoffregen View Post
    Well, I wasn't planning to dive into this until after MTP... but here I am (at least today) several hours into the USB serial issue.

    Indeed checking availableForWrite() or disabling the usb_serial_write() timeout code makes things work much better. But wow, the performance on Windows is horrible. With Teensy 4.1 overclocked at 816 MHz, my Linux desktop consistently sustains about 644K lines/sec. My Macbook Air manages a consistent 632K. The overall speed appears to be CPU limited on the Teensy side, probably by Serial.print(number). Serial.printf() is much slower. Transmitting fixed strings is much faster, but requires other ways of measuring than simply printing the benchmark.

    But Windows varies wildly from high points around 120K-150K lines/sec to frequent slowdowns at half that speed or less, and sometimes stalls where it wasn't able to send anything to the PC for a few seconds! Remember, this is the speed observed from the Teensy side. Windows Task Manager showing pretty consistent 30% CPU usage and no unusual amount of memory used. I don't understand how Windows can perform this badly when so much CPU power is going unused.

    Then after running for 15 min or more, Windows seems to fall into a pattern of short bursts at normal to sometimes even nearly Mac / Linux speed (again, as observed from the Teensy side) with long times of reporting 1 lines/sec. My best guess at this point is we're filling up a huge buffer on the Windows side and then waiting a long time before its gets drained low enough for data transfer to resume.

    My beliefs at this point...

    1: Something is going very wrong on the Teensy side for the unresponsive host timeout case. I had previously thought this to be a Windows bug, but now I'm not sure. It probably is something wrong on the Teensy side that only manifests when talking to Windows. This very likely could be the source of corrupted data. Maybe?

    2: I don't understand how the Windows performance can be so bad, but wow, it's terrible!

    3: Looks like teensy_serialmon might have another stall condition. I've hit it only a few times with hours of high speed printing from usb_serial_print_speed.ino. When it happens, sending any character causes data flow to resume. I'm pretty sure it's getting hung in WIN32 MsgWaitForMultipleObjects(), but why I have no idea yet. It's a very rare problem which only seems to happens after many hundreds of millions of lines.

    FWIW, here is usb_serial_print_speed.ino with availableForWrite added. @Defragster - can you run this and tell me if you see any data corruption?
    ...
    Edit: here's the sort of performance I'm seeing.
    ...
    Running that code seeing about 75K lps consistently with TyComm {not over 90K} - then some few minutes and 'SPLASH' of a full screen of garbage.

    Moving to teensy_serialmon: Cycles typically between ~(75K to 155K) lps
    > drops to 1 lps on (rare) occasion. Rare under 50M cnts, then more often as it neared/passed 100M
    >> over 100M cnts seeing cycling of 1 lps (for 1-3 sec and pulse to 180K lps)
    >> FIRST STALL at : count=122247991, lines/sec=1 : Recovery? - No :: Until I hit 'Send' { repro again at ~128M cnts }
    > not caught garbage yet
    > see only sub second GUI pauses that are rare

    RE: points
    1: odd that garbage shown on PC often appears as 'PC internal data' - but maybe not always
    2: Terrible indeed! Even when Hterm does amazingly well, it is only short term and not repeatable
    3: First stall above ended when 'Send' was hit

    Somewhere in history back I observed/reported that Send can work to WAKE the Teensy/PC I/O - but only (it seemed) when Teensy had not exhausted/queued ALL USB buffers for output? This was found using .availableForWrite() restriction on the code to not abuse all buffers for send.

    Third Stall at '163M' trying to copy failed as selection not possible - and in trying the window went blank.
    > hitting Send resumed at 165M

    Now pulsing 1 lps to 200+ (highest seen ~250K lps)
    > Stalled at : count=171142869, lines/sec=241346, output Resumed with 'Send'

    This pulsing seems to be a cycle and no garbage yet observed.
    Click image for larger version. 

Name:	tsermon_Avail.jpg 
Views:	6 
Size:	124.9 KB 
ID:	26018

    Note: This is a beta Win 11 machine

    It was sitting at : count=215933094, lines/sec=1
    and 'Send' again allowed it to pick up where it left off with no counting while stuck in the : while( Serial.availableForWrite() < 50 ) {}

    Ran to here and restarted on send:
    count=376697100, lines/sec=154282

    Then again to here - with Send restarting: {still no garbage observed}
    count=411624674, lines/sec=163562
    Last edited by defragster; 09-28-2021 at 07:06 PM.

  17. #67
    Member
    Join Date
    Sep 2021
    Posts
    70
    My understanding is that there should be a ""dmb:::memory" (why is dsb used ?) after each tx_noautoflush = 1; in the code. this is not the case.
    Likewise, certainly before each tx_noautoflush = 0;

  18. #68
    Member
    Join Date
    Sep 2021
    Posts
    70
    Code:
    				if (status & 0x68) {
    					// TODO: what if status has errors???
    					printf("ERROR status = %x, i=%d, ms=%u\n",
    						status, tx_head, systick_millis_count);
    				}
    This fires sometimes.

  19. #69
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    @Paul - are there no serialEvent() calls for USB1 and USB2? Should/Could there be?

    I have seen garbage text using provided 'available' code:
    Click image for larger version. 

Name:	tsermonGarb.png 
Views:	7 
Size:	70.3 KB 
ID:	26024

    Using IDE gets really sluggish, or non-responsive, at times when the t_sermon gets troubled, and fine other times while running.

    Seems running this Killed computer WiFi?

    Added a serialEvent() to go along with the 'Send' used for Recovery.
    > NOTE: serialEvent() won't process during normal running? Unless t_sermon 'Autoscroll' is disabled?

    That is printing this out USB1 Dual Serial:
    Code:
    count=11511291, lines/sec=100304	Send sec =34.72
    lps hits to =50000 = 21
    lps hits to =100000 = 2
    lps hits to =150000 = 10
    lps hits to =200000 = 1
    count=17560114, lines/sec=169981	Send sec =92.48
    lps hits to =50000 = 22
    lps hits to =100000 = 14
    lps hits to =150000 = 54
    lps hits to =200000 = 2
    count=29971802, lines/sec=92719	Send sec =213.53
    lps hits to =50000 = 27
    lps hits to =100000 = 87
    lps hits to =150000 = 90
    lps hits to =200000 = 9
    count=40199546, lines/sec=100233	Send sec =313.58
    lps hits to =50000 = 30
    lps hits to =100000 = 149
    lps hits to =150000 = 110
    lps hits to =200000 = 24
    Just saw Garbage go by and while it was drawing the USB1 port from TyComm output response to USB1 input was delayed until the garbage cleared?
    Code:
    count=56215791, lines/sec=98317	Send sec =477.66
    lps hits to =50000 = 34
    lps hits to =100000 = 237
    lps hits to =150000 = 149
    lps hits to =200000 = 42
    lps hits to =300000 = 1
    count=67669625, lines/sec=176315	Send sec =627.34
    lps hits to =50000 = 118
    lps hits to =100000 = 255
    lps hits to =150000 = 170
    lps hits to =200000 = 74
    lps hits to =250000 = 8
    lps hits to =300000 = 1
    Garbage repeated again with the delayed response during t_sermon garbage display - almost as if at that

    Unless the DUAL Serial interferes with USB ( it allocates its own buffer space ) - this should only prevent overrunning the PC with added code.
    >> Note doing this gives INSTANT values out USB1 that shows the 'display LAG' offset between Teensy USB output and t_sermon display ... over 500,000 counts.

    Code:
    uint32_t count, prior_count;
    uint32_t prior_msec;
    uint32_t count_per_second;
    
    // Uncomment this for boards where "SerialUSB" needed for native port
    //#define Serial SerialUSB
    
    void setup() {
      Serial.begin(1000000); // edit for highest baud your board can use
      while (!Serial) ;
      count = 10000000; // starting with 8 digits gives consistent chars/line
      prior_count = count;
      count_per_second = 0;
      prior_msec = millis();
    }
    
    uint32_t lpsSum[40];
    void serialEvent() {
      logEvent( 1 );
    }
    void serialEventUSB1() {
      while ( SerialUSB1.available() ) SerialUSB1.read();
      logEvent( 2 );
    }
    void logEvent( int uu ) {
      int rr = 0;
      while ( Serial.available() ) {
        rr += Serial.read();
      }
    #if defined(USB_DUAL_SERIAL)
      SerialUSB1.print("count=");
      SerialUSB1.print(count);
      SerialUSB1.print(", lines/sec=");
      SerialUSB1.print(count_per_second);
      SerialUSB1.print("\tSend sec =");
      SerialUSB1.println(millis() / 1000.0);
      if ( rr > 13 || uu > 1 ) {
        for ( int ii = 0; ii < 40; ii++ ) {
          if ( lpsSum[ii] > 0 ) {
            SerialUSB1.print("lps hits to =");
            SerialUSB1.print((1 + ii) * 50000);
            SerialUSB1.print(" = ");
            SerialUSB1.println(lpsSum[ii]);
          }
        }
      }
    #endif
    }
    void loop() {
      while ( Serial.availableForWrite() < 50 ) {
        yield();
      }
      Serial.print("count=");
      Serial.print(count);
      Serial.print(", lines/sec=");
      Serial.println(count_per_second);
      count = count + 1;
      uint32_t msec = millis();
      if (msec - prior_msec > 1000) {
        // when 1 second as elapsed, update the lines/sec count
        prior_msec = prior_msec + 1000;
        count_per_second = count - prior_count;
        lpsSum[ count_per_second / 50000 ]++;
        prior_count = count;
      }
    }
    Last edited by defragster; 09-29-2021 at 02:35 AM. Reason: serialEventUSB1() works well

  20. #70
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    9,576
    I believe they are: serialEventUSB1 and serialEventUSB2

  21. #71
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Quote Originally Posted by KurtE View Post
    I believe they are: serialEventUSB1 and serialEventUSB2
    Thanks Kurt, will update above and see what I see. I searched and failed ...

    <EDIT> - easy fix and it works to hit Send in TyComm USB1 and get stats, will see if that also wakes when it stalls.

    p#69 stopped twice again and restarted with "1, Send" showing stats. Had to toggle the 'Autoscroll' again to let it show ... will see if the events process in yield():
    Code:
    count=297180572, lines/sec=1	Send sec =3392.43
    lps hits to =50000 = 1917
    lps hits to =100000 = 397
    lps hits to =150000 = 307
    lps hits to =200000 = 195
    lps hits to =250000 = 150
    lps hits to =300000 = 124
    lps hits to =350000 = 112
    lps hits to =400000 = 102
    lps hits to =450000 = 87
    count=623033717, lines/sec=1	Send sec =7390.67
    lps hits to =50000 = 5145
    lps hits to =100000 = 398
    lps hits to =150000 = 309
    lps hits to =200000 = 198
    lps hits to =250000 = 156
    lps hits to =300000 = 126
    lps hits to =350000 = 113
    lps hits to =400000 = 105
    lps hits to =450000 = 840

  22. #72
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Not sure if this is going anywhere - but it stalled.

    Two sends from USB1 printed ( thanks to while(){yield()} ) did not wake the stalled USB - it shows dupe info below.

    Then "1,Send" on USB did wake and send to USB1:
    Code:
    count=10664621, lines/sec=109912	Send sec =4.36
    lps hits to =150000 = 1
    lps hits to =200000 = 1
    lps hits to =250000 = 1
    count=12815108, lines/sec=70446	Send sec =21.04
    lps hits to =100000 = 5
    lps hits to =150000 = 7
    lps hits to =200000 = 7
    lps hits to =250000 = 1
    count=21950619, lines/sec=99424	Send sec =167.48
    lps hits to =50000 = 75
    lps hits to =100000 = 17
    lps hits to =150000 = 61
    lps hits to =200000 = 12
    lps hits to =250000 = 1
    count=197511389, lines/sec=34899	Send sec =1699.98
    lps hits to =50000 = 487
    lps hits to =100000 = 276
    lps hits to =150000 = 375
    lps hits to =200000 = 316
    lps hits to =250000 = 87
    lps hits to =300000 = 42
    lps hits to =350000 = 36
    lps hits to =400000 = 27
    lps hits to =450000 = 16
    count=197511389, lines/sec=34899	Send sec =1708.77  // 
    lps hits to =50000 = 487
    lps hits to =100000 = 276
    lps hits to =150000 = 375
    lps hits to =200000 = 316
    lps hits to =250000 = 87
    lps hits to =300000 = 42
    lps hits to =350000 = 36
    lps hits to =400000 = 27
    lps hits to =450000 = 16
    count=197540133, lines/sec=1	Send sec =1726.01  // ran this long before first stall
    lps hits to =50000 = 549
    lps hits to =100000 = 276
    lps hits to =150000 = 375
    lps hits to =200000 = 316
    lps hits to =250000 = 87
    lps hits to =300000 = 43
    lps hits to =350000 = 36
    lps hits to =400000 = 27
    lps hits to =450000 = 16

    Stalled again while typing - same no activation with USB1, though it prints - then '1,send' and USB started running again with another USB2 output only after 'AutoScroll' off:
    Code:
    count=225953562, lines/sec=1	Send sec =2042.85
    lps hits to =50000 = 657
    lps hits to =100000 = 290
    lps hits to =150000 = 390
    lps hits to =200000 = 329
    lps hits to =250000 = 100
    lps hits to =300000 = 59
    lps hits to =350000 = 53
    lps hits to =400000 = 37
    lps hits to =450000 = 29
    count=226768754, lines/sec=242568	Send sec =2055.83
    lps hits to =50000 = 764
    lps hits to =100000 = 290
    lps hits to =150000 = 391
    lps hits to =200000 = 329
    lps hits to =250000 = 101
    lps hits to =300000 = 60
    lps hits to =350000 = 53
    lps hits to =400000 = 37
    lps hits to =450000 = 30
    And again :
    count=241388521, lines/sec=14978 Send sec =2270.47

    Stalled again - Print was stopped here : count=274113643, lines/sec=20519

    USB1 count was at : count=274664024, lines/sec=1 Send sec =3141.59

    So the data buffer seems to be stalling about 550381 counts?

    And '1,send' sent this to USB:
    Code:
    count=274982041, lines/sec=107636	Send sec =3159.97
    lps hits to =50000 = 1722
    lps hits to =100000 = 302
    lps hits to =150000 = 401
    lps hits to =200000 = 340
    lps hits to =250000 = 111
    lps hits to =300000 = 68
    lps hits to =350000 = 62
    lps hits to =400000 = 48
    lps hits to =450000 = 104
    lps hits to =500000 = 1
    count=281960878, lines/sec=1	Send sec =3581.02
    count=342652453, lines/sec=355362	Send sec =4224.79
    lps hits to =50000 = 2354
    lps hits to =100000 = 350
    lps hits to =150000 = 440
    lps hits to =200000 = 377
    lps hits to =250000 = 152
    lps hits to =300000 = 105
    lps hits to =350000 = 104
    lps hits to =400000 = 73
    lps hits to =450000 = 126
    lps hits to =500000 = 1
    Last edited by defragster; 09-29-2021 at 03:43 AM.

  23. #73
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,081
    I found a fix for the rare stall, where sending any data causes reception to restart.
    Attached Files Attached Files

  24. #74
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    Quote Originally Posted by PaulStoffregen View Post
    I found a fix for the rare stall, where sending any data causes reception to restart.
    Started testing with this ... will see if the stalls seen here go away.

    Debug out USB1 doesn't seem to have been enough to restart or interfere with repro when used to get stats and status.

    Just saw (rare) garbage - but not stalled:
    Code:
    671.17==secs last lps calc USB1::	garbage
    count=66390252, lines/sec=1	Send sec =671.82
     >> Call by USB==1 or USB1==2 :: 2
    lps hits to =25000 = 140
    lps hits to =50000 = 10
    lps hits to =75000 = 17
    lps hits to =100000 = 268
    lps hits to =125000 = 113
    lps hits to =150000 = 74
    lps hits to =175000 = 34
    lps hits to =200000 = 13
    lps hits to =225000 = 1
    Just now seeing big lag and holes/Jumps in the print stream ...
    They persisted for more than a few seconds ... buffers clearing from higher speeds? ... then strings of 1 lps ... and back up to speed:
    Code:
    806.09==secs last lps calc USB1::	stall completed
    count=70645768, lines/sec=1	Send sec =806.58
     >> Call by USB==1 or USB1==2 :: 2
    lps hits to =25000 = 244
    lps hits to =50000 = 15
    lps hits to =75000 = 17
    lps hits to =100000 = 273
    lps hits to =125000 = 114
    lps hits to =150000 = 79
    lps hits to =175000 = 41
    lps hits to =200000 = 18
    lps hits to =225000 = 4
    864.57==secs last lps calc USB1::	back up to speed - now toggling 1 lps but fast
    count=77038196, lines/sec=1	Send sec =866.02
     >> Call by USB==1 or USB1==2 :: 2
    lps hits to =25000 = 259
    lps hits to =50000 = 18
    lps hits to =75000 = 21
    lps hits to =100000 = 279
    lps hits to =125000 = 117
    lps hits to =150000 = 81
    lps hits to =175000 = 51
    lps hits to =200000 = 25
    lps hits to =225000 = 13

  25. #75
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,096
    57 minutes and still running with p#73 EXE:
    Code:
    3470.51==secs last lps calc USB1::	Status update
    count=356195990, lines/sec=2046	Send sec =3473.26
     >> Call by USB==1 or USB1==2 :: 2
    lps hits to =25000 = 1489
    lps hits to =50000 = 115
    lps hits to =75000 = 131
    lps hits to =100000 = 374
    lps hits to =125000 = 197
    lps hits to =150000 = 182
    lps hits to =175000 = 169
    lps hits to =200000 = 156
    lps hits to =225000 = 125
    lps hits to =250000 = 63
    lps hits to =275000 = 77
    lps hits to =300000 = 83
    lps hits to =325000 = 95
    lps hits to =350000 = 55
    lps hits to =375000 = 41
    lps hits to =400000 = 89
    lps hits to =425000 = 27
    lps hits to =450000 = 2
    Running this variant code DUAL SERIAL to kickstart if it stalls and get stats:
    Code:
    uint32_t count, prior_count;
    uint32_t prior_msec;
    uint32_t count_per_second;
    
    // Uncomment this for boards where "SerialUSB" needed for native port
    //#define Serial SerialUSB
    
    void setup() {
      Serial.begin(1000000); // edit for highest baud your board can use
      while (!Serial) ;
      count = 10000000; // starting with 8 digits gives consistent chars/line
      prior_count = count;
      count_per_second = 0;
      prior_msec = millis();
    }
    
    uint32_t lpsSum[80];
    void serialEvent() {
      logEvent( 1 );
    }
    uint32_t lastMSec = 0;
    uint32_t dualTrigger = 0;
    void serialEventUSB1() {
      SerialUSB1.print(lastMSec / 1000.0 );
      SerialUSB1.print("==secs last lps calc USB1::\t");
      dualTrigger = 1;
      while ( SerialUSB1.available() ) SerialUSB1.print( (char)SerialUSB1.read());
      logEvent( 2 );
    }
    void logEvent( int uu ) {
      int rr = 0;
      while ( Serial.available() ) {
        rr += Serial.read();
      }
    #if defined(USB_DUAL_SERIAL)
      SerialUSB1.print("count=");
      SerialUSB1.print(count);
      SerialUSB1.print(", lines/sec=");
      SerialUSB1.print(count_per_second);
      SerialUSB1.print("\tSend sec =");
      SerialUSB1.println(millis() / 1000.0);
      if ( rr > 13 || uu > 1 ) {
        SerialUSB1.print(" >> Call by USB==1 or USB1==2 :: ");
        SerialUSB1.println(uu);
        for ( int ii = 0; ii < 80; ii++ ) {
          if ( lpsSum[ii] > 0 ) {
            SerialUSB1.print("lps hits to =");
            SerialUSB1.print((1 + ii) * 25000);
            SerialUSB1.print(" = ");
            SerialUSB1.println(lpsSum[ii]);
          }
        }
      }
    #endif
    }
    void loop() {
      while ( Serial.availableForWrite() < 50 ) {
        yield();
      }
      Serial.print("count=");
      Serial.print(count);
      Serial.print(", lines/sec=");
      Serial.println(count_per_second);
      count = count + 1;
      uint32_t msec = millis();
      if (msec - prior_msec > 1000) {
        if ( dualTrigger > 0 ) {
          delay(50);
          dualTrigger = 0;
        }
        // when 1 second as elapsed, update the lines/sec count
        prior_msec = prior_msec + 1000;
        count_per_second = count - prior_count;
        lpsSum[ count_per_second / 25000 ]++;
        prior_count = count;
        lastMSec = millis();
      }
    }

Posting Permissions

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