Set all pins to output mode

Sure you could do

int a;
for(a=0;a < 13;a++){
        pinMode(a, OUTPUT);
}

But is there a better way to setup all the pins to output?

BTW I am still waiting for an arduino but I am writing programs in VirtualBreadBoard.

You could do direct port manipulation.

The library should have a provision for this :P

But is there a better way to setup all the pins to output?

Your question is incomplete. None of us knows what "better" means to you.

it can be shorter

for(int a=0;a<13;) pinMode(a++,OUTPUT);

main difference: the var a doesn’t exist outside the for loop

better? who knows?

One of the first thing I checked last week when I discovered Arduino.

Can you go low level?

#include <avr/io.h>

void setup()
{
  DDRB = 0xFF ; // Port B outputs
}

void loop()
{
  PORTB = ~PORTB ;
  delay(500) ;
}

Yes!

And that sets all 14 pins? :D

And that sets all 14 pins?

No, just the pins associated with PORTB. If you look at the schematics of your board, you'll find out. For the Uno, PORTB controls pins 8 to 13 (Bit 0 to 5). Bits 6 and 7 don't exists, simply because PORTB is a 6 bits port.

int a;
for(a=0;a < 13;a++){
        pinMode(a, OUTPUT);
}

Maybe a little nit-picky, but wouldn’t this set all digital pins EXCEPT 13?

I guess I have to use that code. Still seems like there should be a cleaner solution :-/ @biocow: I was kind of being sloppy ;D

Still seems like there should be a cleaner solution

I don't think very many people want to set all 14 digital pins as output at one time. First, because most people don't use pins 0 and 1, since these are connected to the serial port. Second, most applications that have a lot of outputs have at least one input.

It only takes two commands to for all the pins you want on. Why should the library be cluttered with a special function just for you?

What about a function to set a range of pins? I am sure the function would not be "just for me" as I am sure other users would find it useful.

What about a function to set a range of pins?

There is a two line way of doing that. Why should there be a special function to do that in one line?

Additional functions bloat the library, resulting in bigger sketches for everybody, and more maintenance issues.

it can be shorter

for(int a=0;a<13;) pinMode(a++,OUTPUT);

main difference: the var a doesn’t exist outside the for loop

better? who knows?

It can be smaller than that too:

for(byte cnt=13;cnt!=0;pinMode(cnt--,OUTPUT));

Counting down is more code efficient because of how the assembly commands are. With the proper optimizations, having pinMode() inside the for loop control block shouldn’t be any faster, but with an inefficient compiler, it could make the difference of 1/4us or so.

Two things...

  1. I believe your example skips pin zero while the other examples include it.

  2. Your example generates slightly more code. On an AVR processor this generally indicates that the code will take longer to run.

Your example generates slightly more code. On an AVR processor this generally indicates that the code will take longer to run

That's a very sweeping generalisation - unwound loops typically result in more code (both source and object) but will almost inevitably take less time to run than the equivalent unwound loop.

Besides, always leave the optimisations to the compiler (until you absolutely have to).

Yep, I skipped 0 (that sounds really bad,) here is the corrected code:

for(char cnt=13;cnt>=0;pinMode(cnt--,OUTPUT));

As for the different code sizes, theoretically, mine should have produced smaller code if for no other reason than I used a byte variable instead of an int. For some reason however, using an int or even a char make the code 2 bytes smaller. I have no idea why that is, because unless the compiler is optimizing the int down to an 8-bit variable, byte should a couple lines less of code. And char and byte should be exactly the same. I'm going to try to dig up the assembly files for the programs to see if I can figure this out.

To AWOL, I agree mostly with you, except that there are some optimizations that compilers don't catch. Most of my programming experience has been with PIC16Fs. I took a look at the assembly instruction set for the Atmega chips, and I believe that the counting down to zero optimization doesn't apply to these chips. It has to with 16F PICs not having the BRANCH command set.