Teensyduino 1.54 Beta #6

Status
Not open for further replies.
I posted a thread in the audio forums, but since it concerns 1.54 beta 6 and the new integration with SDFat, I'm linking to it here.
The 5 second version is that calling SDCard.read() in SDIO mode with T4.1's built-in card seems to cause audio glitches, even if the data read is not used for audio. If this is a known issue or a limitation of the hardware, please disregard!

Thanks,
-J
 
PaulStoffregen said:
Here is the elf parsing code.

https://github.com/PaulStoffregen/teensy_size

Want the final result to be compact in the non-verbose mode, probably 1 line per memory region shown on the product page (so 3 lines for Teensy 4.0, 4 lines for Teensy 4.1). Exact format to be determined....
Click to expand...

As said a few posts later, I don't think we can simply replace the size-tool. The builder prints a defined text and gets its data by using the regexs on the output.
So we need an extra tool - but then, we don't need to parse the elf-file. There is one minor disadvantage: The "used libraries" text is printed after our size-output.
But maybe that's even better...?
 
Frank B said:
As said a few posts later, I don't think we can simply replace the size-tool. The builder prints a defined text and gets its data by using the regexs on the output.
Click to expand...

I'm kinda hoping for a replacement. Committed some code on github towards that goal.
 
That would have misleading information, too - it would print only one value for "RAM" :-(
That would be not much better than that we have now?!?
 
The code on github right now prints this, for the LadderFilter example compiled for Teensy 4.1.

Code: 
 FLASH: code:59452, data:6152, headers:7212   free for files:8053648
  RAM1: code:65536, variables:21184   free for local variables:437568
  RAM2: variables:15520   free for malloc/new:508768
 
It prints that :
Code: 
Der Sketch verwendet 0 Bytes (0%) des Programmspeicherplatzes. Das Maximum sind 8126464 Bytes.
Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers, 524288 Bytes für lokale Variablen verbleiben. Das Maximum sind 524288 Bytes.
Do I have to modify the regexs?

I removed "-A" from the commandline.

Or I have misunderstood "replacement" ....?? Likely!!
So, you use a "receipe", right?

Windows-exe:
 
Frank B said:
I removed "-A" from the commandline.
Click to expand...

Plan is not using builder's regex stuff.

So add this to platform.txt

Code: 
recipe.hooks.postbuild.4.pattern="{compiler.path}teensy_size" "{build.path}/{build.project_name}.elf"

and delete the "upload.maximum_size" and "upload.maximum_data_size" entries for Teensy 4.x from boards.txt.

Yes, it will print size before the library usage info. I'm ok with that.




defragster said:
Not sure what 'text_csf' / headers is telling me?
Click to expand...

The first 4140 bytes are headers needed by NXP's ROM, and the last 3072 bytes are a placeholder for a digital signature and public key to someday be used when/if we support encryption & authentication.
 
@FrankB - thanks for the EXE!

LFSIntegrity shows this when added to TSET cmdline build - when using EXTMEM char buf[8*1024*1024] RAM LFS Media:
Code: 
 FLASH: code:86092, data:10160, headers:7212   free for files:8023000
  RAM1: code:98304, variables:21312   free for local variables:404672
  RAM2: variables:16576   free for malloc/new:507712
[B]EXTRAM: variables:8388608[/B]

And without use of Extram for LFS Media of SPI:
Code: 
 FLASH: code:85916, data:10160, headers:7212   free for files:8023176
  RAM1: code:98304, variables:21312   free for local variables:404672
  RAM2: variables:16576   free for malloc/new:507712

prior output from imxrt_size.exe::
Code: 
RAM1:  22.81% of 512 kB used.
   Code (ITCM, 32 kB Blocks):   76.48 kB
   Variables (DTCM):            20.81 kB
   Available for Variables:    395.19 kB

RAM2:   3.16% of 512 kB used.
   Variables (DMAMEM):          16.19 kB
   Available for Heap:         495.81 kB

EXTMEM: not used.

FLASH:   1.27% of 7936 kB used.
   Code and Constants:         100.87 kB

And output from build system:
Code: 
Memory region         Used Size  Region Size  %age Used
            ITCM:         96 KB       512 KB     18.75%
            DTCM:       21312 B       512 KB      4.06%
             RAM:       16576 B       512 KB      3.16%
           FLASH:      103292 B      7936 KB      1.27%
            ERAM:          0 GB        16 MB      0.00%
 
PaulStoffregen said:
The first 4140 bytes are headers needed by NXP's ROM, and the last 3072 bytes are a placeholder for a digital signature and public key to someday be used when/if we support encryption & authentication.
Click to expand...

Good to know - so that is (current) 'fixed' MCU overhead - not something user code will affect - but takes space on the FLASH.
 
I'm going to edit the linker scripts. Now that we can print more detailed info, having too much stuff lumped together in the .text.progmem segment means we get inaccurate info.

If you grab newer versions of teensy_size from github, make sure you also update the core library linker scripts to match.
 
PaulStoffregen said:
Minor problem... looks like arduino builder discards all the stdout printing in non-verbose mode. :(
Click to expand...

Well everyone should use Verbose mode. For those using non verbose wasn't expecting this detail to be ejected. But if the normal output gets clipped then that won't show for non-verbose ... Opps

Though making it warning output would give it cool colors to stand out :)
 
You can patch it to always use verbose mode!
Btw, the build of teensy size showed a minor warning with -Wall - not important.
Good night... zzzzzz
 
I changed teensy_size to print to stderr and prefix each line with "teensy_size:". This causes the size report to be visible in both verbose and non-verbose mode. But Arduino shows it in alarming red color.

I'm going to put a small patch in the Java code to look for lines on stderr which begin with "teensy_size:" and print them in normal white text. Not the cleanest approach, but the last thing I want to do is jump into the arduino-builder & arduino-cli code.
 
Still looks good.

this shows here? Maybe just a local issue - but %lld fixes it.
Code: 
teensy_size.c:54:43: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'size_t' {aka 'long long unsigned int'} [-Wformat=]
  if (!filedata) die("unable to allocate %ld bytes\n", filesize);
                                         ~~^           ~~~~~~~~
                                         %I64d

Prints normal white in a dos box :)

Using in tset cmdline - .ld files updated:
Code: 
teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   FLASH: code:85344, data:10904, headers:7212   free for files:8023004
teensy_size:    RAM1: code:98304, variables:21312   free for local variables:404672
teensy_size:    RAM2: variables:16576  free for malloc/new:507712
teensy_size:  EXTRAM: variables:8388608
 
And for mtp-test - looks good?:
Code: 
teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   FLASH: code:140560, data:13176, headers:7212   free for files:7965516
teensy_size:    RAM1: code:163840, variables:37696   free for local variables:322752
teensy_size:    RAM2: variables:16576  free for malloc/new:507712

Build output:
Code: 
Memory region         Used Size  Region Size  %age Used
            ITCM:      132812 B       512 KB     25.33%
            DTCM:       37696 B       512 KB      7.19%
             RAM:       16576 B       512 KB      3.16%
           FLASH:      160956 B      7936 KB      1.98%
 
Looking good, I will have to try it out.

Wondering, In my size program I put check in for in your case free for local variables if it <=0 the program returns an error status

don't see it in this code base. I found it helped when people for example have large tables or the like and use up all of the ram1
 
KurtE said:
Wondering, In my size program I put check in for in your case free for local variables if it <=0 the program returns an error status

don't see it in this code base. I found it helped when people for example have large tables or the like and use up all of the ram1
Click to expand...

Yes, a check for not enough RAM1 left for a reasonable size stack is a good idea. If you feel like doing this, please add it and send a pull request.

To show an error in red text, just print to stderr without the "teensy_size: " prefix. I believe calling exit(1) should cause Arduino to terminate the build as an error, but I haven't tested.

Here are the JAR files to put into {Arduino}/lib if you want to see the results displayed with the latest Java patches.
 

Attachments

  • arduino-core.zip
    1.6 MB · Views: 152
  • pde.zip
    426.2 KB · Views: 138
Status
Not open for further replies.
Back
Top