project of arduino

I am surprised we have not had comments regarding what we just did, Im sure there are plenty of new comers that are just shaking their head

But its always fun to just mess about with code for just fun. Anyways it has been a while since I've played with Arduino's compiler but I've just had a quick 10 min play while waiting for something else to finish.

While the first delay(1000); adds 190 bytes to the program every other delay(1000); only adds 12 bytes where each _delay_ms(1000); adds 18 bytes to the program so depending on how many delays you have in your program you might find its more efficient to use the Arduino delay(); over the AVR Libc _delay_ms(); A quick of the top of my head calculation would put that number around the 30 mark.

void setup() {  
DDRB = DDRB | B00100000; // set pin 13 to output    
} 
void loop() { 
  PORTB = PORTB ^ B00100000;
  delay(1000);
}

Binary sketch size: 666 bytes (of a 32256 byte maximum, 2.06 percent).

void setup() {  
DDRB = DDRB | B00100000; // set pin 13 to output    
} 
void loop() { 
  PORTB = PORTB ^ B00100000;
  delay(1000);
  delay(1000);
}

Binary sketch size: 678 bytes (of a 32256 byte maximum, 2.10 percent).

void setup() {  
DDRB = DDRB | B00100000; // set pin 13 to output    
} 
void loop() { 
  PORTB = PORTB ^ B00100000;
  delay(1000);
  delay(1000);
  delay(1000);
}

Binary sketch size: 690 bytes (of a 32256 byte maximum, 2.14 percent).

But its always fun to just mess about with code for just fun. Anyways it has been a while since I've played with Arduino's compiler but I've just had a quick 10 min play while waiting for something else to finish.

While the first delay(1000); adds 190 bytes to the program every other delay(1000); only adds 12 bytes where each _delay_ms(1000); adds 18 bytes to the program so depending on how many delays you have in your program you might find its more efficient to use the Arduino delay(); over the AVR Libc _delay_ms(); A quick of the top of my head calculation would put that number around the 30 mark.

void setup() {  
DDRB = DDRB | B00100000; // set pin 13 to output    
} 
void loop() { 
  PORTB = PORTB ^ B00100000;
  delay(1000);
}

Binary sketch size: 666 bytes (of a 32256 byte maximum, 2.06 percent).

void setup() {  
DDRB = DDRB | B00100000; // set pin 13 to output    
} 
void loop() { 
  PORTB = PORTB ^ B00100000;
  delay(1000);
  delay(1000);
}

Binary sketch size: 678 bytes (of a 32256 byte maximum, 2.10 percent).

void setup() {  
DDRB = DDRB | B00100000; // set pin 13 to output    
} 
void loop() { 
  PORTB = PORTB ^ B00100000;
  delay(1000);
  delay(1000);
  delay(1000);
}

Binary sketch size: 690 bytes (of a 32256 byte maximum, 2.14 percent).

By easy, I did not mean short. Short helps, but sensible, easy to read code is just as important. Binary sketches are a little to difficult for a first project. When I made that post I didn't mean it as a challenge, but it's nice to see that you can do so much to such a simple program.

Yeah we got a little carried away with just messing around with code. Using digitalWrite(); is a lot simpler as the Arduino core handles all the bit handling and pin addressing for you. Sure on the ATMega328/168 DDRB = DDRB | B00100000; will set Arduino Pin 13 as an output but the Arduino is not just based around that ATMega. If you were using the Leonardo which is based around the ATMega32U4 pin 13 is actually C7 so if you wanted the same blink program running on the Leonardo you would have to change the code to:-

void setup() {     
DDRC = DDRC | B10000000; // set pin 13 to output       
}    
void loop() {    
  PORTC = PORTC ^ B10000000;  
  _delay_ms(1000);
}

Which isn't friendly to newcomers. digitalWrite(); gets rid of the headache and just handles all that for you.

That is an interesting observation, I would have expected the low level call to be better in all cases or certainly no worse after the first higher level call

I agree with you there, and you right, we love to make challenges at the drop of a hat, can be fun. and I do get you when your referring to short not being the goal, we just could not resist

this level of coding is far from simple, coding this way requires a much deeper understanding of the underlying hardware down to registry names and bit patters, not to mention the boolean algebra

Where this kind of coding becomes VERY useful is in tight timing situations

try this

write a loop using only digital write and turn on and off an output pin as fast as you can (So no delay function call), run it on your ATMEGA328 based Arduino (UNO for example)

measure the frequency of that, yes it will be cpu dependent but were doing a relative measure here so it is not a problem

now (If you have one) run it on an ATMEGA2560 and measure the frequency

both boards run at the same speed but you will find the mega is significantly lower frequency

now write the code in the way we have above and run on both boards, they will be almost identical

Why, well the ATMEGA has much more IO and the base arduino runtime that allows people to code the "Regular" way performs significant checks and mappings before it allows your code anywhere near the hardware

When you code the "Fancy" way, you as the programmer take on that responsibility. You can actually look at the code for the digital write and read if you want, all the source is there in the arduino IDE library files

Code version A

void setup() {     
pinMode(13, OUTPUT);           
}    
void loop() {    
     digitalWrite(13,!digitalRead(13));       
}

UNO = 58.785Khz

MEGA = 36.91Khz

Code version B

void setup() {    
DDRB = DDRB | B00100000; // set pin 13 to output      
}   
void loop() {   
  PORTB = PORTB ^ B00100000;    
}

Note the bits are slightly different on the mega, this library now maps PB5 to output D11 (PB7 is the new D13), either move your measurement tool or change the code

UNO = 497.87Khz

MEGA = 467.9Khz

WOW, what a difference, so even a new comer can see that if you need a fast output change, you have to resort to different coding, the best you can get if you don't is 58Khz (Assuming your not doing other code as well), there are hardware timers that of course can do better but this is to demonstrate a point of code overhead. So with a different coding technique your about 10 times faster (In this example, mileage will vary)

Peter

But you can get even smaller than _delay_ms(); and pretty efficient for the simple tests we are doing

void setup() {     
DDRB = DDRB | B00100000; // set pin 13 to output       
}    
void loop() {    
  PORTB = PORTB ^ B00100000;  
  delnms(1000);   
}  

void delnms(unsigned int n){ 
//delay n ms 
unsigned int x;
  while(n--){ 
    x=2600;       //empirically determined fudge factor 16mhz
    while(x--); 
  } 
}

Binary sketch size: 476 bytes (of a 32256 byte maximum, 1.48 percent).

Source: View topic - AVR Delay Functions :: AVR Freaks

void setup() {     
DDRB = DDRB | B00100000; // set pin 13 to output       
}    
void loop() {    
  PORTB = PORTB ^ B00100000;  
  delnms(1000);   
  delnms(500);   
  delnms(1000);   
}  

void delnms(unsigned int n){ 
//delay n ms 
unsigned int x;
  while(n--){ 
    x=2600;       //empirically determined fudge factor 16mhz
    while(x--); 
  } 
}

Binary sketch size: 476 bytes (of a 32256 byte maximum, 1.48 percent).

Yup even with more calls to the delay and even different delays didn't increase the compile size, but using this method can be a bit finicky. For example interrupts during the delay will cause the delay to increase in length.