Minimum Build

Hello all,
I am looking for instructions on what the minimum build requirements are for a successful compile.
I came across these instructions several months ago and I thought that I had booked marked the site.
Guess what, now I can't find it. It was a rather neat tutoral. It started with the typical setup() loop()
compile showing how many bytes that compiled to and then it stripped out one item at a time showing
the resulting byte count. When it was done it was down to below 100 bytes. Little more than a few
header bytes and a return instruction.
Has anyone else seen this? Can you point me to it again?
Thank You !!! :slight_smile:

-Ray
:fearful:

void setup() { } 

void loop () { }

Thank you but that is NOT what I meant. That setup() loop() pulls in several libraries and other stuff that may now be needed for every project. I'm looking for the tutorial that breaks that down the the bares minimum bytes.

Regards,
-Ray

This got me curious and did some searching, I didn't find anything but this:

http://arduino.cc/forum/index.php/topic,129635.0.html

int main() {return 0;}

Is the smallest you can do with the IDE. It just loads the avr-gcc crt*.o start-up. Total is 176 byte with 1.0.4.

Some of crt*.o is the vector table.

Thanks everyone for taking some time on this. I still have not found what I saw a few months ago. The closest I have come to it is this:

http://bleaklow.com/2012/02/29/why_im_ditching_the_arduino_software_platform.html

So I am going to follow Allen down his rabbit hole. It seems to carry the least amount of baggage and it seems to avoid some problems
that are in line with where I'm headed in my little personal Arduino project.

Best Regards To All
-Ray

Ray,

I looked at Allen's sourceforge site. It is a curious collection of "bits and pieces".

I don't have any specific libraries for doing the equivalent of analogWrite, generally I just set up the timers by hand. Once you've done it a couple of times it's not that hard, and you get better control. I've put all the bits and pieces I've written on sourceforge, at ABAVR download | SourceForge.net

There are many problems with the Arduino software but it's not as bad as you suggest. I admit that I have rewritten some of it for my use.

Allen is just wrong in his analysis of Arduino system.

Allen claims this program takes 10k of flash.

#include "WString.h"
int main(void) {
    String bloat = "hello world";
    return 0;
}

/opt/avr-gcc/bin/avr-size build/test.elf
text data bss dec hex filename
10194 20 5 10219 27eb build/test.elf

Can that really be right? 10K for a one-line program? Unfortunately it is. Any mention of String pulls in the entirety of the class, as well as all the other avr-libc routines it references. So on a Duemilanove that only has 32k to start with, a third of the available memory is gone before you start.

Most of the "Bloat" is removed by the linker so the real size of the program is 1574 bytes.

Binary sketch size: 1,574 bytes (of a 32,256 byte maximum)

The String class uses dynamic memory so all the C++ creator overhead with malloc, free, and realloc is loaded. This overhead will not be loaded with other C++ classes.

Most of the things Allen claims to be bugs are not.

For example this analysis of HardwareSerial is wrong. The write routine works correctly, you can implement a queue between a producer and consumer without locks on AVR.

Oh dear. head and tail are declared as int, i.e. 16 bits, 2 bytes. They are accessed by both the write routine and the interrupt service routine that actually transmits the data yet there's no locking in the write routine so the accesses aren't atomic.

Arduino is a hobby system and many thousands of users are happy with it. I don't think Alan Burlison has anything to offer to the average Arduino user.

OK, I understand the concept of "included libraries" including other libraries that aren't called/used by the main program but get compiled to object code and that the final LINKER does not include that / those modules because there are no references to them in the main program. Allen may have forgotten that fact as I did till you reminded me of it.

My intent on starting this thread was / is two fold. One, too (is that the correct to??) discover how to have just the needed code included in the final executable and two, to be sure that there are no hidden delays / waits anywhere.

My main concern is having a pin go high but is missed because the cpu was in a "busy wait". My little understanding of the Arduino boards is that the pins are NOT latched when active and are free to go inactive (low) at will (follow the voltage).

Thanks for your analyst (sp?)

Regards,
-Ray

rfleisch,

Is this the blog you where looking for?
http://www.robopeak.net/blog/?p=131

rfleisch:
My intent on starting this thread was / is two fold. One, too (is that the correct to??) discover how to have just the needed code included in the final executable and two, to be sure that there are no hidden delays / waits anywhere.

I understand your concern, Ray, and I partially agree with it.

The size of the final executable is actually small, bacause the linker already does a very good job removing unused functions and the like. This avr-gcc is actually a great compiler.

If the size of the final binary is a problem, one solution to gain 2kb is to flash it to the Atmega using ICSP, thus overwriting the bootloader.

You have a point, however, when it comes to the slow manipulation of ports I/O. The digitaRead/Write calls are really slow, but we can choose not to use them in our sketches. We can do direct port manipulation without giving up everything else. The point, however, is deciding when to do it.

AlxDroidDev:
If the size of the final binary is a problem, one solution to gain 2kb is to flash it to the Atmega using ICSP, thus overwriting the bootloader.

Every board since the first uno has had a 512 byte bootloader, so you'd only save that much.

The main arduino 'overhead' code for a minimum build is from an init function that runs before the user setup function and that is to configure and start timer0 which is used by the arduino supplied timing function millis() and micros() functions.

Lefty

WizenedEE:

AlxDroidDev:
If the size of the final binary is a problem, one solution to gain 2kb is to flash it to the Atmega using ICSP, thus overwriting the bootloader.

Every board since the first uno has had a 512 byte bootloader, so you'd only save that much.

But then every current board is not a Uno board, the current mega board for example uses a much larger bootloader size.

Lefty

Were you looking for this:

It doesn't offer any advice on reducing the overhead; just analysis of where it goes...

That's not what I remember but that sure is a good break down of what is in a simple setup() ; loop() program.
Thanks for that link, I'll now spend the rest of the week studying it.

A big thank You to everyone who has taken some time from what I am sure is a busy day for these replies.

-Regards,
-Ray

:slight_smile: I FOUND IT

:slight_smile:

I guess that I need some better memory for myself :wink: That is exactly what I was reading several months ago, it just did not look familiar today.

Opps,

Thanks

-Ray