Teensyduino 1.58 Beta #1 (updated toolchain trial)

PaulStoffregen said:
Fixed
https://github.com/PaulStoffregen/USBHost_t36/commit/0c86f2cb3ecc645fe11fe63339dfc6247110537b

Using volatile prevents the compiler from optimizing reading the pointer outside of a loop if the Arduino sketch code checks the status like this: "while (!mydrive) { /* wait */ }". The compiler (usually) will inline this function, and without volatile it is free to just read the pointer once, since it's stored in memory and the compiler assumes memory doesn't just spontaneously change. But of course the USB host library runs on interrupts and things like this pointer do change.
Click to expand...

Thanks Paul, I more or less understand the usage of volatile...

But I guess the question is what level you should not trust that pointer? And more specifically similar pointers?

Like we have the same issue with:
Code: 
class USBHIDInput {
public:
	operator bool() { return (mydevice != nullptr); }
There are also several composite objects that have to implement their own which don't do this:
Like Joystick:
Code: 
class JoystickController : public USBDriver, public USBHIDInput, public BTHIDInput {
public:
...
	operator bool() { return (((device != nullptr) || (mydevice != nullptr || (btdevice != nullptr))) && connected_); }	// override as in both USBDriver and in USBHIDInput

And looking more at the actual one you fixed. Wondering why that one was signed out in this class?
Code: 
class USBFilesystem : public FS, public USBFSBase
{
public:
	USBFilesystem(USBHost &host) { init(); }
	USBFilesystem(USBHost *host) { init(); }

	// Manual way to associate a drive/partition to a Filesystem object
	bool begin(USBDrive *pDrive, bool setCwv = true, uint8_t part = 1);
	void end(bool update_list = true);
	void init();

	operator bool() {
		//Device_t *dev = *(Device_t * volatile *)&device;
		//return dev != nullptr;
		return device != nullptr;
	}
When the base class has:
Code: 
class USBFSBase {
public:
	operator bool() { return (mydevice != nullptr); }
	uint16_t idVendor() { return (mydevice != nullptr) ? mydevice->idVendor : 0; }
	uint16_t idProduct() { return (mydevice != nullptr) ? mydevice->idProduct : 0; }
	const uint8_t *manufacturer()
		{  return  ((mydevice == nullptr) || (mydevice->strbuf == nullptr)) ? nullptr : &mydevice->strbuf->buffer[mydevice->strbuf->iStrings[strbuf_t::STR_ID_MAN]]; }
	const uint8_t *product()
		{  return  ((mydevice == nullptr) || (mydevice->strbuf == nullptr)) ? nullptr : &mydevice->strbuf->buffer[mydevice->strbuf->iStrings[strbuf_t::STR_ID_PROD]]; }
	const uint8_t *serialNumber()
		{  return  ((mydevice == nullptr) || (mydevice->strbuf == nullptr)) ? nullptr : &mydevice->strbuf->buffer[mydevice->strbuf->iStrings[strbuf_t::STR_ID_SERIAL]]; }
So the base class is checking a different member variable and not looking at volatile, plus if we needed to override for this? what if instead of looping on the existence bool(), I loop
on idVendor... (would not do that but...)

I guess the question is, if you are needing to cast everywhere you are using that pointer, shouldn't that member variable pointer simply be defined that way?

Probably a subject for a different day...
 
PaulStoffregen said:
Probably simplest to just make the ctimebuf[16], mtimebuf[16] buffers 21 bytes, even though the extra bytes would only be used if the struct had invalid data.

Yeah, it's a waste of 10 bytes. But if something else went wrong and the struct has invalid data, it would prevent that issue from turning into a buffer overflow.
Click to expand...

Understood and agree in general. In the cases that I used the pragma to turn off the error, we are trying to output specific information that MTP expects in specific format.
ALso we are using breakTime() which I think sort of hopefully catches most cases of bad data. And hopefully Filesystem won't give us bad data for their dates and times.
 
@brtaylor

Not sure you saw the errors I was getting with the Ublox and Eigen libraries in msg #16 but you might want to check other ones as well with the new compiler.
 
defragster said:
Interesting but 'fix' was just taking "%d" to "%ld" when prior working 'int' became 'int32_t'.
> It is a valuable warning - at least when using a uint64_t type SIZE from FS file where without "%llu" give really bad numbers for reference.
Click to expand...

The point is to use type correct format specifiers for *printf and *scanf. Perhaps the next machine you build for will map int32_t into long, perhaps it will map it into int. The other alternative is to explicitly cast the values to int, long, etc.
 
One thing I was curious about with new toolchain, is if it helped with usages of maybe wanting the library USBHost_t36 to know for example if SD.h was included in the sketch:

SO suppose I add this to MTP_teensy.h
Code: 
#if defined(__has_include) && __has_include(<SD.h>)
#include <SD.h>
#endif

Now suppose my sketch looks like:
Code: 
#include <SD.h>
#include <MTP_Teensy.h>

#define CS_SD BUILTIN_SDCARD  // Works on T_3.6 and T_4.1
//#define CS_SD 10  // Works on SPI with this CS pin
void setup()
{
  // mandatory to begin the MTP session.
  MTP.begin();

  // Add SD Card
  SD.begin(CS_SD);
  MTP.addFilesystem(SD, "SD Card");
}

void loop() {
  MTP.loop();  //This is mandatory to be placed in the loop code.
}
The sketch builds without issue.

But if I change it to:
Code: 
#include <MTP_Teensy.h>
#include <SD.h>

#define CS_SD BUILTIN_SDCARD  // Works on T_3.6 and T_4.1
//#define CS_SD 10  // Works on SPI with this CS pin
void setup()
{
  // mandatory to begin the MTP session.
  MTP.begin();

  // Add SD Card
  SD.begin(CS_SD);
  MTP.addFilesystem(SD, "SD Card");
}

void loop() {
  MTP.loop();  //This is mandatory to be placed in the loop code.
}
The sketch fails to build.
Code: 
C:\Users\kurte\AppData\Local\Temp\.arduinoIDE-unsaved202287-19452-1y21nla.3hah\Example_3_simple_SD\Example_3_simple_SD.ino: In function 'void setup()':
C:\Users\kurte\AppData\Local\Temp\.arduinoIDE-unsaved202287-19452-1y21nla.3hah\Example_3_simple_SD\Example_3_simple_SD.ino:30:3: error: 'SD' was not declared in this scope; did you mean 'SS'?
   30 |   SD.begin(CS_SD);
      |   ^~
      |   SS
"C:\\Users\\kurte\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=158 -DARDUINO=10607 -DARDUINO_TEENSY41 -DF_CPU=600000000 -DUSB_MTPDISK_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\Users\\kurte\\AppData\\Local\\Temp\\arduino-sketch-94DF2CD68BE15FE986375A2566EC151E/pch" "-IC:\\Users\\kurte\\AppData\\Local\\Arduino15\\packages\\teensy\\hardware\\avr\\1.58.0-beta1\\cores\\teensy4" "-Ic:\\Users\\kurte\\Documents\\Arduino\\libraries\\MTP_Teensy\\src" "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino-sketch-94DF2CD68BE15FE986375A2566EC151E\\sketch\\Example_3_simple_SD.ino.cpp" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino-sketch-94DF2CD68BE15FE986375A2566EC151E\\sketch\\Example_3_simple_SD.ino.cpp.o"
C:\Users\kurte\AppData\Local\Temp\.arduinoIDE-unsaved202287-19452-1y21nla.3hah\Example_3_simple_SD\Example_3_simple_SD.ino:22:15: error: 'BUILTIN_SDCARD' was not declared in this scope
   22 | #define CS_SD BUILTIN_SDCARD  // Works on T_3.6 and T_4.1
      |               ^~~~~~~~~~~~~~
C:\Users\kurte\AppData\Local\Temp\.arduinoIDE-unsaved202287-19452-1y21nla.3hah\Example_3_simple_SD\Example_3_simple_SD.ino:30:12: note: in expansion of macro 'CS_SD'
   30 |   SD.begin(CS_SD);

Wondered if new Toolchain would help.... It did not. There is an issue with Arduino builder that uses the GCC compiler to generate a list of dependencies, that if you first ask if a file has been included, and it has not, and then you ask for it to include it, it does not register in the list of dependencies. And as such Arduino does not include the SD library into the search path...

From resolution on issue, I earlier raised with Arduino. They informed me that it is a GCC issue...
 
KurtE/mjs513/ ... others using TSET and IDE 2.0?

This is published TSET - it hooks into ARDUINO15 - and using it this way will end up pulling from IDE 2.0 install - even if the IDE 1.8.19 is running TD 1.57 - it will build with TD 1.58b1 updated tools:
Code: 
echo Building Sketch: %ino%
"%arduino%\arduino-builder" -verbose=1 -warnings=more -compile -logger=human -hardware "%arduino%\hardware" [U]-hardware "%LOCALAPPDATA%\Arduino15\packages"[/U] -tools "%arduino%\tools-builder" -tools "%arduino%\hardware\tools\avr" [U]-tools "%LOCALAPPDATA%\Arduino15\packages"[/U] -built-in-libraries "%arduino%\libraries" -libraries "%libs%" -fqbn=%fqbn% -build-path %temp1% -build-cache "%temp2%"  %ino%
GIVES:
Code: 
...
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_post_compile" -file=T4MemInfo.ino "-path=R:\\temp\\arduino_build_T4MemInfo.ino" "-tools=C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/" -board=TEENSY41
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/stdout_redirect" "R:\\temp\\arduino_build_T4MemInfo.ino/T4MemInfo.ino.sym" "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_T4MemInfo.ino/T4MemInfo.ino.elf"
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_size" "R:\\temp\\arduino_build_T4MemInfo.ino/T4MemInfo.ino.elf"
teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   [B]FLASH: code:38684, data:8088,[/B] headers:8520   free for files:8071172
teensy_size:    RAM1: variables:8992, code:[B]33760[/B], padding:31776   free for local variables:449760
teensy_size:    RAM2: variables:12384  free for malloc/new:511904
...[Finished in 28.0s]

If that is not desired for comparison: USE IDE 1.8.19 (?) instead of TSET Compile.cmd, or remove those refs when TeensyInstaller 1.57 is the installed version:
Code: 
echo Building Sketch: %ino%
"%arduino%\arduino-builder" -verbose=1 -warnings=more -compile -logger=human -hardware "%arduino%\hardware" -tools "%arduino%\tools-builder" -tools "%arduino%\hardware\tools\avr" -built-in-libraries "%arduino%\libraries" -libraries "%libs%" -fqbn=%fqbn% -build-path %temp1% -build-cache "%temp2%"  %ino%
GIVES:
Code: 
...
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/teensy_post_compile" -file=T4MemInfo.ino "-path=R:\\temp\\arduino_build_T4MemInfo.ino" "-tools=C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/" -board=TEENSY41
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/stdout_redirect" "R:\\temp\\arduino_build_T4MemInfo.ino/T4MemInfo.ino.sym" "C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_T4MemInfo.ino/T4MemInfo.ino.elf"
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/teensy_size" "R:\\temp\\arduino_build_T4MemInfo.ino/T4MemInfo.ino.elf"
teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   [B]FLASH: code:29844, data:8088[/B], headers:9168   free for files:8079364
teensy_size:    RAM1: variables:8704, code:[B]25064[/B], padding:7704   free for local variables:482816
teensy_size:    RAM2: variables:12384  free for malloc/new:511904
...[Finished in 24.4s]

Note: Code looks to be 25% larger?

<edit> results code4code - clean build on both - code size diff
TSET for TD 1.58b1 under Arduino15 tools:
Code: 
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_post_compile" -file=Code4Code.ino "-path=R:\\temp\\arduino_build_Code4Code.ino" "-tools=C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/" -board=TEENSY41
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/stdout_redirect" "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.sym" "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.elf"
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_size" "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.elf"
teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   FLASH: code:[B]1216784[/B], data:331272, headers:8420   free for files:6569988
teensy_size:    RAM1: variables:86880, code:[B]48552[/B], padding:16984   free for local variables:371872
teensy_size:    RAM2: variables:24736  free for malloc/new:499552
[Finished in 123.9s]

TSET edit for TD 1.57
Code: 
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/teensy_post_compile" -file=Code4Code.ino "-path=R:\\temp\\arduino_build_Code4Code.ino" "-tools=C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/" -board=TEENSY41
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/stdout_redirect" "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.sym" "C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.elf"
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/teensy_size" "R:\\temp\\arduino_build_Code4Code.ino/Code4Code.ino.elf"
teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   FLASH: code:[B]999672[/B], data:332296, headers:8444   free for files:6786052
teensy_size:    RAM1: variables:87200, code:[B]41528[/B], padding:24008   free for local variables:371552
teensy_size:    RAM2: variables:24736  free for malloc/new:499552
Waiting for user selection
[Finished in 104.9s]
 
Last edited:
Hi @defragster - Sorry I am a little scattered today... Lots of different things going on.

But are you saying you have a TSET that now uses the Arduino CLI? to do the build. If so that would be fun to play with.
I know wishful thinking ;)

Right now I am not doing very many builds using 1.8.19 or building within Sublime Text. Trying to see what things are fixed or not fixed in IDE2!

Like they updated to new release today.
 
KurtE said:
Hi @defragster - Sorry I am a little scattered today... Lots of different things going on.

But are you saying you have a TSET that now uses the Arduino CLI? to do the build.
...
Click to expand...

Noted earlier - before 1.58b1 that it appeared as though having Arduino15 in tools and hardware including the "%LOCALAPPDATA%\Arduino15" would have the CLI use the current installed IDE 2.0 install.

This was CONFIRMED as shown p#61 seeing: "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_size"

So, without the indicated edit {removing those added links} TSET CLI builds WILL be using the latest installed IDE 2.0.

ALSO NOTE: not tested - but that line for CLI build was taken from the {old} IDE 1.8.19 build console. So, it is quite possible that IDE 1.8.19 may defer as well - unless that is the CHANGE PAUL made some time back when separating IDE 1.x from 2.x builds?

Also: Not done a sketch using any library to see which install they pull from.

So just noting 'for better or worse' old style TSET builds without Compile.cmd edit WILL use some part of the IDE 2.x latest update from: %LOCALAPPDATA%\Arduino15

- and the new toolchain seems to have grown code by 20-25%, and at least from TSET in Sublime - the build take longer too.

Also: doesn't seem as though LTO options are present (at least not with same flag) in the TD1.58b1 to see if that builds reliable HEX and may get smaller.
> They are not populated in IDE 2.x menus
> this tested using TSET that can pick 'faster w/LTO' and it fails, unless those p#61 deletions of the Arduino15 links which then work as it uses prior toolchain.
 
Has anyone updated TeensyThreads yet? My local copy is cloned from github.com:ftrias/TeensyThreads.git. Maybe I should bring in a different branch or fork for 1.58-beta2? Or just edit the code and delay with conflicts later?
 
PaulStoffregen said:
Has anyone updated TeensyThreads yet? My local copy is cloned from github.com:ftrias/TeensyThreads.git. Maybe I should bring in a different branch or fork for 1.58-beta2? Or just edit the code and delay with conflicts later?
Click to expand...

I started to make changes but didn't issue a PR back to @ftrias. There was one warning I couldn't figure out how to fix or if the fixes I put in were the best. See msg 29

Changes are currently in my fork
https://github.com/mjs513/TeensyThreads
 
Probably best to do it like this, since context_pit_empty is only referenced in the #else after #ifdef __IMXRT1062__.

Code: 
#ifndef __IMXRT1062__
static void context_pit_empty() {}
#endif
 
PaulStoffregen said:
Probably best to do it like this, since context_pit_empty is only referenced in the #else after #ifdef __IMXRT1062__.

Code: 
#ifndef __IMXRT1062__
static void context_pit_empty() {}
#endif
Click to expand...

Fixed and tested. Just pushed the change to my fork.

EDIT: Just sent @ftrias a PR as well.
 
Paul (or others) have you looked at the addr2line issue: posted in a few different messages like:
https://forum.pjrc.com/threads/7104...olchain-trial)?p=312364&viewfull=1#post312364

addr2line (with other gibberish in name) from previous toolchains fail to understand format - no unexpected.

addr2line from this toolchain gives wrong information:

Code: 
C:\Users\kurte\AppData\Local\Temp\arduino-sketch-7858D9125BABC79477386166F029CF48>C:\Users\kurte\AppData\Local\Arduino15\packages\teensy\tools\teensy-compile\11.3.1-beta1\arm\bin\arm-none-eabi-addr2line.exe -e MouseKeyboardForward.ino.elf 0x26F0
c:\Users\kurte\Documents\Arduino\libraries\USBHost_T36/MassStorageDriver.cpp:889

As I mentioned I re-enabled the objdump in platform.txt (suggestion that we do that for this beta)

and looking for the address of the fault in it, gave me valid information.

EDIT: Just had another one, different sketch:
Code: 
C:\Users\kurte\AppData\Local\Temp\arduino-sketch-E3CDFA778F47585FDF08194635A9E9C9>addr2line -e keyboard_viewer.ino.elf 0x108E4
??:?
Code: 
000108c0 <strlen>:
   108c0:	f890 f000 	pld	[r0]
   108c4:	e96d 4502 	strd	r4, r5, [sp, #-8]!
   108c8:	f020 0107 	bic.w	r1, r0, #7
   108cc:	f06f 0c00 	mvn.w	ip, #0
   108d0:	f010 0407 	ands.w	r4, r0, #7
   108d4:	f891 f020 	pld	[r1, #32]
   108d8:	f040 8049 	bne.w	1096e <strlen+0xae>
   108dc:	f04f 0400 	mov.w	r4, #0
   108e0:	f06f 0007 	mvn.w	r0, #7
 [COLOR="#FF0000"]  108e4:	e9d1 2300 	ldrd	r2, r3, [r1][/COLOR]
   108e8:	f891 f040 	pld	[r1, #64]	; 0x40
   108ec:	f100 0008 	add.w	r0, r0, #8
 
Last edited:
Update to TSET notes on p#61 and p#63. Just built this for another thread - Audio building here without Error or indicated warning!
Changing the Indicated line(s) in generated Compile.cmd:
Code: 
[B][COLOR="#FF0000"]rem[/COLOR][/B]  "%arduino%\arduino-builder" -verbose=1 -warnings=more -compile -logger=human -hardware "%arduino%\hardware" -hardware "%[B]LOCALAPPDATA[/B]%\Arduino15\packages" -tools "%arduino%\tools-builder" -tools "%arduino%\hardware\tools\avr" -tools "%[B]LOCALAPPDATA[/B]%\Arduino15\packages" -built-in-libraries "%arduino%\libraries" -libraries "%libs%" -fqbn=%fqbn% -build-path %temp1% -build-cache "%temp2%"  %ino%

"%arduino%\arduino-builder" -verbose=1 -warnings=more -compile -logger=human -hardware "%arduino%\hardware" -tools "%arduino%\tools-builder" -tools "%arduino%\hardware\tools\avr" -built-in-libraries "%arduino%\libraries" -libraries "%libs%" -fqbn=%fqbn% -build-path %temp1% -build-cache "%temp2%"  %ino%

Does result in change to TOOLS between IDE 2.0 install (here D 1.58b1) AND ALSO Hardware libraries used for that build.
> as before the new 11.3.1 toolset grows the code - here build times seem ~unchanged doing clean builds.

Current TSET results with IDE 2 install of TD 1.58b1 for MemoryAndCpuUsage.ino - using TSET CMDLINE BUILDER:
Code: 
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_post_compile" -file=MemoryAndCpuUsage.ino "-path=R:\\temp\\arduino_build_MemoryAndCpuUsage.ino" "-tools=C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/" -board=TEENSY40
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/stdout_redirect" "R:\\temp\\arduino_build_MemoryAndCpuUsage.ino/MemoryAndCpuUsage.ino.sym" "C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-compile\\11.3.1-beta1/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_MemoryAndCpuUsage.ino/MemoryAndCpuUsage.ino.elf"
"C:\\Users\\Tim\\AppData\\Local\\Arduino15\\packages\\teensy\\tools\\teensy-tools\\1.58.0-beta1/teensy_size" "R:\\temp\\arduino_build_MemoryAndCpuUsage.ino/MemoryAndCpuUsage.ino.elf"
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   FLASH: code:59924, data:22664, headers:8544   free for files:1940484
teensy_size:    RAM1: variables:28928, code:57416, padding:8120   free for local variables:429824
teensy_size:    RAM2: variables:18112  free for malloc/new:506176
Multiple libraries were found for "SD.h"
 Used: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\SD
 Not used: C:\T_Drive\Arduino-1.8.19\libraries\SD
Using library Audio at version 1.3 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\Audio 
Using library SPI at version 1.0 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\SPI 
Using library SD at version 2.0.0 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\SD 
Using library SdFat at version 2.1.2 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\SdFat 
Using library SerialFlash at version 0.5 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\SerialFlash 
Using library Wire at version 1.0 in folder: C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.0-beta1\libraries\Wire 
[Finished in 64.9s]


Using edited builder line above for TSET results with IDE 1.8.19 install of TD 1.57 for MemoryAndCpuUsage.ino - using TSET CMDLINE BUILDER:
Code: 
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/teensy_post_compile" -file=MemoryAndCpuUsage.ino "-path=R:\\temp\\arduino_build_MemoryAndCpuUsage.ino" "-tools=C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/" -board=TEENSY40
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/stdout_redirect" "R:\\temp\\arduino_build_MemoryAndCpuUsage.ino/MemoryAndCpuUsage.ino.sym" "C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-objdump" -t -C "R:\\temp\\arduino_build_MemoryAndCpuUsage.ino/MemoryAndCpuUsage.ino.elf"
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/teensy_size" "R:\\temp\\arduino_build_MemoryAndCpuUsage.ino/MemoryAndCpuUsage.ino.elf"
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   FLASH: code:57500, data:23688, headers:8920   free for files:1941508
teensy_size:    RAM1: variables:28000, code:54920, padding:10616   free for local variables:430752
teensy_size:    RAM2: variables:18112  free for malloc/new:506176
Multiple libraries were found for "SD.h"
 Used: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SD
 Not used: C:\T_Drive\Arduino-1.8.19\libraries\SD
Using library Audio at version 1.3 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\Audio 
Using library SPI at version 1.0 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SPI 
Using library SD at version 2.0.0 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SD 
Using library SdFat at version 2.1.2 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SdFat 
Using library SerialFlash at version 0.5 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SerialFlash 
Using library Wire at version 1.0 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\Wire 
[Finished in 64.6s]

This is handy for compare testing using 'SublimeText' on windows versus either (PJRC supported) IDE.

Just confirmed the IDE 1.8.19 results in the SAME BUILD as TSET with edited Compile.cmd {I could update TSET add an option to alter that rather than hand edit each time}
> Also confirms IDE 1.8.19 TeensyInstaller is independant of IDE 2.0 installs as it uses the 1.8.19 Tools and Hardware from that install.
Code: 
"C:\\T_Drive\\arduino-1.8.19\\hardware\\teensy/../tools/teensy_size" "C:\\Users\\Tim\\AppData\\Local\\Temp\\arduino_build_540488/MemoryAndCpuUsage.ino.elf"
Memory Usage on Teensy 4.0:
[B]  FLASH: code:57500, data:23688, headers:8920   free for files:1941508
   RAM1: variables:28000, code:54920, padding:10616   free for local variables:430752
   RAM2: variables:18112  free for malloc/new:506176
[/B]Multiple libraries were found for "SD.h"
 Used: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\SD
 Not used: C:\T_Drive\arduino-1.8.19\libraries\SD
Using library Audio at version 1.3 in folder: C:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\Audio
 
shawn said:
What is “TSET”?
Click to expand...

{for Windows only} See: github.com/Defragster/Tset
It is a way to Command Line Execute an Arduino IDE build - Using Windows Batch files.

Capturing the 'builder' line Frank B reversed it to pass the fqbn and paths from a batch file. Tset is an extended version with a batch file to emulate the IDE BOARDS settings (to build the fqbn string) to adjust those attributes to a 'Compile.cmd' file that when run results in a HEX upload to a Teensy.

Using 'editor of choice' that can execute a batch file from within the editor. @KurtE pointed out SublimeText that I've adopted here, it can also work on Notepad++ ... but only for Windows.

In conjunction with TyCommander it provides a good/better alternative to the IDE for dealing with multiple online Teensy units both programming and Serial Monitor output as used here - especially using Dual or Triple USB Serial.
 
defragster said:
{for Windows only} See: github.com/Defragster/Tset
It is a way to Command Line Execute an Arduino IDE build - Using Windows Batch files.

Capturing the 'builder' line Frank B reversed it to pass the fqbn and paths from a batch file. Tset is an extended version with a batch file to emulate the IDE BOARDS settings (to build the fqbn string) to adjust those attributes to a 'Compile.cmd' file that when run results in a HEX upload to a Teensy.

Using 'editor of choice' that can execute a batch file from within the editor. @KurtE pointed out SublimeText that I've adopted here, it can also work on Notepad++ ... but only for Windows.

In conjunction with TyCommander it provides a good/better alternative to the IDE for dealing with multiple online Teensy units both programming and Serial Monitor output as used here - especially using Dual or Triple USB Serial.
Click to expand...

Sorry, I know that all of this is somewhat off topic, but I keep meaning to also try:
https://packagecontrol.io/packages/...ublime Text,board. ... 4 SETTINGS ... 5 TODO

On my previous machine I also had a Platform IO setup with Sublimetext (deviot)
https://github.com/platformio/platformio-docs/blob/develop/integration/ide/sublimetext

<edit>: This URL?: platformio/platformio-docs/blob/develop/integration/ide/sublimetext.rst

Which was sort of started off from STINO stuff we tried earlier.

Sorry, back to the normal interruptions.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top