How to get a little bit more FLASH room on Teensy 3.x

Status
Not open for further replies.
On my Mac, these are at:
/Applications/Arduino.app/Contents/Resources/Java/hardware/teensy/boards.txt
and
/Applications/Arduino.app/Contents/Resources/Java/pde.jar

With the Blink example, the original files have this size:
Binary sketch size: 12,688 bytes (of a 262,144 byte maximum)
Estimated memory use: 3,456 bytes (of a 65,536 byte maximum)


Swapping in the new ones gives:
Binary sketch size: 5,480 bytes (of a 262,144 byte maximum)
Estimated memory use: 1,612 bytes (of a 65,536 byte maximum)

In the process of doing this test, I (accidentally) ran with the pjrc version of pde.jar, but with xxxajk's boards.txt. This gave the best results:
Binary sketch size: 1,240 bytes (of a 262,144 byte maximum)
Estimated memory use: 28 bytes (of a 65,536 byte maximum),

but the code didn't upload :(

Also (when it didn't run), I tried to re-install teensyduino -- it wouldn't install when either of the modified boards.txt or pde.jar were in place.
 
Last edited:
In the process of doing this test, I (accidentally) ran with the pjrc version of pde.jar, but with xxxajk's boards.txt. This gave the best results:
Binary sketch size: 1,240 bytes (of a 262,144 byte maximum)
Estimated memory use: 28 bytes (of a 65,536 byte maximum),

but the code didn't upload :(

Also (when it didn't run), I tried to re-install teensyduino -- it wouldn't install when either of the modified boards.txt or pde.jar were in place.

Yup, that is because it is missing the all important core parts. :D
 
new pde.jar and boards.txt copied to my win 7 PC.
Installation directory was c:\Arduino
new boards.txt went to C:\Arduino\hardware\teensy
new pde.jar went to C:\Arduino\lib

May I sugest that one zip file be created containing both of the above files?
And that a new thread or or some such be made so others can readily find this good change?

Thank you guys.
 
new pde.jar and boards.txt copied to my win 7 PC.
Installation directory was c:\Arduino
new boards.txt went to C:\Arduino\hardware\teensy
new pde.jar went to C:\Arduino\lib
Did it work and give you smaller sizes?

May I sugest that one zip file be created containing both of the above files?
And that a new thread or or some such be made so others can readily find this good change?
Not worth doing. Paul will probabbly release this in the next version anyway.

Thank you guys.
You are quite welcome. :cool:
 
No fails. Same size reduction as reported earlier.

I'm using Visual Micro (freeware), their low cost debugger add-on, with free Atmel Visual Studio (MS Visual Studio for micros).
Splendid combo if you use Windows. A 60 second one click install of the Visual Micro plugin. Just works.

I just tried a small two-task RTOS (FreeRTOS) build for Teensy 3.0 with the above mash-up. Works.
FreeRTOS port for Teensyduino allows library calls to be made. FreeRTOS is an ordinary app with the addition of the software interrupt done by FreeRTOS to context switch.
I configured FreeRTOS to not use preemption in the scheduler, to simplify my apps. With this, each task must sleep or wait on a semaphore/queue or some such to yield to another task.
But then I don't have the issues that happen with preemption where 2+ tasks go for the same resource such as even Serial.print()
 
Last edited:
Ok following up I get the segfault with the toolchain installed by Teensyduino, gcc-arm-embedded doesn't have arm_cortexM4l_math.a

Need to spend some time on it but no time until tomorrow.

Did you ever get this sorted? I also get a segfault using the toolchain shipped with teensyduino on osx 10.9
 
If there was a way to also do this on Eclipse I'd be interested in that.

The upgraded stuff works happily no matter what IDE you have, even the regular Teensyduino stuff...
If you already have it all working in eclipse, this is simply an upgrade. If not, read on...

https://github.com/xxxajk/Arduino_Makefile_master should work happily with eclipse, it works just fine with NetBeans.
You will need to have GNU make at a minimum. GNU screen is used for monitoring, but optional. (Use what you like)
It is untested on Win, but is working on Linux and MacOS. (Kristen is the Mac guy that contribs Mac stuff...) I'm accepting patches and instructions for Win...
On Win you should be able to get things to work via Cygwin.

I do prefer NetBeans since it is (to me at least) more intuitive, and I found eclipse to be too clumsy, and too slow. :D
Yes, that's right, eclipse is slow. I got 10GB of RAM on a fast quadcore. :confused: Go figure.

***anti-editor-and-ide-flame statement***
The Entire point is "Use what you like, it is a Makefile."
GNU make does not care what tools you use to edit.
It is written as generically as possible, and you can extend and or modify it, barrow/steal stuff to suit your needs.
Use what ever IDE you like, or no IDE at all. Use what ever editor you like, even the one in the Arduino IDE (YUCK!).
 
but is working on Linux and MacOS. (Kristen is the Mac guy that contribs Mac stuff...)

Would love to here from someone getting this to work successfully on MacOS about what toolchain they are using since I and riotwing are both seeing segfaults. Specifically I see:

Code:
$ /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/arm-none-eabi-objdump -h -S build/clitest.elf | /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/arm-none-eabi/bin/arm-none-eabi-c++filt -t > build/clitest.lst
Segmentation fault: 11

Plan on digging into this myself tomorrow, will update if I figure out what's causing it.
 
Is there a chance to get gcc 4.8.x in one of the next versions ?

It creates smaller&faster code (according to a german avr-forum), too :)
 
Gcc 4.9 has branched and a release candidate is available, so I would expect 4.9.0 on/before July (when the Gnu Cauldren is and many of the developers will meet for face to face). After 4.9 is released, 4.8.3 is expected to be released.
 
Good. Hopefully the many bugs I have encountered will go away.
I'd use a newer chain (and I actually have for stuff I don't release) but this makes bugs difficult to figure out when something works for you and not some one else.
This is also one reason why it is good that Paul is slow to do tool chain updates-- We know the bugs, and the workarounds.
Some tools are harmless to update-- ld for example won't affect the compiler, nor would replacing gas. You could even use a little of two different compilers at different stages and end up with something that still reflects the known quirks, but produces smaller code, just by only using the optimizer in a newer version.

In any case I really cant wait for the fix for the annoying ARM array init. That to me is the most annoying of them all. However I don't believe manually initializing them really affects the actual size of the code generated all that much. What would be saved in this case would be RAM.

As far as the better optimization, that is simply an extra bonus, just as long as the optimization does not cause new quirks, which can happen, and has happened in the past.

I hope Paul will let me have a go at throwing some of my code at it, especially stuff I have not even released into the public yet.. This would be good since I do some very advanced stuff that can really put a strain on just about all the phases of the compiler.
 
I hope Paul will let me have a go at throwing some of my code at it, especially stuff I have not even released into the public yet.. This would be good since I do some very advanced stuff that can really put a strain on just about all the phases of the compiler.

I usually publish at least a couple release candidates. They're always posted to the announcements forum.
 
Hi all,

not sure if it's interesting for somebody, I followed Michael Meissner's suggestion to use -ffunction-sections -fdata-sections, and then pass --gc-sections to the linker.
An application with USB_Serial, some DES code and LED blinking dropped from:
text data bss dec hex filename
52372 1624 1796 55792 d9f0 main.elf
to:
text data bss dec hex filename
35636 1576 1528 38740 9754 main.elf

Not sure if there are some side effects from multiple ELF-sections, but it looks pretty nice.

Nikolai
 
The Arduino AVR setup uses -ffunction-sections, -fdata-sections, and the linker's --gc-sections options.

One place where you have to be careful is if you have a function or data that isn't referenced that you want in the image. For instance, when I'm debugging the GCC compiler, there are several functions that aren't called from other functions in the source (so they would be deleted by the above options), but are available to be called from within the debugger that pretty print the data structures. This isn't an issue with the Teensy, since it does not support the gdb debugger.
 
Last edited:
So I realize this is almost a year after the last post. I tried to copy over the boards.txt file and the pde.jar file and now the Arduino IDE will not open.

I have IDE 1.6.4 and 1.6.5 installed w/ Teensyduino for 1.6.4 on a Windows 7 box. Copied the pde and boards files into the appropriate folders for both 1.6.5 and 1.6.4, no dice. The IDE still bombs out immediately after the splash screen before actually loading the editor window. I have the originals saved so I can hopefully get it up and running again. I have a work project I am using the Teensy 3.0's RAM to store a data array so any space / performance I can glean is a boon.

I've got 3 locations for Arduino data:
C:\arduino-1.6.5\ (1.6.5 install location)
C:\Program Files\Arduino (1.6.4 install location)
C:\...\My Documents\Arduino (think this one was created when I added support for Sparkfun boards, no reference to Teensy in hardware folder and no lib folder)

Any suggestions would be extremely appreciated.

Cheers,

Emach
 
@Emach : should be safe to assume that these old fixes for what they were worth are part of the standard install at this time. Going back to those files now will remove all the evolution for other things since then, and would explain the IDE going offline when you drop them in today.
 
Defragster,

I have the Arduino IDE set to verbose for compiling and I can see a bunch of unused Teensy specific libraries being compiled. Is there an easy and reversible way to exclude those from compiling?

Thanks for the reply, going to try and fix my IDE w/ the original files.

Cheers,

Emach
 
Last edited:
You can always get a fresh copy of Arduino and run the Teensyduino installer on that fresh Arduino, to get back to a working installation.

On Windows, if you want more than 1 copy, get the ZIP file instead of the Arduino installer. You can extract the ZIP file anywhere, except do not extract it inside My Documents/Arduino... that's where YOUR files go, not Arduino itself. Before you run the Teensyduino installer, make sure you know *where* you extracted that ZIP file.

If you *really* want to fiddle with copying internal parts of Arduino files, starting with Arduino 1.6.0 you need both pde.jar & arduino-core.jar, and boards.txt & platform.txt. Versions 1.0.x used only pde.jar and boards.txt. If you neglect to copy arduino-core.jar and platform.txt on these newer Arduino versions, you'll end up with inconsistent installations.
 
Defragster,

I have the Arduino IDE set to verbose for compiling and I can see a bunch of unused Teensy specific libraries being compiled. Is there an easy and reversible way to exclude those from compiling?
Emach

If you scan this thread I think it was confirmed - the problem isn't from extra/unused compiled files, those should generally be ignored at LINK time:: i.e. no call then no code. If I got the gist right:: The problem addressed here was some intermediate '.p' file that once presented passed through the linker and into the resultant executable, used or not.

If you follow Paul's note and remove your 'busted' install - doing a ZIP extract is the best way to set up an Arduino installation on Windows - whether single or one of many. I know as I started here as the 1.6.x family exploded/vomited on the scene, and with it the betas&updates required for TeensyDuino when I was working on three different machines.
 
Status
Not open for further replies.
Back
Top