Go Down

Topic: code size (Read 3135 times) previous topic - next topic

ardnut

I just compiled the blink example to test arduino and got the following:
Binary sketch size: 1,084 bytes (of a 14,336 byte maximum)

over 1k to blink a LED ?!

Does this link in a new bootloader as well ?



AWOL

Quote
Does this link in a new bootloader as well ?

No.

But your code won't be 2k if you blink two LEDs
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

James C4S

The blink example demonstrates how to use 3 very common functions, used in nearly every program.  It wasn't designed for compact size.

If you used direct port manipulation and possible millis() instead of delay(), it would be much smaller.  However, only AVR intermediates and experts would understand it.
Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com

ardnut

So that example is pulling in  a whole bunch of libraries just to toggle one output line.

Bareminimum builds to 466 and does "nothing".

Are there some examples the show a more direct approach?

thx.

PaulS

Quote
So that example is pulling in  a whole bunch of libraries just to toggle one output line.

Quote
The blink example demonstrates how to use 3 very common functions

If you consider 3 "a whole bunch", then, yes.

AWOL

#5
Jul 09, 2012, 04:24 pm Last Edit: Jul 09, 2012, 04:32 pm by AWOL Reason: 1
Quote
Bareminimum builds to 466 and does "nothing".

I wouldn't say that - have you looked at the source of "init()" ?
Plus all that handy-dandy stuff C does before "main()" runs.

If you're really keen on going off-piste, try AVRfreaks.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

ardnut

"If you consider 3 "a whole bunch", then, yes."

The number of libraries is not the question, it's the size.

It's the 1k of code  to toggle an output put that shocked me not the number 3 ;)


"If you're really keen on going off-piste, try AVRfreaks. "

I was not realising what was on/off piste. My experience of this sort of restricted hardware is the need to keep things small and tight I'm still getting a feeling for what arduino is all about and what its aims are.

Maybe it's about providing a kind of visual basic of the uP world.

Maybe 'freaks is more in line with what I need to work with.

Thanks for the comments.

AWOL

With direct port manipulation, you can certainly get the "pinMode" and "digitalWrite" overheads down, but then your code wouldn't be portable from, say, Uno to Mega.
The delay is a little more problematic to write out explicitly, but you've still got some C overhead.

Like I said, it doesn't cost another 1K to blink another LED
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

James C4S


It's the 1k of code  to toggle an output put that shocked me not the number 3 ;)

The Arduino functions are hardly the most efficient method to perform the end-actions they perform.  However, they make a trade off between connivence and efficiency.  They are efficient at being convenient.  As illustrated by the Blink example.

Very few people post complaining they have run out of code space.  And the ones that do generally have massive static data structures stored in PROGMEM, not because of their actual code.

I don't have an Arduino to test, but not using the Arduino functions this example is 600 bytes.  (Someone else will have to test / correct the code.)

Code: [Select]

void setup() {                 
  DDRB = DDRB | 0x20;  // set pin 13 to output
}

unsigned long currentMillis = 0;
unsigned long previousMillis=0;

void loop() {
  currentMillis = millis();
 
  if (currentMillis - previousMillis > 1000) {
    previousMillis = currentMillis;
   
    if (PORTB & 0x20)
      PORTB = PORTB & 0xCF; // turn led off
    else
      PORTB = PORTB & 0xFF;  // turn led on
  }
}


So it took me 15 minutes or so to save 200 bytes.  Plus because I don't have a lot of my normal resources with me, I am not sure I did all of the bitmath correctly.
Capacitor Expert By Day, Enginerd by night.  ||  Personal Blog: www.baldengineer.com  || Electronics Tutorials for Beginners:  www.addohms.com

ardnut

Thanks, that's the kind of code I was expecting to be working with.

AWOL's point that the libs provide a level of hardware abstraction could be big time saver further down the line.


AWOL

Quote
hanks, that's the kind of code I was expecting to be working with.

..and you're still relying on the support of the Arduino's "init()" to setup the timer and interrupt that allows "millis()" to provide you with timing.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

ardnut

... which is still costing the 466 bytes.

I had expected to see the led example with interrupts and timers and use about 50 bytes of code. But obviously having those sort of libraries available opens up access to a much wider public, which I guess is one of the key aims of Arduino.

There's also the question of speed and latency, though the ADC conversion time will probably outweigh all other considerations there. The sort of figures I have seen on AVR are on a par with realtime linux. If I'm limited to circa 200us per sample I may be as well using a Rasp (if they ever manage to take orders for them). There I would have all the libraries and RAM I want on much faster hardware.



PaulS

Quote
There I would have all the libraries and RAM I want on much faster hardware.

The first part of that statement may not necessarily be true. The faster hardware that does more stuff per instruction does not necessarily translate into faster response times, either.

ardnut

Quote
faster hardware that does more stuff per instruction does not necessarily translate into faster response times, either.


exactly, that's why I'm looking at atmega , I have an ARM SBC with an ADC chip that takes about 6us per sample but even RT linux has latencies around 200us. That is too slow and meant I'd have to do dedicated external ADC cct with buffered IO.

So I thought about atmel, however, the ADC is so slow it looks like I'm back to square one.  :smiley-fat:


cyclegadget


IMHO, currently the LeafLabs Maple is the next closest thing to Arduino but, it has an Arm chip and much higher speeds. Some of the Arduino libraries work with Maple. If the Arduino Due arrives, it would be the next best thing.
Good links: Eagle tutorial= http://www.youtube.com/playlist?list=PLDE1858BD83D19C70
General Arduion tutorials = http://tronixstuff.wordpress.com
http://www.gammon.com.au/forum/bbshowpost.php?bbtopic_id=123

Go Up