Hi All,

Just received my kit and was trying out the initialload.c program. Since I have a Java dev background and used to IDEs, I searched for an IDE and came across AVR Studio. This IDE looks pretty good with debugging and simulator capabilities. I was able to compile and debug initialload.c without loading the program onto the chip. I have a few newbie questions and would really appreciate the answers.

1) I did not find any cscope like tool in this IDE or in WinAVR - does anyone know if we have such a tool with WinAVR ?

2) the idiom used to intialize the registers DDRC |= (1<<PC4); Is this a programming practice ? can't we just do with the assignment DDRC = 0x10; Are we guaranteed that DDRC does not contain any previous value ?

3) There is no concept of Dynamic linking correct ? So if everything is linked statically one shld just link in the right number of libraries correct ? For example when compiling initiaload I need dealy.o and lcd.o but can avoid uart.o (from libnerdkits)

Thanks.

Hi jaijeetc, welcome to the group.

I really cannot help you except to say [search the Nerdkits forum](http://www.nerdkits.com/search/?q=DDRC%20|=%20(1%3C%3CPC4) for some very interesting discussions about why the DDRC |= (1<<PC4) syntax is used.

Ralph

DDRC |= 1<<PC4 is for source code portability, to cover the maybe-some-day case where an Atmel chip doesn't use PC4 = 4.

Thank you ralphxyz and bretm for yr replies.

I am not sure I completely understand the portability issue you mentioned. We set the 4th bit of higher order nibble in the DDRC register. Now if Atmel comes around and says the 3rd bit needs to be set I will have to change my code even if I had used DDRC |= 1<<PC4

If you mean this line will work in a 16 bit resgister too (for a higher order chip than atmega168 which uses 16 bit registers) and will set the 4th bit of the higher order byte then it makes sense. If I had used DDRC = 0x10 I will now have to change to DDRC = 0x1000;

From the discussions I understand that DDRC |= 1<<PC4 is actually an assignment not an actual 'or-and-then-assign'. This is not very intuitive.

I found that for atmel168 either of these work:

DDRC |= 1<<PC4; 
DDRC = 0x10;
DDRC |=0x10;

DDRC or Data Direction Register for port C is the register that sets whether a given pin on the port is configured as input or output.

There are a couple of reasons why this is commonly done with an OR command and a binary shift.

1. Using the DDRC |= (1<<PC4) is easier to see that bit 4 (Or PORTC4) will be configured as an output.
   
2. While the statement DDRC |= 0x10 has the exact same effect it is less obvious what is happening.
3. The statement DDRC = 0x10 will set the PORTC4 as an output however, it will also configure every other pin in PORTC as an input. This is often a more conventient method when setting an entire port as input or output with DDRC=0x00 or DDRC= 0xFF.

That's my understanding of it all anyway.

Rick

The portability issue is this: PC4 is the name of a pin, not the name of a bit in a register. Which bit corresponds to which pin is allowed to vary by hardware. The fact that pin 4 corresponds to bit 4 for the ATMega168 is denoted by the fact that PC4 contains the constant value 4.

But other chips are allowed to do it differently. For example, pin PC4 might be associated with bit 3 in the DDRC register for some weird chip. It would be not cool if they did that, but code written like DDRC |= (1<<PC4) would work as-is on that weird chip. Code like DDRC |= 0x10 would not affect pin PC4 on that weird chip.

(Side note: There is a macro called _BV that can be used to clean up the ugly bit-shifting. Example: DDRC |= _BV(PC4). But that's still pretty ugly.)

For example, pin PC4 might be associated with bit 3 in the DDRC register for 
some weird chip. It would be not cool if they did that

You are very right... That wouldn't be cool. Luckily to date, I've not run across any like this however, I do use the pre-defined constants to reference them anyway. I think they make it easier to follow the code anyway.

Rick