Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Why the arduino generated hex is too large even for a hello workd led blink?

Status
Not open for further replies.
vinodstanur

vinodstanur

Advanced Member level 3
Joined
Oct 31, 2009
Messages
751
Helped
114
Reputation
234
Reaction score
114
Trophy points
1,333
Location
Kerala (INDIA)
Activity points
7,054
I am simply trying to compile an led blinking code using arduino IDE in linux. But why the hex code is too large? Can't we give any size optimization? Any way, I wan't to see the disassembled view of the hex, but I don't know the location of the hex file generated. :roll:
 

Hiya,
How big is the hex file being generated? I doubt a program like that would need size optimization. Does your IDE not have an option to allow you to see the hez file generated?

/Pheetuz
 

this is the code, as seen in the example list..

Code: 
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */

void setup() {                
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(13, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

It takes 1010 bytes out of 30KB of flash...
 

Ok, well I am guessing that there is other code being loaded into your uC other than just what you have written there, for starters there will be a section of code that goes through and sets/clears all the RAM when the device resets, also all the functions that you are calling are going to have program memory associated with them. If they are library functions then that library (or at least parts of it) will have to be loaded into the uC so that they can work.
To prove it to yourself that there is other stuff than just what is written above, why don't you double the amount of code that you compile and put into program memory, say have two loops instead of one doing the similar things, the size of the hex file wont double as the libraries and what not don't need writing to program memory twice.

Hope that helps.

/Pheetuz
 
That is a nice idea..:) I will try it..

But any way to see the hex? I can't find where it is generated...

---------- Post added at 20:27 ---------- Previous post was at 20:07 ----------

Okay,.. I tried to double the loop... But the increment is less...
But still compared to normal avr-gcc generated hex, this is very large...

Because , when I am using digitalWrite(13, HIGH); for the first time, may be due to the function requirement, it is taking 150 bytes of flash!,,
Also, for delay(1000) for first time, it is taking 162 bytes of flash! Any way, I was using normal C programming for AVR , using the AVR-GCC. That is generating hex of total size of only 150 bytes for the entire LED blinking...:)

Dont know why, I can't see any optiimization options in the arduino IDE...

---------- Post added at 20:30 ---------- Previous post was at 20:27 ----------

Any way, I will read back the hex from chip and try to see it disassembled...
 

It does seem slightly odd that you cant see the hex file ... It should be exported to your output directory, where-ever that may be set up to be, try have a look in your preferences menu for path locations and see if you can change the output directory to somewhere more easily findable.

Hope this helps.
/Pheetuz
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top