Teensy 4.0 First Beta Test

Status
Not open for further replies.
Hey team, I received my Teensy 4 board today with the hopes of getting my Speeduino ECU firmware running for it shortly. I'm experiencing what appear to be hard lockups of it though, seemingly serial (buffer?) related.

To reproduce, here is a SUPER simple sketch based on the Arduino Serial example that runs on AVR and Teensy 3.5/3.6 systems without a problem:
Code:
void setup() {
  // initialize serial communication at 9600 bits per second:
  Serial.begin(115200);
}

// the loop routine runs over and over again forever:
void loop() {
  // print out the value you read:
  Serial.println(millis());
  delay(1);        // delay in between reads for stability
}

On the Teensy4 this runs for between 5 and 10 seconds before locking up. The problem occurs fairly quickly with the delay value set to 1 or 2 and with 3 it seems to run most of the time without issue but does freeze occasionally (Up to 120+ seconds after startup). With delay values of 4 and above it seems fine.

I understand there's a limited serial transmit buffer, but I would not expect that doing something like this should cause a hard lockup even if the buffer (if that's what it is) is exceeded. As mentioned, this same sketch runs fine on AVR and Kinetis boards without any worries.
Is anyone else seeing the same types of issues?
 
In a word, yes. I'm seeing even worse serial issues than you, I have USB-Serial dropouts even sending as slow as 30 characters per second (!) but there must be something wrong with my system as it's not just T4, also T3.2 and T-LC.
However if I use one of Teensy's real serial UARTs instead of the serial-over-USB connection, then everything works fine.
I believe Paul is currently working on the Arduino serial code to improve speed.
 
Hey team, I received my Teensy 4 board today with the hopes of getting my Speeduino ECU firmware running for it shortly. I'm experiencing what appear to be hard lockups of it though, seemingly serial (buffer?) related.

...

Now that Teensy 4 and TD 1.47 are released I went back to using TyCommander for Serial Monitor - and also uploading so I can do it all from my editor as IDE without the Arduino IDE {TyComm still Beta needs an ENV var set to allow uploading - but working fine for months off and on in Beta when not on Arduino IDE}.

Running the delay(1) against TyComm at delay(1) didn't show any problems - so I doubled it …
Code:
void loop() {
  Serial.println(millis());
  delayMicroseconds(500);        // delay in between reads for stability
}

The GUI text is scrolling fine - but too fast to watch anything but the seconds tick by - and not see any added garbage or merged lines and no obvious signs of shorted lines. Sketch now running on TWO Teensy 4's at the same time using the TyComm Ctrl+N New Window feature so both have a SerMon seesion running just fine.

This is on Win 10 on a Gen #6 i7-6700 - both on the same powered USB 2.0 Hub. TyComm can get overwhelmed - but two of these at this speed with short lines is not enough to do it. These lines are only 2,000/second and only 7 chars long - the PJRC LPS test has lines about 32 chars long and works at over 100,000 lines { 80K-150K } - with some corruption or PC slowdown resulting.

One T4 at 930 seconds and the other 628 and both counting. I think even IDE SerMon would do this on this machine - but it isn't open.

Give TyCommander a try until Paul can put out an improved version for IDE SerMon - check your cables - try a hub or different port ???
 
Sorry for endless information ;) But I wanted to make sure it was not just as simple as a large amount of data in DTCM... SO did a quick and dirty version of the ili9341_t3 pictureembed, with two full size 240x320 images and I made sure to not have PROGMEM...

Code:
Sketch uses 334864 bytes (16%) of program storage space. Maximum is 2031616 bytes.
Global variables use 339584 bytes (32%) of dynamic memory, leaving 708992 bytes for local variables. Maximum is 1048576 bytes.
D:\arduino-1.8.9\hardware\teensy/../tools/teensy_post_compile -file=T4_ili9341_pictureEmbed

I believe it has more DTCM in it, but less ITCM: And it has
……...

And if anyone wants to try it:View attachment 17271

@KurtE
Thanks for putting this all together. Going to take me a bit to absorb it all. But just a quick note I think from the other dumps we did in the other thread you are right that it has more DTCM than ITCM.

Paul I think had a note that I reposted that said 512K is split between ITCM and DTCM (256K max each? I guess). ITCM fills up first and then allocated to nearest 32K boundary (think that is what you saw) then the rest is DTCM.

Oh - is that the right attachment?
 
Paul I think had a note that I reposted that said 512K is split between ITCM and DTCM (256K max each? I guess). ITCM fills up first and then allocated to nearest 32K boundary (think that is what you saw) then the rest is DTCM.

Yes, except the part about a 256K limit. All of the 512K not used for ITCM is allocated to DTCM. For a common Arduino program that takes under 64K in ITCM, that would give you 448K allocated to DTCM.
 
@PaulStoffregen

Thanks for the clarification on that one Paul. Now to see I can modify imxrt-size to take that into account.

Is it possible to make something like that a permanent addition to Teensyduino?
 
Again not sure if you will find this part interesting, but I took the sketch that displayed the front and back of the T4 card on an ILI9341 display (from DTCM memory), and added a dump at the start showing some of the memory stuff:
Code:
void DumpMemoryInfo() {
#if defined(__IMXRT1062__)
  // from the linker
//  extern unsigned long _stextload;
  extern unsigned long _stext;
  extern unsigned long _etext;
//  extern unsigned long _sdataload;
  extern unsigned long _sdata;
  extern unsigned long _edata;
  extern unsigned long _sbss;
  extern unsigned long _ebss;
//  extern unsigned long _flexram_bank_config;
  extern unsigned long _estack;
uint32_t flexram_config = IOMUXC_GPR_GPR17;
  Serial.printf("IOMUXC_GPR_GPR17:%x IOMUXC_GPR_GPR16:%x IOMUXC_GPR_GPR14:%x\n", 
      flexram_config, IOMUXC_GPR_GPR16, IOMUXC_GPR_GPR14);
  Serial.printf("Initial Stack pointer: %x\n", &_estack); 
  uint32_t dtcm_size = 0;
  uint32_t itcm_size = 0;
  for (;flexram_config; flexram_config >>=2) {
    if ((flexram_config & 0x3) == 0x2) dtcm_size += 32768;
    else if ((flexram_config & 0x3) == 0x3) itcm_size += 32768;
  }
  Serial.printf("ITCM allocated: %u  DTCM allocated: %u\n", itcm_size, dtcm_size);
  Serial.printf("ITCM init range: %x - %x Count: %u\n", &_stext, &_etext, (uint32_t)&_etext - (uint32_t)&_stext);
  Serial.printf("DTCM init range: %x - %x Count: %u\n", &_sdata, &_edata, (uint32_t)&_edata - (uint32_t)&_sdata);
  Serial.printf("DTCM cleared range: %x - %x Count: %u\n", &_sbss, &_ebss, (uint32_t)&_ebss - (uint32_t)&_sbss);
#endif  
}

Output:
Code:
IOMUXC_GPR_GPR17:aaaaaaaf IOMUXC_GPR_GPR16:7 IOMUXC_GPR_GPR14:aa0000
Initial Stack pointer: 20070000
ITCM allocated: 65536  DTCM allocated: 458752
ITCM init range: 0 - 8a60 Count: 35424
DTCM init range: 20000000 - 2004c760 Count: 313184
DTCM cleared range: 2004c760 - 2004f2c0 Count: 11104
Display Front of card
Display Back of card

Now wondering if everything above _ebss up till _estack is all now only used by stack?

If so might hack up some stuff, which then initializes everything from that value up to current stack pointer with some initial value, like: 0xff or maybe something a little different, and then maybe have a function that I call at random times, that tries to guess how far down the stack has used, by finding the first place that is not the specified value...

EDIT
- I thought I should mention, that I crashed the USB, with a program mistake, that is I missed adding a %u to the last printf, that is it was:
Code:
  Serial.printf("DTCM cleared range: %x - %x Count: \n", &_sbss, &_ebss, (uint32_t)&_ebss - (uint32_t)&_sbss);
It then crashed and said the USB was not recognized... I then wondered if same as earlier crash so was about to #ifdef around the last couple printfs...
But found the bug and fixed it and rebuilt. Hit the program button and it looked like it downloaded properly, but USB was still crashed.

It was only after I did the 15+ second reset and then waited for the system to say that it was raw hid, and then pressed the program button again and it worked again
 
Code:
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
30     EMC_37     3.23                         GPT1_3   3_RX  3:MCLK     I-23
31     EMC_36     3.22                         GPT1_2   3_TX  3:TX_DATA  I-22

Hi Paul,

I looked at the Schematic searching for alternate Pins from CanFD, and find no alternativ Pins for it btw. but this:
schematic40.png

Teensy Pin 30 (CRX3) is linked to EMD_37 from the Reference Manual it should EMC_37, prescribed?

BR
Markus
 
@PaulStoffregen and others:

Again More on memory stuff... Maybe should move to new thread?

But: I thought I would blindly add a third full size ILI9341 display image:

Like the other two (without PROGMEM).
It built fine, BUT nothing works, no errors...
Code:
Sketch uses 507952 bytes (25%) of program storage space. Maximum is 2031616 bytes.
Global variables use 511328 bytes (48%) of dynamic memory, leaving 537248 bytes for local variables. Maximum is 1048576 bytes.
D:\arduino-1.8.9\hardware\teensy/../tools/teensy_post_compile -file=T4_ili9341_pictureEmbed.ino -path=C:\Users\kurte\AppData\Local\Temp\arduino_build_543316 -tools=D:\arduino-1.8.9\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/7/1 -portlabel=(null) -portprotocol=(null)
Which gives us:
Code:
aaaaaaaf A _flexram_bank_config

20070000 B _estack

00000000 T _stext
60001610 A _stextload
00008aa0T _etext


20000000 D _sdata
6000a0bc A _sdataload
20071f80 D _edata

20071f80 B _sbss
200742c0 B _ebss
As suspected: the _edata as well as the _sbss _ebss > end of DTCM as shown by the value _estack...

Other notes: If I try to compile the sketch using images directly brought over from: http://www.rinkydinkelectronics.com/t_imageconverter565.php
The conversion files have:
Code:
#if defined(__AVR__)
    #include <avr/pgmspace.h>
#elif defined(__PIC32MX__)
    #define PROGMEM
#elif defined(__arm__)
    #define PROGMEM
#endif

const unsigned short teensy40_front[76800] PROGMEM={ ...
Which gives compiler warnings:
Code:
In file included from C:\Users\kurte\Documents\Arduino\Teensy Tests\T4_ili9341_pictureEmbed\T4_ili9341_pictureEmbed.ino:16:0:

C:\Users\kurte\AppData\Local\Temp\arduino_build_543316\sketch\teensy40_front.c:11:0: warning: "PROGMEM" redefined

     #define PROGMEM

 ^

In file included from D:\arduino-1.8.9\hardware\teensy\avr\cores\teensy4/WProgram.h:41:0,

                 from C:\Users\kurte\AppData\Local\Temp\arduino_build_543316\pch\Arduino.h:6:

D:\arduino-1.8.9\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition

 #define PROGMEM __attribute__((section(".progmem")))
If I remove the stuff:
Code:
#if defined(__AVR__)
    #include <avr/pgmspace.h>
#elif defined(__PIC32MX__)
    #define PROGMEM
#elif defined(__arm__)
    #define PROGMEM
#endif
It errors with:
Code:
teensy40_front.c:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'
 const unsigned short teensy40_front[76800] PROGMEM={

Which I will fix. I believe the issue is that the .ino file is including the .c files and then the .c files are trying to compile also...
renamed the tabs to .h... and that worked...

Then wondered, Can I by chance define the last image to be installed in the Upper 512KB of memory? So I tried changing the define like:
Code:
const unsigned short teensy40_front[76800] DMAMEM={ ...
[/CODE]

And the Link failed with rather a strange message:
Code:
Linking everything together...
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -O2 -Wl,--gc-sections,--relax "-TD:\\arduino-1.8.9\\hardware\\teensy\\avr\\cores\\teensy4/imxrt1062.ld" -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316\\sketch\\T4_ili9341_pictureEmbed.ino.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316\\libraries\\SPI\\SPI.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316\\libraries\\ILI9341_t3\\ILI9341_t3.cpp.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316\\libraries\\ILI9341_t3\\font_Arial.c.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316\\libraries\\ILI9341_t3\\font_ArialBold.c.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316\\libraries\\ILI9341_t3\\glcdfont.c.o" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/..\\arduino_cache_408718\\core\\core_7ab3d924210d22e02afbf9266aa5c54d.a" "-LC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316" -larm_cortexM7lfsp_math -lm -lstdc++
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.eep"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objcopy" -O ihex -R .eeprom "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.elf" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.hex"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.lst" "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -d -S -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.elf"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/stdout_redirect" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.sym" "D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316/T4_ili9341_pictureEmbed.ino.elf"
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/teensy_post_compile" -file=T4_ili9341_pictureEmbed.ino "-path=C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_543316" "-tools=D:\\arduino-1.8.9\\hardware\\teensy/../tools/" -board=TEENSY40
Teensy Loader could not find the file T4_ili9341_pictureEmbed.ino

Multiple libraries were found for "ILI9341_t3.h"
 Used: C:\Users\kurte\Documents\Arduino\libraries\ILI9341_t3
 Not used: D:\arduino-1.8.9\hardware\teensy\avr\libraries\ILI9341_t3
Using library SPI at version 1.0 in folder: D:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI 
Using library ILI9341_t3 at version 1.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\ILI9341_t3 
quitexit status 1
Error compiling for board Teensy 4.0.
If I change back to PROGMEM, it runs again just fine...

Probably enough rambling :D
 
For what it is worth, here is a hacked up version of imxrt-size.c that I build in visual studio 2019...

Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int printnumbers(unsigned flexram_config, unsigned itcm, unsigned dtcm, unsigned ocram, unsigned flash, unsigned stack,
	unsigned ocramm, unsigned flashm)
{
	unsigned dtcm_allocated = 0;
	unsigned itcm_allocated = 0;
	printf("flexRam Config : %08lx\r", flexram_config);
	for (; flexram_config; flexram_config >>= 2) {
		if ((flexram_config & 3) == 2) dtcm_allocated += 32;	// 32K per bank;
		else if ((flexram_config & 3) == 3) itcm_allocated += 32;	// 32K per bank;
	}
	printf("ITCM : %6d B\t(%5.2f%% of %4d KB)\r", itcm, itcm / (itcm_allocated * 1024.0) * 100, itcm_allocated);
	printf("DTCM : %6d B\t(%5.2f%% of %4d KB)\r", dtcm, dtcm / (dtcm_allocated * 1024.0) * 100, dtcm_allocated);
	printf("Stack Size : %6d\r", stack);
	printf("OCRAM: %6d B\t(%5.2f%% of %4d KB)\r", ocram, ocram / (ocramm * 1024.0) * 100, ocramm);
	printf("Flash: %6d B\t(%5.2f%% of %4d KB)\r", flash, flash / (flashm * 1024.0) * 100, flashm);
	return 0;
}


int main() {
	const int bl = 200;
	char str[bl + 1];
	char* s;

	unsigned teensy_model_identifier = 0;
	unsigned stext = 0;
	unsigned etext = 0;
	unsigned sdata = 0;
	unsigned ebss = 0;
	unsigned flashimagelen = 0;
	unsigned heap_start = 0;
	unsigned flexram_bank_config = 0;
	unsigned estack = 0;

	do {
		s = fgets(str, sizeof(str), stdin);
		if (s) {
			str[bl] = 0;
			if (strstr(str, "_teensy_model_identifier")) teensy_model_identifier = strtol(str, NULL, 16);
			if (strstr(str, "T _stext")) stext = strtol(str, NULL, 16);
			if (strstr(str, "T _etext")) etext = strtol(str, NULL, 16);
			if (strstr(str, "D _sdata")) sdata = strtol(str, NULL, 16);
			if (strstr(str, "B _ebss")) ebss = strtol(str, NULL, 16);
			if (strstr(str, " _heap_start")) heap_start = strtol(str, NULL, 16);
			if (strstr(str, " _flashimagelen")) flashimagelen = strtol(str, NULL, 16);
			if (strstr(str, "B _estack")) estack = strtoul(str, NULL, 16);
			if (strstr(str, " _flexram_bank_config")) flexram_bank_config = strtoul(str, NULL, 16);
			//puts( str );
		}
	} while (s);

	if (teensy_model_identifier == 0x24) {
		printnumbers(flexram_bank_config, etext - stext, ebss - sdata, heap_start - 0x20200000, flashimagelen, estack-ebss, 512, 1984);
	}

	return 0;
}
Again hard to know what all anyone would like seen output, but here is an output from my display three images (front and back of T4 card, and front of T4, with one of them in PROGMEM)

Code:
cmd /c "D:\\arduino-1.8.9\\hardware\\teensy\\..\\tools\\arm\\bin\\arm-none-eabi-gcc-nm -n C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_225708\\T4_ili9341_pictureEmbed.ino.elf | C:\\Users\\kurte\\source\\repos\\imxrt-size\\Debug\\imxrt-size.exe"
flexRam Config : aaaaaaaf
ITCM :  35488 B	(54.15% of   64 KB)
DTCM : 324288 B	(70.69% of  448 KB)
Stack Size : 134464
OCRAM:      0 B	( 0.00% of  512 KB)
Flash: 507952 B	(25.00% of 1984 KB)
===info ||| Multiple libraries were found for "{0}" ||| [ILI9341_t3.h]
 Used: C:\Users\kurte\Documents\Arduino\libraries\ILI9341_t3
 Not used: D:\arduino-1.8.9\hardware\teensy\avr\libraries\ILI9341_t3
Using library SPI at version 1.0 in folder: D:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI 
Using library ILI9341_t3 at version 1.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\ILI9341_t3 
"D:\\arduino-1.8.9\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_build_225708/T4_ili9341_pictureEmbed.ino.elf"
Sketch uses 507952 bytes (25%) of program storage space. Maximum is 2031616 bytes.
Global variables use 359776 bytes (34%) of dynamic memory, leaving 688800 bytes for local variables. Maximum is 1048576 bytes.
D:\arduino-1.8.9\hardware\teensy/../tools/teensy_post_compile -file=T4_ili9341_pictureEmbed.ino -path=C:\Users\kurte\AppData\Local\Temp\arduino_build_225708 -tools=D:\arduino-1.8.9\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/7/1 -portlabel=hid#vid_16c0&pid_0478 Bootloader -portprotocol=Teensy

EDIT: Thought I would mention I will probably hack up a bit more for my own usage... Like maybe print out some separating lines, and maybe another line or so
that shows the DTCM+ITCM = 512KB and allocated on 32KB chunks.

Side note: on crashes like uncanny... wonder if it might make sense to leave some maybe not overly often used system things like USB descriptor in program space? That way hopefully can not be corrupted...
 
Last edited:
For what it is worth, here is a hacked up version of imxrt-size.c that I build in visual studio 2019...

// ...

EDIT: Thought I would mention I will probably hack up a bit more for my own usage... Like maybe print out some separating lines, and maybe another line or so
that shows the DTCM+ITCM = 512KB and allocated on 32KB chunks.

Side note: on crashes like uncanny... wonder if it might make sense to leave some maybe not overly often used system things like USB descriptor in program space? That way hopefully can not be corrupted...

Hey Kurt - I had just updated VStudio 2017 when 2019 dropped - so still using 2017 and it worked to make a console app.

Quick HACK in the great Frank B Compile.CMD looks like this as edited into github.com/Defragster/Tset:
Code:
  "%arduino%\hardware\tools\arm\bin\arm-none-eabi-gcc-nm.exe" -n "%temp1%\%sketchname%.elf" | C:\Users\mehere\source\repos\imxrt_size\Debug\imxrt_size.exe"
* the quick hack was just pointing to the output EXE rather than putting it on in the TSET known path.

Did it on this open sketch::
Code:
Using library [B]TeensyThreads [/B]at version 1.0 in folder: T:\tCode\libraries\TeensyThreads 
"T:\\arduino-1.8.9t4\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_Print.ino/Print.ino.elf"
Sketch uses 18480 bytes (0%) of program storage space. Maximum is 2031616 bytes.
Global variables use 23344 bytes (2%) of dynamic memory, leaving 1025232 bytes for local variables. Maximum is 1048576 bytes.
       upload@6052840-Teensy  Uploading to board '6052840-Teensy' (Teensy 4.0)
       upload@6052840-Teensy  Triggering board reboot
       upload@6052840-Teensy  Firmware: Print.ino.teensy40.hex
       upload@6052840-Teensy  Flash usage: 19 kiB (1.2%)
       upload@6052840-Teensy  Uploading...
       upload@6052840-Teensy  Sending reset command
flexRam Config : aaaaaaab
ITCM :  10352 B	(31.59% of   32 KB)
DTCM :  12992 B	( 2.64% of  480 KB)
Stack Size : 478528
OCRAM:      0 B	( 0.00% of  512 KB)
Flash:  18480 B	( 0.91% of 1984 KB)
[Finished in 4.1s]

@KurtE :: Cool info - please github or update source as you go.
> Also starting a new thread for this "T4 RAM WORK" would be nice - finding the posts here to make sense of it doesn't help get a clear picture.
 
@KurtE

Wow - great stuff - you got done what I was suggesting to define ITCM/DTCM better in imxrt-size.

Think I agree with @defragster about starting a new thread just so we can keep this all together for a good reference.
 
Here's my first attempt to speed up the Arduino Serial Monitor.

Please give this a try and let me know if it improves the serial monitor performance on your machine? Please also say which OS, how much memory, and what CPU your machine has.

To install, find pde.jar in your Arduino's lib folder and replace it with this one. Keep a backup of the original (somewhere outside the Arduino lib folder), since this experimental one is missing many important things. For example, you'll see a Java exception if you simply click inside the serial monitor window, since it doesn't yet support position tracking needed by text selection. You need to restart Arduino for the new pde.jar to be used.

The main thing at this point is whether is really makes enough of a difference in performance when Teensy 4.0 transmits continuously without delays.
 

Attachments

  • serialmon_speedup_1st_try.zip
    396.2 KB · Views: 71
Last edited:
Swapped the PDE.jar :: Win 10 - 16 MB RAM - i7-6700

Can't disable AutoScroll to do a cut to paste … the version of LPS.ino I have is holding about 235K lines/sec { plus and minus ~ 15 KB }

Running a about 8 minutes:
FirstNewSerMon1.47.png
 
Oh, yeah, disabling auto-scroll doesn't work yet. Neither does text selection, so even if you could stop the scrolling you wouldn't be able to copy text. I'll get that stuff working later.

The main issue right now is whether it stalls, crashes, uses too much memory, or otherwise does bad things under the load of continuous max speed printing.
 
Oh, yeah, disabling auto-scroll doesn't work yet. Neither does text selection, so even if you could stop the scrolling you wouldn't be able to copy text. I'll get that stuff working later.

The main issue right now is whether it stalls, crashes, uses too much memory, or otherwise does bad things until the load of continuous max speed printing.

Yeah - assumed all of that given the intro: "you'll see a Java exception if you simply click inside the serial monitor window"

I have not seen any signs of trouble yet - exceptions or explosions of anything - the above TaskMan data looks to be holding pretty steady - serialmon unchanged - though Java Platform p# 4140 of 397MB is creeping up to 436MB after ~26 minutes.

Running well at 222 to 238 K lps so far … not seeing 240K or above cycle through any more.

At 32 minutes the Java RAM reset lower - but throughput lps the same:
First30mNewSerMon1.47.png

Going to restart with your current copy of :: github.com/PaulStoffregen/USB-Serial-Print-Speed-Test

Left the IDE open - just closed and re-opened SerMon after new upload … will let it sit some time now …

<EDIT>: used Snipping tool to freeze the display - counts are sequential and not seen any malformed lines fly by - so the integrity looks good too
 
Oh, yeah, disabling auto-scroll doesn't work yet. Neither does text selection, so even if you could stop the scrolling you wouldn't be able to copy text. I'll get that stuff working later.

The main issue right now is whether it stalls, crashes, uses too much memory, or otherwise does bad things under the load of continuous max speed printing.

Compiled the usb to serial print test sketch and got the following:
Code:
Sketch uses 12864 bytes (0%) of program storage space. Maximum is 2031616 bytes.
Global variables use 15728 bytes (1%) of dynamic memory, leaving 1032848 bytes for local variables. Maximum is 1048576 bytes.

Right now running between 222K+ to 245+K lines per second. Going to let it run and see what happens. Count over 87Million

Capture.JPG
 
Oh, yeah, disabling auto-scroll doesn't work yet. Neither does text selection, so even if you could stop the scrolling you wouldn't be able to copy text. I'll get that stuff working later.

The main issue right now is whether it stalls, crashes, uses too much memory, or otherwise does bad things under the load of continuous max speed printing.

As a real stress test ran @bicycleguy's guy sketch. Still get the awt java exception but the data still flowing to the sermon after 5mins but with fairly high memory usage:
Capture1.JPG
 
Paul - SerialMon is much faster … ~100K lps faster IIRC - and this is way more stable. System is usable and JAVA cpu only 12 to 18 %

There do seem to be losses at hand though. Ran IDE one time and uploaded twice per above … ~25 mins running second upload and Java Memory that was last 260 above now 527MB and counts 216K to 228K lps w/github code.

Update:: the loss is recovered - 'safely'? - That 527MB number is now showing 285MB … back to 225K lps +/- 5 just now.

crosspost edit - what is "@bicycleguy's guy sketch"

I have 5 sketch IDE windows open - one has only this after about 1 hour since starting for this:
Code:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at javax.swing.text.DefaultHighlighter$SafeDamager.run(DefaultHighlighter.java:608)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
 
Last edited:
Paul - SerialMon is much faster … ~100K lps faster IIRC - and this is way more stable. System is usable and JAVA cpu only 12 to 18 %

There do seem to be losses at hand though. Ran IDE one time and uploaded twice per above … ~25 mins running second upload and Java Memory that was last 260 above now 527MB and counts 216K to 228K lps w/github code.

crosspost edit - what is "@bicycleguy's guy sketch"

I have 5 sketch IDE windows open - one has only this after about 1 hour since starting for this:
Code:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at javax.swing.text.DefaultHighlighter$SafeDamager.run(DefaultHighlighter.java:608)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Code:
void setup() {
  Serial.begin(9600);
  while(!Serial)
   ;
  Serial.println("I'm starting up");
}

void loop() {
  Serial.println("DejaVu"); // comment and uncomment this line
}
That's the same exception I see after a couple of minutes of the above sketch - but sermon stays open and keeps workings - no hangs
 
Coming up on 2 hours since IDE was opened with this 'firstTry':

lps hitting at 197-206K lps just now - that is the lowest seen.

Nothing broken or unstable looking - RAM up then down and not so high now just abit over an hour ago's 285 MB now 292MB:
First2hrNewSerMon1.47.png

<edit> : Closed SerialMon - nothing in JAVA was freed - was at 315 MB - opened SerialMon again and jumped to 441 MB and lps back in the 215-225K region.
 
:confused:
Code:
Model Name:	iMac
  Model Identifier:	iMac14,2
  Processor Name:	Intel Core i5
  Processor Speed:	3.2 GHz
  Number of Processors:	1
  Total Number of Cores:	4
  L2 Cache (per Core):	256 KB
  L3 Cache:	6 MB
  Memory:	16 GB

The speedup seems to work better in general:
Typical memory use by Arduino 1.8.9 is about 370MB. running normally before and after the speedup.
Before the speedup, after a DejaVu moment the ram would be about 980MB sometimes higher, now it seems to cap at about 755MB.
I can still make it crash it just takes more effort, maybe 4 or 5 times.

But ...
The last time after 4 or 5 tries, my whole screen went black and the iMac crashed :confused:
I gotta say I'm an amateur Mac & IOS programmer and carpal tunnel sufferer but I haven't seen the mac crash in years.
 
Noticing others comments, I found its not how long you let the window or app sit running, it's how many times you let the monitor window overflow, close it, recompile, reload, overflow. In fact I think I saw some indication of letting it overflow passed the 'stream stopped' error was better for it than if you closed the window before that and cycled again.

Also forgot to mention the Arduino app stays pretty responsive up to the crash, ie. after an overflow you can almost always easily save, unlike before.
 
Status
Not open for further replies.
Back
Top