winAVR code size....??

[drthilina]

Hi everyone,
     I recently switched to programming AVR from PICs for curiosity sake, and MY GOD...!!! those have the speed. they are simple simple but brutal (this is just my experience). but I was baffled about some issues regarding the memory usage... as an argument, if AVR poses larger assembly instruction set, it should mean that the code it generates should be lesser compared to PICs. Don't know whether its the compiler but I feel the code can be much lesser than what is usually given via winAVR. recently I stumbled upon a mysterious situation, I was using the delay.h header and when I tried pass a variable from source file to my own header file which passed it then to delay.h via _delay_ms(XXX) the code size was 69% of ATmega's capacity, when I replaced those XXX (or variable) with constant ie. _delay_ms(100) the code shrunk to 20%.

Any idea..?

Many Thanks

[sam_des]

Hello drthilina,

  I recently switched to programming AVR from PICs for curiosity sake, and MY GOD...!!! those have the speed. they are simple simple but brutal (this is just my experience).

Glad to hear that..

but I was baffled about some issues regarding the memory usage... as an argument, if AVR poses larger assembly instruction set, it should mean that the code it generates should be lesser compared to PICs

No, that may not be the case always. AVR has load-act-store architecture, that means you will have to  move your operands from memory to one of 32 the working  registers before doing any operation & store it back to memory. PIC on the other hand can directly work on any of its memory location, but PIC memory is not continuous & is segmented/banked to allow smaller opcode size. AVR can access upto 64k memory with same pointers(x,y,z).
There are couple of other advanteges which you will notice once you start using avr.

Don't know whether its the compiler but I feel the code can be much lesser than what is usually given via winAVR. recently I stumbled upon a mysterious situation, I was using the delay.h header and when I tried pass a variable from source file to my own header file which passed it then to delay.h via _delay_ms(XXX) the code size was 69% of ATmega's capacity, when I replaced those XXX (or variable) with constant ie. _delay_ms(100) the code shrunk to 20%.

By god .. If you decide to use WinAVR(for that matter any gnu tools) make habit of reading help files thouroughly. Look at delay.h in 'avr/util' directory of your winavr installation. delay_xxx() functions have declaration,

Code:

void _delay_ms( double );
void _delay_us( double );

delay.h & avr_libc docs specifically "notes" that if you pass a variable to these function they will calculate all the constants needed for delay using "double" precision. That means all the floating point library is included in your final image. On the other hand if you pass them a compie time constant then preprocessor will calculate necessary constants.
Look at you '.lss' or '.map' file in both cases, you will get why there is so huge code-difference.

regards,
sam_des

[drthilina]

Well.. I'm new to C programming also... one reason to switch was to force myself to learn C .... anyway I tried passing double type variables into the delay.h library but resulted in getting the same result.. I'm guessing what ever the case for any variable that is passed it uses the floating point....!

[sam_des]

Hi,

Well.. I'm new to C programming also... one reason to switch was to force myself to learn C ..

That explains a lot. 

anyway I tried passing double type variables into the delay.h library but resulted in getting the same result.. I'm guessing what ever the case for any variable that is passed it uses the floating point....!

Firstly, delay.h is NOT the library. It is just the header file which gets included to "declare" external references in your '.c' file for compiler to be happy. To actually resolve these externals they must be "defined" elsewhere - that is library. Usually libraries have extension of ".lib", but GNU tools use extension -".a" for archieve. Look for "libc.a" & "libm.a" in 'avr/lib' folder. Your makefile will add them with name 'c' & 'm' i.e. without 'lib' which is assumed by linker.

Code:

void _delay_ms( double );
void _delay_us( double );

Note that these are function prototypes which specifies the "type" of argument it takes. Now whenever you call these functions, with argument of "any type", they will be automatically converted to 'double'. This is called type conversion. You normally must specify these type conversions to make your code clear to compiler as well as to you.

On the other hand, when you pass it a "compile-time" constant, preprocessor(cpp) wii do the all the calculations(with double precesion) & pass final result to function which now does not need to do any floating-point calcs.

Look at this...

Code:

  uint16_t j, k;
  uint32_t i;
 
  i = j * k;                     // does 16 x 16 = 16 bit, overflow ignored !!!!, may be wrong
  i = (uint32_t)j*k;          // does 16 x 16 = 32 bit,  that's correct

Run few examples with wide range of j & k, you will see why type conversion & type checking is done by c/c++ compilers. If you turn on all the warnings, compiler will flag first of above code as warning !!

Also I suggest you to learn using 'make' as well as 'lint'. 'make' will make your life a lot easier. & 'lint' will catch many errors which gets passed through compiler/linker unnoticed.

regards,
sam_des

[drthilina]

I will get my basics straight first..
I'll try and see what the "make" and "lint" can do to ease my work..

[ali_asadzadeh]

you should always use this pattern to get delays

Code:

#include <util/delay.h>
int main(void)
{
delay_ms(100);//will give you 100ms delay
//do something
while(1);
return 0;
}


void delay_ms(long time)
{
while(time--)
_delay_ms(.96);
}

[sam_des]

Hi,
In my opnion it always better to code delays in terms of no. of cpu cycles. That's what compilers actually do using wrappers. But since most users just blindly use the libraries, such code may be dangerous.
So I prefer the method followed by IAR & Crossworks - __delay_cycles( unsigned long ). Code generated is inline & very compact. For other compilers you can write a assembler routine that does fast double-loop based delay. That way you will be always sure how much time your 'delay' actually going to take.

regards,
sam_des