Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: Why is my Blink program taking 11,748 bytes of flash memory?

  1. #1

    Why is my Blink program taking 11,748 bytes of flash memory?

    Hi all...noobie here...

    I'm using a Windows 7 64-bit computer. I just purchased two Teensy LC boards. I installed Arduino 1.6.12 and Teensyduino Beta 1.31. I loaded the default Blink sketch, compiled, and loaded to both boards. Then I was able to change the blink rate in the sketch, load both boards...and the blink rate changed according to plan.

    So everything is working.

    The thing that has me scratching my head is the huge amount of resources a simple 5-line blink program is consuming. The sketch uses 11,748 bytes (18%) of flash storage space...and global variables use 2,200 bytes(26%) of dynamic memory. These numbers can't be real...can they? The Bootloader code resides on a totally separate chip...doesn't it?

    Could these inflated numbers be due to "debug info" that may be included in the Teensyduino Beta Code?
    If this is the case, I will move back to Arduino 1.6.11 and Teensyduino 1.30.

    Which brings me to my next set if questions:
    In my Windows Control Panel...Programs and Features Section...I see a line where the Arduino Code was installed...thus can be uninstalled,
    But I see no line where the Teensyduino was installed.

    So I assume the Teensyduino installer is not a formal "windows program installer", but more of a file shifter.
    So where do all the Teensyduino files end up going?
    Will they be removed when Arduino is uninstalled...or is there more cleanup I have to do?

    Thanks for any info you can provide.

    PS. A sticky that covers all these "install nuances" would be awesome.

  2. #2
    There always is a lot of setup overhead to get a microprocessor up and running. You have to select clock sources, start internal PLLs, configure peripheral buses, configure watchdogs, and setup basic IO assignments.

    There are also many "behind the scenes" features and utilities that are included by default. These core functions are the basic building blocks that we then can use to easily hang more high level goodies on.

    What makes the Teensy environment so cool is all this preparatory work is done for you and you can just enjoy watching the LED Blink almost instantly. I started this game over 35 years ago and used to spend days getting a new micro configured enough to blink a LED. There is a lot of detail in the 1377 page K20 Sub-Family Reference Manual....

    A large portion of the flash and variable space you noted is related to the Serial USB functions that were complied and loaded by default along with your four line Blink code. If you change the Tools -> USB Type to NO USB then a four line Blink program goes to:

    Sketch uses 8,240 bytes (12%) of program storage space. Maximum is 63,488 bytes.
    Global variables use 748 bytes (9%) of dynamic memory, leaving 7,444 bytes for local variables. Maximum is 8,192 bytes.


    "So where do all the Teensyduino files end up going? "

    The Teensyduino Installer effectively "patches" the Arduino install to add the Teensy "on top of" the Arduino files. Look in your Arduino Install directory and notice the new Teensy subdirectory.


    you will see the new AVR directory with all of its support stuff

    Last edited by drmartin; 10-09-2016 at 06:40 AM.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Three major factors contribute to the bulky code size for a minimal program.

    #1: USB - While blinking your LED, Teensy is also implementing a complete USB stack which communicates with your PC. Arduino Uno & Mega have a separate chip which does this. On Teensy, all that code is built into your program. Also, Teensy's USB uses DMA to memory, rather than a FIFO with limited packet buffers within the USB port. USB performance is awesome even on Teensy LC, even when using libraries that add software latency, but it does require allocating part of the RAM for USB buffers.

    #2: Initialization - On AVR, the hardware mostly initializes itself to a full-power running mode. On newer chips, almost all hardware defaults to a low power state and requires significant initialization code. This gives you tremendous flexibility (if hacking the startup code) but it does come with a code size cost if you just want to get all the hardware initialized.

    #3: Serial ports - Teensyduino's Serial1, Serial2 and Serial3 have a known limitation where all their code is built into your program, even if you're not using them. Each has buffers in memory, and quite a bit of code for several extra features (like CTS/RTS flow control and RS485 control) which aren't present on most other boards. All that adds up to about 5K of code usage, for the 3 ports. Someday this will probably be fixed, but it's a really tough problem due to serialEvent and special code by the ARM fault handler, requiring a massive refactoring of this well-tested code.

    In addition, 32 bit ARM code is usually slightly larger than similar 8 bit AVR code, despite what ARM's marketing info might claim. Most of the code size comes from the fact that pointers are 32 bits, requiring initialization with 32 bit constants.
    Last edited by PaulStoffregen; 10-09-2016 at 07:00 AM.

  4. #4
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    anecdotal survey of size of blink
    Last edited by manitou; 10-09-2016 at 05:40 PM. Reason: forgot i had it on github

  5. #5


    Thanks drmartin, Paul, and manitou...

    I guess you're telling me that USB Stacks are being built and loaded regardless if they are actually being used by the Sketch code. And besides that...if you choose the "No USB" option, there's still a lot of initialization these ARM chips need in order to become fully operational.

    Also, I'm assuming that a "beta release" of Teensyduino does not have any effect on the Flash or RAM utilization. If the beta adds bloat...then I will go back one level. If not, I will stay put with these latest releases.

    I'm coming into this ARM world from the AVR 8-bit world. The ATUSB32U2 chip I was using essentially came up fully initialized. For the Blink Program the only two things I needed to do was to set to clock speed to 16MHz (I want full speed) and set the pre-scaler divider to zero.'s the minimal LED Blink program utilization numbers for the my custom made board using the ATUSB32U2 chip.

    Flash Memory = 198 bytes...SRAM = 0 bytes...(the results were the same for all compiler optimization settings).

    This is the Blink C-code for my specific LED Pin using Atmel Studio 6.2.1548

     * Blink.c
    #ifndef F_CPU
        #define F_CPU 16000000UL
    #define CPU_PRESCALE(n)	(CLKPR = 0x80, CLKPR = (n))
    #define LED_YELLOW_CONFIG	(DDRC  |=  (1<<4))
    #define LED_YELLOW_ON		(PORTC |=  (1<<4))
    #define LED_YELLOW_OFF		(PORTC &= ~(1<<4))
    #include <avr/io.h>
    #include <util/delay.h>
    int main(void)
    Actually, the overhead may turn out to be a godsend. My application needs to employ USB RAW HID. I spent countless hours making this work in both my ATUSB32U4 and ATUSB32U2 custom boards. Going through the "USB Enumeration House-of-Mirrors" is mind boggling. If a user accessible RAW HID Stack is already there...then...That's Great! All I want to worry about is Sends and Receives...and not all the low level stuff.

    I'm not going to ask anymore questions now. I have to go through a reading of the datasheet, and all the Tensyduino info I can get my hands on. Then I may return with more questions.

    Thanks again

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts