code size

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 ?

Does this link in a new bootloader as well ?

No.

But your code won't be 2k if you blink two LEDs

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.

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.

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

The blink example demonstrates how to use 3 very common functions

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

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.

"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 :wink:

"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.

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

ardnut:
It's the 1k of code to toggle an output put that shocked me not the number 3 :wink:

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.)

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.

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.

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.

... 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.

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.

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. :drooling_face:

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.

ardnut:
If I'm limited to circa 200us per sample I may be as well using a ...

An ADC conversion takes 104 uS, and you can do it asynchronously. That is, do other stuff in the meantime.

As for your original point, I am staggered that to install something like Windows Vista requires something like one Gigabyte (yes, I'm not joking) of RAM.

So 1 Gb for something that "does nothing". You are getting off lightly with 1084 bytes.

The thing about things like digitalWrite is that it can write to a pin defined by a variable. So straight away it needs a table of pins to port mappings. And per port, bits. But as the others have pointed out, once you have the basic libraries there (and you don't have to use them) the memory usage goes up slowly.

An ADC conversion takes 104 uS, and you can do it asynchronously. That is, do other stuff in the meantime.

I looked at the spec for the 328 and it said between 35 and 250us. If I'm working out how fast I can sample a obviously need to take the worst case figure, where did you get 104? Is that an empirical result?

What is the accuracy of the result when running async ? It does not even seem to be included in the spec. All figures are given with the rest of processing shut down. I doubt that they would have provided separate clocks and means to shut down the rest of the chip if it did not make a significant difference.

It makes sense , having the ADC on the same piece of silicon with all the digital circuitry must be a horrendously noisy environment.

Now the ADC is 10b with 2LSB of error in quiet mode. That's 9 bit accuracy ADC.

If I run async what am I going to get? If they don't even put it in the spec sheet, it seem fair to assume it ain't that good. That may be OK for "fun" projects but it will not give an accurate enough result for what I need.

I will have to see if I can work with 5-10 kSps but it's about on order of magnitude below what I had originally intended.

Could you clarify the 104us ? Thanks.

ardnut:
If I run async what am I going to get?

I don't know anything about the accuracy of ADCs, but the accuracy of running it async is the same as running it with the analogRead function, since analogRead doesn't sleep the chip. It just goes into a busy wait.

ardnut:
If I'm working out how fast I can sample a obviously need to take the worst case figure, where did you get 104?

13/125000*1000000 ...13 clock cycles / 125000 clock cycles per second * 1000000 microseconds per second.

Is that an empirical result?

No.

What is the accuracy of the result when running async ?

The same as running synchronously. There is not a special asynchronous converter.

I doubt that they would have provided separate clocks and means to shut down the rest of the chip if it did not make a significant difference.

The point is to reduce the effect of noise not increase the accuracy.

Now the ADC is 10b with 2LSB of error in quiet mode. That's 9 bit accuracy ADC. If I run async what am I going to get?

The same.

13/125000*1000000 ...13 clock cycles / 125000 clock cycles per second * 1000000 microseconds per second.

So why does the atmel spec sheet say 35 to 250 us, are you saying they are incorrect?

For the rest of you comments try to understand the difference between the terms resolution and accuracy and reply again to my question.