Teensy 4.0 First Beta Test

Status
Not open for further replies.
I'll look at GetSystemTimePreciseAsFileTime() - I just found that I think it was noted on StackExchange as GetSystemTime() was yelling depreciated !!!!

Though these are overall times here in Seconds for longer test periods. - also the summary times in prior latency test.

The Lines/Sec numbers go LOW and also SURGE HIGH - even in SerMon or TyComm. As noted when you posted it has to be allowed to stabilize - since I was limiting output to assure max throughput I couldn't see when the numbers went to a sane stable value.
 
@KurtE

I got my breakout board up and running today and so far been testing pins with your BlinkAnyPin sketch. Also USBHost is working along with SPI and my ILI9488 shield which runs nicely without have to play with wires :)

Having 1 problem though - it seems when I select pin 30 it high and stays high. Tried it on the official breakout board and same thing - pin 30 stays high if I select it Is there any reason that you can think of?

EDIT: I just checked the pin with just blink running and its reading 2.8v on the osc. Other pins are pretty much ground. If I run blink on pin 30 it just reads High (3.3v)
 
Last edited:
Good news:
I've ported the very complex TeensyConvolutionSdr to Teensy4 - it uses all kinds of libraries and hardware - had NO problems. Uses 190KB ITCM, 250K DTCM - really a lot of code (>12K lines sourcecode PLUS libraries), but porting was easy - had to add code for I2S setFreq() and for my own hardware only.. All used libs worked out of the box!

Edit: Missing is EEProm, and I want to add USB Audio, later. Then, I hope Paul ports MTP too, because that's on my wishlist for the SDR.
 
Last edited:
@Frank B - That is good news and bodes well for other libraries that are out there. :)

EDIT: Yep EEProm is missing and can use that to test a few libraries I have.
 
Last edited:
The Lines/Sec numbers go LOW and also SURGE HIGH - even in SerMon or TyComm.

Now that is an interesting result. I haven't see anything like that happen with Linux. It's definitely something I'd like to investigate.

On the Teensy side, my guess is something is going wrong, then this code is catching up.

Code:
  uint32_t msec = millis();
  if (msec - prior_msec > 1000) {
    prior_msec = prior_msec + 1000;

Before improving the benchmark, I'd really like to understand if there's ever a case where "msec - prior_msec" is significantly more than 1000.

If I set up my Windows test machine, anything special I should do to reproduce this behavior. Is it reproducible with only the Arduino serial monitor?
 
I've got new code to upload - with a few more tweaks. Cleaner more minimal output:
Code:
T:\T_Downloads\pjrc_latency_test>lps_test.exe COM8
port COM8 opened
#0 : __>>count=1133259638, lines/sec=24623<<__
#8 : __>>count=1678408274, lines/sec=84264<<__
#16 : __>>count=1678423254, lines/sec=84264<<__
#24 : __>>count=1678438233, lines/sec=24540<<__
#32 : __>>count=1678453213, lines/sec=24540<<__
#35 : __>>count=1678458830, lines/sec=24815<<__
#36 : __>>count=1678460703, lines/sec=24815<<__
#37 : __>>count=1678462575, lines/sec=24815<<__
#38 : __>>count=1678464448, lines/sec=24815<<__
#39 : __>>count=1678466320, lines/sec=24815<<__
#40 : __>>count=1678468192, lines/sec=24815<<__
#41 : __>>count=1678470065, lines/sec=24815<<__
 ------  elapsed time 3.185 secs for 340032 bytes

You can see it stabilizes much more quickly - this is T_3.6 - and RAM buffer for read is 64KB per line - then repeats...

I think it is surging at times as the buffer fills during the time of the prints - and of course is static when PC not connected.

I moved the prints into the main code read loop because the data receive is background to the system.

Will post the code soon ...
 
@KurtE

I got my breakout board up and running today and so far been testing pins with your BlinkAnyPin sketch. Also USBHost is working along with SPI and my ILI9488 shield which runs nicely without have to play with wires :)

Having 1 problem though - it seems when I select pin 30 it high and stays high. Tried it on the official breakout board and same thing - pin 30 stays high if I select it Is there any reason that you can think of?

Sorry just got back...

Wondering if core_pins.h is correct?

I did not double check some of these as I did not change this area for pins 30-31.... (Did in first PR... Need to double check)...
Assuming my Spreadsheet is correct:
Code:
30	EMC_37	[COLOR="#FF0000"]3.23	[/COLOR]			GPT1_3 	3_RX	3:MCLK	IO-23			
31	EMC_36	[COLOR="#FF0000"]3.22	[/COLOR]			GPT1_2	3_TX	3:TX_DATA	IO-22
But we have
Code:
#define CORE_PIN30_BIT		24
#define CORE_PIN31_BIT		23
#define CORE_PIN30_PORTSET	GPIO4_DR_SET
#define CORE_PIN31_PORTSET	GPIO4_DR_SET
So not updated to new pins... note the portset one are the older names. looks like these pins need updating
 
You can see it stabilizes much more quickly

Can I talk you into doing the opposite? I know you want to create a good benchmark program. Long term, that's great. But right now, the thing that would help the most is making this problem worse, not better. The more the problem happens, the better chance I'll have of reproducing it here in a way I can understand what's going wrong. Especially if the Teensy side is computing a too-high number, would be good to investigate why the timing goes off the rails.
 
@defragster - @KurtE

Was going to have some diner then go through the pin configurations - was also just looking at the manual to check a couple of things. I am wondering if that might be the cause of CANFD not working properly. Trying to do it step by step to make sure its not me.

EDIT: Paul's original table has it the same way. If I look further down:
Code:
#define CORE_PIN30_PORTCLEAR	GPIO9_DR_CLEAR
#define CORE_PIN31_PORTCLEAR	GPIO9_DR_CLEAR
Shouldn't the GPIO# be the same - ok been going through the manual - wheres the do I find what its suppose to be?
 
Last edited:
Can I talk you into doing the opposite? I know you want to create a good benchmark program. Long term, that's great. But right now, the thing that would help the most is making this problem worse, not better. The more the problem happens, the better chance I'll have of reproducing it here in a way I can understand what's going wrong. Especially if the Teensy side is computing a too-high number, would be good to investigate why the timing goes off the rails.

Indeed - not looking to make a useless one time benchmark - but expand a tool to help you find weak spots and quickly check for regressions and progress - that's why I expanded the latency_test as I did with the array to focus on selective boundaries - and made it easy to repeat.

I'll look to add a cmdline param for a delay inside or outside the loop as needed , I expect that will do the trick - that will fill the system and the surging will repeat. Sort of like a garden hose on and off - the hose swells storing water and energy flexing the hose ... like a capacitor for discharge when it opens again.
 
FWIW, here is graph of lines/second for T4B2 with latest github core and debug printf's disabled. First few seconds of data discarded. Collected on linux laptop.
t4b2lps.png
min/max/avrg: 25414/25588/25527
Sketch recalculates lines-per-second every second.

Or is this graph too revealing?
 
@Paul @defrag and @mjs...

I put up a new branch: https://github.com/KurtE/cores/tree/T4B2_PIns30_31

Which I think I properly fixed pins 30 and 31... At least they blink now with my blink any pin... So nice to be able to use on Serial and not have to use Serial4 :D


Yes it is, was so happy not to have to hook up another Teensy :) - I have a folder of utility sketches and that right where it went. One of the first things I loaded up after USBHost and ILI9488 tests on the breakout.

EDIT: Just downloaded and updated core_pins.h and yeah the pins look good (on PJRC breakout). Had to try CANFD but still now joy. But have to double check the changes I kept making today just in case I messed something up.
 
Last edited:
Below is pending cleanup/upload ... my edits under #ifdef WINDOWS only ... that is T_3.6 because this is the best current T4-2 will do:
Code:
T:\T_Downloads\pjrc_latency_test>lps_test.exe COM25
port COM25 opened
#0 : __>> count=10630525, lines/sec=3366 <<__
#1 : __>> count=10632784, lines/sec=1 <<__
#2 : __>> count=10635044, lines/sec=1 <<__
#3 : __>> count=10637191, lines/sec=2675 <<__
#4 : __>> count=10639239, lines/sec=2675 <<__
#5 : __>> count=10641287, lines/sec=[B][U]3953[/U][/B] <<__
#6 : __>> count=10643335, lines/sec=3953 <<__
#7 : __>> count=10645383, lines/sec=3957 <<__
Code:
T_3.6 at 180 MHz::
T:\T_Downloads\pjrc_latency_test>lps_test.exe COM8 2
port COM8 opened
#0 : __>> count=28586654, lines/sec=25260 <<__
#1 : __>> count=28834471, lines/sec=[COLOR="#FF0000"]137705 [/COLOR]<<__
#2 : __>> count=28836399, lines/sec=137705 <<__
#3 : __>> count=28838326, lines/sec=137705 <<__
#4 : __>> count=28840254, lines/sec=137705 <<__
#5 : __>> count=28842181, lines/sec=137705 <<__
#6 : __>> count=28844109, lines/sec=137705 <<__
#7 : __>> count=28846036, lines/sec=137705 <<__
#8 : __>> count=28847964, lines/sec=137705 <<__
#9 : __>> count=28849891, lines/sec=137705 <<__
#10 : __>> count=28851819, lines/sec=137705 <<__
#11 : __>> count=28853746, lines/sec=137705 <<__
#12 : __>> count=28855674, lines/sec=137705 <<__
#13 : __>> count=28857652, lines/sec=[COLOR="#FF0000"]33311 [/COLOR]<<__
#14 : __>> count=28859638, lines/sec=33311 <<__
#15 : __>> count=28861623, lines/sec=33311 <<__
#16 : __>> count=28863609, lines/sec=33311 <<__
#17 : __>> count=28865595, lines/sec=33311 <<__
#18 : __>> count=28867581, lines/sec=33311 <<__
#19 : __>> count=28869567, lines/sec=33311 <<__
#20 : __>> count=28871553, lines/sec=33311 <<__
#21 : __>> count=28873539, lines/sec=33311 <<__
#22 : __>> count=28875525, lines/sec=33311 <<__
#23 : __>> count=28877511, lines/sec=33311 <<__
#24 : __>> count=28879497, lines/sec=33311 <<__
#25 : __>> count=28881483, lines/sec=33311 <<__
#26 : __>> count=28883469, lines/sec=[COLOR="#FF0000"]26195 [/COLOR]<<__
#27 : __>> count=28885455, lines/sec=[B][U]26195 [/U][/B]<<__
#28 : __>> count=28887441, lines/sec=26195 <<__
#29 : __>> count=28889427, lines/sec=26195 <<__
#30 : __>> count=28891413, lines/sec=26195 <<__
#31 : __>> count=28893398, lines/sec=26195 <<__
#32 : __>> count=28895384, lines/sec=26195 <<__
#33 : __>> count=28897370, lines/sec=26195 <<__
#34 : __>> count=28899356, lines/sec=26195 <<__
#35 : __>> count=28901342, lines/sec=26195 <<__
#36 : __>> count=28903328, lines/sec=26195 <<__
#37 : __>> count=28905314, lines/sec=26195 <<__
#38 : __>> count=28907300, lines/sec=26195 <<__
#39 : __>> count=28909286, lines/sec=25996 <<__
 ------  elapsed time 3.041 secs for 323840 bytes
 
Nobody told me if my Ubuntu Linux binary was usable? Just would be nice to know I can build in WSL if needed. UPDATED binary included in Linux folder in zip below.

UPDATED: Unified test sketch/c file names - attempted Linux port for lps_test and compiled in LINUX
Here is my folder with sketch and source.c for both [ latency_test and lps_test ]
Code:
 [ATTACH]16524._xfImport[/ATTACH]

New Code 2 params:
[ param #1 - still upper case COM# ]
#2: how many times [1-9] to run the inbuilt set of loops [int blkcnt = 20;]
#3: how many of these surge delays [1-9] should be used in 2 places: if ( surge ) delay(surge*0.003);
>> Update has a different factor [delay(surge*0.03)] outside loop to allow data to collect for next pass surge ... T-3.6 data below shows that it never normalizes.
> edits made to WINDOWS for this behavior - and untested first pass for Linux in (4).zip

shows this on T_3.6:
Code:
T:\T_Downloads\pjrc_latency_test>[B][U]lps_test.exe COM8 2  8[/U][/B]
port COM8 opened
repeat 40
surge 8 delay
#0 : __>> count=442320987, lines/sec=68305 <<__
#1 : __>> count=473555929, lines/sec=134613 <<__
#2 : __>> count=473573738, lines/sec=134613 <<__
#3 : __>> count=473591724, lines/sec=134613 <<__
#4 : __>> count=473610025, lines/sec=66725 <<__
#5 : __>> count=473628348, lines/sec=66725 <<__
#6 : __>> count=473646706, lines/sec=66725 <<__
#7 : __>> count=473664871, lines/sec=64030 <<__
#8 : __>> count=473683038, lines/sec=64030 <<__
#9 : __>> count=473701333, lines/sec=64030 <<__
#10 : __>> count=473719539, lines/sec=63071 <<__
#11 : __>> count=473737761, lines/sec=63071 <<__
#12 : __>> count=473755994, lines/sec=63071 <<__
#13 : __>> count=473774396, lines/sec=63071 <<__
#14 : __>> count=473792451, lines/sec=55586 <<__
#15 : __>> count=473810581, lines/sec=55586 <<__
#16 : __>> count=473828834, lines/sec=55586 <<__
#17 : __>> count=473847039, lines/sec=63452 <<__
#18 : __>> count=473865329, lines/sec=63452 <<__
#19 : __>> count=473883642, lines/sec=63452 <<__
#20 : __>> count=473902281, lines/sec=63667 <<__
#21 : __>> count=473920533, lines/sec=63667 <<__
#22 : __>> count=473938992, lines/sec=63667 <<__
#23 : __>> count=473957253, lines/sec=63667 <<__
#24 : __>> count=473975424, lines/sec=55738 <<__
#25 : __>> count=473993728, lines/sec=55738 <<__
#26 : __>> count=474012161, lines/sec=55738 <<__
#27 : __>> count=474030440, lines/sec=63665 <<__
#28 : __>> count=474048675, lines/sec=63665 <<__
#29 : __>> count=474066919, lines/sec=63665 <<__
#30 : __>> count=474085206, lines/sec=63488 <<__
#31 : __>> count=474103424, lines/sec=63488 <<__
#32 : __>> count=474121581, lines/sec=63488 <<__
#33 : __>> count=474140068, lines/sec=63488 <<__
#34 : __>> count=474158322, lines/sec=55661 <<__
#35 : __>> count=474176579, lines/sec=55661 <<__
#36 : __>> count=474194753, lines/sec=55661 <<__
#37 : __>> count=474213029, lines/sec=63448 <<__
#38 : __>> count=474231464, lines/sec=63448 <<__
#39 : __>> count=474249798, lines/sec=63448 <<__
 ------  elapsed time 12.053 secs for 323840 bytes

shows this for T_3.1:
Code:
T:\T_Downloads\pjrc_latency_test>lps_test.exe COM19 1 2
port COM19 opened
#0 : __>> count=929303829, lines/sec=24951 <<__
#1 : __>> count=929443226, lines/sec=54387 <<__
#2 : __>> count=929445156, lines/sec=54387 <<__
#3 : __>> count=929447085, lines/sec=54387 <<__
#4 : __>> count=929449013, lines/sec=45772 <<__
#5 : __>> count=929450940, lines/sec=45772 <<__
#6 : __>> count=929452868, lines/sec=45772 <<__
#7 : __>> count=929454795, lines/sec=45772 <<__
#8 : __>> count=929456723, lines/sec=45772 <<__
#9 : __>> count=929458650, lines/sec=45772 <<__
#10 : __>> count=929460578, lines/sec=45772 <<__
#11 : __>> count=929462505, lines/sec=45772 <<__
#12 : __>> count=929464435, lines/sec=45772 <<__
#13 : __>> count=929466364, lines/sec=45772 <<__
#14 : __>> count=929468292, lines/sec=45772 <<__
#15 : __>> count=929470221, lines/sec=45772 <<__
#16 : __>> count=929472149, lines/sec=45772 <<__
#17 : __>> count=929474076, lines/sec=24933 <<__
#18 : __>> count=929476006, lines/sec=24933 <<__
#19 : __>> count=929477933, lines/sec=24933 <<__
 ------  elapsed time 1.584 secs for 161920 bytes
 
Last edited:
@Paul @defrag and @mjs...

I put up a new branch: https://github.com/KurtE/cores/tree/T4B2_PIns30_31

Which I think I properly fixed pins 30 and 31... At least they blink now with my blink any pin... So nice to be able to use on Serial and not have to use Serial4 :D

Funny - I'm using Pin 30 and 31 from Serial5 breakout for second encoder using Encoder.h and it is working there for interrupt read. I suppose that means I should get that change and see it work.

Use Serial USB ? How can you use what is being tested :) ... just plug in more Teensys ... Serial2 and Serial4 ... of course there is that power on Serial pins problem for cold Start / Power On.

Paul: Hopefully the pjrc_latency_test (4).zip in prior post offers useful PC_Side tools for test with latency and LinePerSec in that.

The other hopefully well done worthwhile update to latency_test was verified changing data to confirm data integrity to some level of confidence as that was something you mentioned - even if it doesn't use a 'checksum' just 100% check.
 
@defragster

Funny - I'm using Pin 30 and 31 from Serial5 breakout for second encoder using Encoder.h and it is working there for interrupt read. I suppose that means I should get that change and see it work.
Confused Serial5 pins are 20/21. Pins 30/31 aren't connected to any pin on the breakout as far as I know and are connected to CANFD transceiver.

Sorry haven't tried your Linux port but don't have a Linux machine. Maybe tomorrow with play with an old laptop to see if I can get it working as a Linux platform.
 
Now that is an interesting result. I haven't see anything like that happen with Linux. It's definitely something I'd like to investigate.

On the Teensy side, my guess is something is going wrong, then this code is catching up.

Code:
  uint32_t msec = millis();
  if (msec - prior_msec > 1000) {
    prior_msec = prior_msec + 1000;

Before improving the benchmark, I'd really like to understand if there's ever a case where "msec - prior_msec" is significantly more than 1000.

If I set up my Windows test machine, anything special I should do to reproduce this behavior. Is it reproducible with only the Arduino serial monitor?

I missed this … hopefully I got the updated code usable and nearly right under Linux so you can expose it to the same stuff and know if Windows is alone.

Your guess is where I went - I shorted the strings and added the msec diff in a print - it was 0 or a few ms - and it maintained that while the lps_test was holding high. I took a dinner/movie break.

I think the benchmark tool is good for what I can test against - on first start with Teensy running - or in delay between runs or with adjustable 'surge' value.

As posted T4-2 never gets over 4K - until you get to work through refinements that is the baseline. And the T_3.x's tested stabilize about 24K - can run slower 10-15K if the test_lps sketch is bogged in the wrong spot with the surge delay in the inner loop. And they will surge 40 to 130K or something on startup or with the right surge tweak value

Nothing special needed it just worked. It can't connect of course when SerMon is connected - but as written it is not always self starting … while(!Serial) ? - … but any Sermon connect then started the outrush of data after connection. And I have the 3 Teensy running the sketch and I can jump between them. You should see the same, let me know.

Interesting if the Linux code runs and shows alternate behavior. It should mirror the changes I made to the WINDOWS chunk below in that func()

I put that folder on github :: pjrc_latency_test

RE: SerMon - I use TyCommander of course whenever as I can as it has better UI Including a button for Serial On/Off without closing - and multiple Teensy at the same time. But IIRC - they were both more limited … will have to check as I was spending time with MinGW and the gcc C code ...
 
Last edited:
@defragster


Confused Serial5 pins are 20/21. Pins 30/31 aren't connected to any pin on the breakout as far as I know and are connected to CANFD transceiver.

Sorry haven't tried your Linux port but don't have a Linux machine. Maybe tomorrow with play with an old laptop to see if I can get it working as a Linux platform.

opps - I was reading UART5 on the cheat sheet … okay half reading … versus Serial5 pins.
 
@defragster
I confuse easily these so glad I didn't miss anything.

I just tried your lps_test.exe from post #2665. Doesn't seem to want to work for me. Tried T4B2 and T3.5:
Code:
latency_test>lps_test COM7 2 8
port COM7 opened
repeat 40
surge 8 delay
        _brk_
        _brk_
        _brk_
        _brk_
        _brk_
And, yes, I had the lps_test.ino file loaded.

UPDATE: NEVER MIND - just read your last updated post :)
 
@defragster
I confuse easily these so glad I didn't miss anything.

I just tried your lps_test.exe from post #2665. Doesn't seem to want to work for me. Tried T4B2 and T3.5:
Code:
latency_test>lps_test COM7 2 8
port COM7 opened
repeat 40
surge 8 delay
        _brk_
        _brk_
        _brk_
        _brk_
        _brk_
And, yes, I had the lps_test.ino file loaded.

UPDATE: NEVER MIND - just read your last updated post :)

Oh yeah - PAUL - BTW if you see '_brk_' that means you need to hit Teensy with SerMon!

It will also show on TimeOut error - I just dropped that in in case that _break_ abort case was associated with the bad LPS numbers, it is not - but it shows when the Teensy connects but not transmitting. EXE not asserting DTR or something and it takes an overt write to open the connection.

I think the latency sketch that expects an 'x' could be modified to see 'y' and just to the code for LPS code … then LPS test could start by sending 'y' - open the connection and be ready to run, then swapping back to the latency test would just take a reset.
 
Paul - back to my machine to see what SerMon shows as far as the lps_test.ino:

TyComm and IDE SerMon ( Teensy Ports ) - both stabilize about 24K -27K. Both starting from OFF to Connecting report that same impossibly high value on my machine.

With TyComm having a window open to ALL Three 3.1, 3.6 and T4:

the T_3.x have buffered about 18 lines of the last stable data - that runs out and the 3.1 hits 45K and works down, the faster to loop T_3.6 jumps to 131K lines/sec

The T_4 starts at 1 then jumps to 1104 many pages later then many pages more later hits 3983.

These jumps are because the updates are 1 second apart ... many any messages per seconds

As we know T4 stalls loop when !Serial - so the counting stops, but the T_3's run like crazy when !Serial.

Perhaps the test needs a blocking send_now once a second or something - or a check on serial_avaialable_for_write ? Or at least make this conditional :: if ( Serial ) count = count + 1;

Though this line - and the one after - it seems should make the over counting go away 1 second after connecting? :: count_per_second = count - prior_count;

But then again at 25K lines per second - one second is a LOT of SPEW

I may look at this shortly ...

Since the message string is 15+ bytes maybe this or something related is needed:
if ( Serial.availableForWrite() > 15 ) count = count + 1;

Does T4-2 have a working :: Serial.availableForWrite() ...
 
Answers coded below in LPS_TEST.INO

Answers coded below in LPS_TEST.INO - SerMon's and lps_test.exe agree OverRun Surge is fixed for T_3's.

Oddity Question:: Why does this not affect Linux the same?

> T4 does not yet have a working Serial.availableForWrite(), and it already stops when dis-connected.
> Using this on T_3's to limit the count increment solves the issue:: if ( Serial.availableForWrite() > 15 )

My test code from before to show the millis is still in place and holds at zero. This code updated on github.com/Defragster/T4_demo/... /pjrc_latency_test

Code:
// https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=204681&viewfull=1#post204681
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);
  while (!Serial) ;
  count = 10000000;
  prior_count = count;
  count_per_second = 0;
  prior_msec = millis();
}
int blog = 0;
void loop() {
  Serial.print("c#");
  Serial.print(count);
  Serial.print(" b#");
  Serial.print(blog);
  Serial.print(", lines/s=");
  Serial.println(count_per_second);
[B]  #if !defined(__IMXRT1062__)
[U]  if ( Serial.availableForWrite() > 15 )[/U]
  #endif
    count = count + 1;[/B]
  uint32_t msec = millis();
  if (msec - prior_msec > 1000) {
    prior_msec = prior_msec + 1000;
    blog = (msec - prior_msec) / 10;
    count_per_second = count - prior_count;
    prior_count = count;
  }
}

BTW: Since it has to run a second or two now to get counts ... that next param is important

ALSO - the counts reported now are more like 20K lines/sec - even when they were working the free running count++ in loop() was over estimating on T_3's.

And opening a TyComm second instance to second Teensy drops the count on both - as one would expect with the machine bandwidth getting stretched.
 
Last edited:
@defragster
I confuse easily these so glad I didn't miss anything.

I just tried your lps_test.exe from post #2665. Doesn't seem to want to work for me. Tried T4B2 and T3.5:

And, yes, I had the lps_test.ino file loaded.
...:)

At least you recognized you may have been confused - but it was me … :) I did not get any POGO pins so I can't get to those pads - which is good because I can find enough distractions without taking my board apart more than removing the base to put that resistor on.

Glad I went looking for the 'gcc' and found the MinGW install steps - it was much more fruitful that my searches for a USB Loopback Visual Studio project … or anything of the sort. And keeps at/near the Linux usability too.

Updated the lps_test.ino Paul provided [ on github.com__pjrc_latency_test ] - it does have while(!Serial) and I didn't remove that. The other latency Exe does a write and confirm check on starting - because it sends a command 'x' to start. I removed that for the 'lps' code - I thought about adding it back with 'y' to start this - but that would be like work now editing the sketch and the EXE's .c file and testing all over since it doesn't expect a command to run or if already running … At least it gives a _brk_ message now wile waiting, had I known when I edited the code I could have put in a more helpful note. It is a timeout waiting 'break' from while() loop and I wasn't sure what might trigger it so I kept the spew terse.

Also since that issue with the overblown count is solved in that update it should be working as Paul intended. Though the #ifdef T4-2 is ugly and won't work on T4-1 as written as 1062 only - and when Serial.available() comes online and Serial goes non-blocking when away it will show funny numbers - really big funny number with higher loop() passing :)

My T4-2 stopped just getting lost - must have been my wool sweater and dry air that day. About 3 times was very odd as I wasn't zapping anything - just passing near 8" loops of wire connecting things. Really odd it stopped loop() processing - but pin interrupt and USB continued in some fashion at least once. Will have to check - maybe USB just started blocking loop() if it got lost and _isr() code and the Debug_Print Serial4 was still able to process - suppose I need to put in a PULL request for the '#define printf_debug(...)' needed in print.h when no PRINT_DEBUG_STUFF is on because it will break the HardFault_HandlerC() prints 'WE' put in - DONE :: drop out code when no print_debug_stuff pull/375 - that whole section could be ifdef print_debug_stuff - but that was easier and what I did so it works - though I don't see side effects from the printing code … - that will be #if 0 when it ships anyhow.
 
Status
Not open for further replies.
Back
Top