Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
November 30, 2024, 07:35:35 07:35


Login with username, password and session length


Pages: [1]
Print
Author Topic: winAVR code size....??  (Read 5366 times)
0 Members and 1 Guest are viewing this topic.
drthilina
Newbie
*
Offline Offline

Posts: 14

Thank You
-Given: 19
-Receive: 7


« on: February 21, 2009, 08:33:25 20:33 »

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
Logged
sam_des
Senior Member
****
Offline Offline

Posts: 256

Thank You
-Given: 128
-Receive: 151


« Reply #1 on: February 22, 2009, 09:13:10 09:13 »

Hello drthilina,

Quote
  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..

Quote
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.

Quote
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 .. Tongue 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
« Last Edit: February 22, 2009, 09:15:47 09:15 by sam_des » Logged

Never be afraid to do something new. Remember Amateurs built the Ark, Professionals built the Titanic !
drthilina
Newbie
*
Offline Offline

Posts: 14

Thank You
-Given: 19
-Receive: 7


« Reply #2 on: February 22, 2009, 10:00:05 10:00 »

Well.. I'm new to C programming also... one reason to switch was to force myself to learn C Grin.... 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....! Shocked
Logged
sam_des
Senior Member
****
Offline Offline

Posts: 256

Thank You
-Given: 128
-Receive: 151


« Reply #3 on: February 22, 2009, 10:24:19 10:24 »

Hi,
Quote
Well.. I'm new to C programming also... one reason to switch was to force myself to learn C ..
That explains a lot.  Lips sealed

Quote
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
« Last Edit: February 22, 2009, 10:29:37 10:29 by sam_des » Logged

Never be afraid to do something new. Remember Amateurs built the Ark, Professionals built the Titanic !
drthilina
Newbie
*
Offline Offline

Posts: 14

Thank You
-Given: 19
-Receive: 7


« Reply #4 on: February 22, 2009, 10:37:52 10:37 »

I will get my basics straight first..
I'll try and see what the "make" and "lint" can do to ease my work..
Logged
ali_asadzadeh
Junior Member
**
Offline Offline

Posts: 82

Thank You
-Given: 5
-Receive: 12


« Reply #5 on: February 25, 2009, 08:11:21 08:11 »

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);
}
Logged
sam_des
Senior Member
****
Offline Offline

Posts: 256

Thank You
-Given: 128
-Receive: 151


« Reply #6 on: February 25, 2009, 05:59:18 17:59 »

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
Logged

Never be afraid to do something new. Remember Amateurs built the Ark, Professionals built the Titanic !
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC