Teensyduino 1.56 Beta #1

Status
Not open for further replies.
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:
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.

capture.png

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.
 
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.
 
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.


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.
 
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!
 
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:
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?
 
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.
 
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.

capture.png
 
Last edited:
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??
 
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)
2021-09-28 17_41_36-Window.png
And wow, it skips "a few" lines :
Code:
count=10000776, lines/se0
count=10015316, lines/sec=0
 
Last edited:
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.
tsermon_Avail.jpg

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:
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;
 
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.
 
@Paul - are there no serialEvent() calls for USB1 and USB2? Should/Could there be?

I have seen garbage text using provided 'available' code:
tsermonGarb.png

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];
[B]void serialEvent() {[/B]
  logEvent( 1 );
}
[B]void serialEventUSB1() {[/B]
  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:
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
 
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
[B]count=197511389, lines/sec=34899	Send sec =1699.98
[/B]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
[B]count=197511389, lines/sec=34899	Send sec =1708.77  // 
[/B]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
[B]count=197540133, lines/sec=1	Send sec =1726.01[/B]  // 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:
[B]count=274982041, lines/sec=107636	Send sec =3159.97[/B]
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:
I found a fix for the rare stall, where sending any data causes reception to restart.
 

Attachments

  • teensy_serialmon.zip
    22.4 KB · Views: 77
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
 
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();
  }
}
 
Status
Not open for further replies.
Back
Top