Help: Explaining Code

Hi, I'm new here. I am having problems reading this code, to understand what each function does as I do not have much experience with this computer programming. I hope to get an idea of this code as a base, to use it as a LED blinker to allow me to show that it can signal time.

The following code is suppose to light an LED after being switched on for 10 seconds. We are using an Atmega88 AVR Chip that will be programed.

Code:

---

// AVR IO memory space
#include <avr/io.h>

// Macro defn to select bit n, assuming 0 <= n <= 7
#define BIT(n) (1 << (n)) //what does this do, I am unfamiliar with this call

// Delay function
void delay (unsigned char time)
{
        unsigned char t1, t2;
        unsigned int count = 0;
        for (t1 = time; t1 > 0; --t1){ //this will be the timer countdown
                for (t2 = 255; t2 > 0; --t2){ //why do we count down from 255 here?
                        count += 1;
                }
        }
        return;
}

// Main function
int main (void)
{
        unsigned char LEDbit;
        DDRD = 0xFF; // set all PortD to output //I think this is the output of the AVR port that will be used to light the LED
        LEDbit = 0;
       
        while(1){        // forever looped
                LEDbit += 1;
                if (LEDbit > 7) LEDbit = 0;
                // turn on LED # by writing 0 to its MCU pin
                PORTD = ~BIT(LEDbit); //This is the function that I am getting confused, PORTD is probably an output variable from the io.h, but what does the ~BIT(LEDbit) do, and why the new for the LEDbit counter?
                // delay by (#) seconds
                delay(10);
        }
        return 0;
}

---

Thanks for the help, much appreciated

This

Quote:

---

#define BIT(n) (1 << (n))

---

was discussed less than a week ago - search forum

Quote:

---

//why do we count down from 255 here?

---

Ask the author - there is no real reason for this
Also busy wait is the last solution that should be applied to implement delay

Quote:

---

but what does the ~BIT(LEDbit) do

---

search bit-operations on forum or C-reference for details, it was explained very recently

the macro allows the programmer to shift the bits to the left (for the corresponding pin in this case.) so calling BIT(2) for example, shifts 00000001 two places to the right, 00000100.

The while loop basically just keeps shifting the bits left based on LEDbit, which goes up to 7 and is reset. the ~ is bitwise NOT which basically flips the values of the bit. BIT(2) = 00000100, ~BIT(2) = 11111011

EDIT: sorry didn't see the ~

Thanks for the help.

Let's say PORTD consist of 8 registers, which are all set to outputs. 0 (LED off), 1 (LED on). What the LEDbit does is just a counter for the register. As it increases, does it just flip the value of that bit, or all the registers?

ie, all set to outputs, all start at 0.

It seems like as the LEDbit increments, it just turns each light on? And then reloops and turns off each light (with 10 second interval delay between each action). Does my logic seem correct?

I notice the author of the code uses a nestedloop to get delay (probably due to the Microcontroller delay). I should look into using interrupts.

Thanks

Actually, there is a very good reason to count down from exactly 255, because the variable is a unsigned char, and 255 is the biggest value for unsigned char in all common hardware implementations (where a byte is 8 bits - there are hardware implementations with 9-bit chars, but that is VERY rare).

--
Mats

Quote:

---

Originally Posted by matsp

Actually, there is a very good reason to count down from exactly 255,

---

Really?
And what is the advantage over

Code:

---

for(unsigned char t=0;t<255;t++)

---

?

Ok, perhaps I should have expressed that as "there is a good reason to not use a value GREATER than 255".

As to why you use counting down instead of up - well, that's probably a completely arbitrary choice by the original author, but for some architectures, it generates shorter code, as comparing with zero doesn't require a compare instruction [just a branch on not zero after the decrement instruction]. This is often not an issue with modern compilers however, as they tend to reverse the counter in loops like that anyways - so counting up to 255 without using the variable inside the loop [or trivial use where the compiler can use a second register for the loop count] can be done as a count down loop.

[In fact we had this exact discussion here at work yesterday - why is this loop done backwards, and it seemed like the original author thought it would generate shorter code and save one clock cycle per loop, but the whole loop takes about 20ms per iteration, so saving 3ns per loop doesn't seem particularly meaningful].

--
Mats