Had a question, what constitutes one over the other? Is Program the "code" for the most part and data the stored data types like int's ?
Program: 16290 bytes (99.4% Full)
(.text + .data + .bootloader)
Data: 485 bytes (47.4% Full)
(.data + .bss + .noinit)
Also, dumb question I'm sure, but can this be adjusted. Can I give more to program?
Program is flash usage, Data is ram usage.
Can I give more to program?
Nope, this is fixed. But many AVRs have an upgrade path.
Any tricks on this. For example does variable size even matter? I'm guessing not since its all compiled to asm .
look at the mega328
That think is pretty nice, why do I see the ARDUINO accompanied with it every where? One of its main uses I guess? Thx Glitch I will see if it jives with v-usb.
Anyone see an migration sheet for this one? When I went from my 8 to 168 I used a migration data sheet that was aimed to help make the changes. It really helped.
Or, is what I'm reading and see true, there is really no difference other then the size.
It is really a mega328P, so look at the migration document for going from a mega168 to a mega168P (AVR512). But since you are not using the P variety of the 168, I don't think you need to change any code
Thx Koshchi
Any tricks on this. For example does variable size even matter? I'm guessing not since its all compiled to asm .
Variable size does matter! You need more code to add a 16bit variable as opposed to an 8 bit variable. Same with a compare etc...
Variable size does matter! You need more code to add a 16bit variable as opposed to an 8 bit variable. Same with a compare etc...
In an AVR, memory is allocated in bytes (8bits). In 'c' your variables are defined by the data types. By default:
char is 1 byte
int is two
short is two
long is 4
char is 1 byte
int is two
short is two
long is 4
But There is no difference in .
char Im_a_verly_long_variable_that_is _only_one_byte_long
char Me_too
correct?
true.
One other "gotcha" when using the GCC compiler is that the default operation size is 16 bits. Thus
if ( (~PINA + 0x3A) == 0xFF )
will actually generate 16-bit math for the computation.
*sigh*, yeah, it's counter-intuitive, but it's the way it works. To force the above test to be done with 8-bit math, you must do:
if ( (char)(~PINA + 0x3A) == 0xFF )
(I may have the placement of the (char) incorrect since this still confuses me a little)
At any rate, if you have lots of single byte computations, you might want to review some of them to be sure they are being done as single byte computations.
Stu
One other "gotcha" when using the GCC compiler is that the default operation size is 16 bits. Thus
if ( (~PINA + 0x3A) == 0xFF )will actually generate 16-bit math for the computation.
Just to clarify, that is not a GCC specific gotcha, but rather a C language gotcha.
There are indirect tradeoffs that you can do to free up more program memory at the expense of data memory (and sometimes at the expense of execution speed). One of the most common is the extensive use of subroutines. Another is to use tables rather than code. Sometimes you can save even more program space by calculating the table at startup rather than embedding it in the source code.
And of course, be vigilant in using the right size variables and nothing larger.
Mike
stu_san, love the casting trick nice! I have many loops that use this for pin checking, I could save lots forcing them to a 1 byte char.
Mike, I'm making a usb protect so my execution time needs to be fast. I think that is out. but this tables thing sound interesting never heard of it. Do you have a link that would explain it.
(I may have the placement of the (char) incorrect since this still confuses me a little)
Quote:(I may have the placement of the (char) incorrect since this still confuses me a little)
You may have to cast all three terms as constants default to int.
I know char can be used most of the time in place of ints, but can it be used as any int that does not count to high? i.e for (char i=0; i<8; i++). and most of the time unsigned char can be used as I dont need negatives. but I dont see any info about unsigned char saving more then signed.
also short int is normally used for Boolean operations, does that save room for avrs? In C its 1 bit. -- hmm a test reviles no..
there are no 1 bit variables in C.. they all occupy at least 8 bits. A short int would be 16 bits, thus would be inefficient on an AVR, if all you are using is 1 bit, use unsigned char (uint8_t).
Using unsigned char instead of signed char can save some space if the compiler has to add code to account for overflow running from positive to negative. Best practise is to always use unsigned variables unless signed operation is specifically required. It can also prevent a lot of hidden "gotch's" from biting you in the ass down the road when you adjust things.
Best practise is to always use unsigned variables unless signed operation is specifically required.
From reading the links mike provided it looks like uint8_t .. would be best. It also shows a big difference in space. but I dont seen any info on the size. Can I reach 0xff? Ok I thisn I foudn the answer.
uint8_t holds 0..255 and int8_t holds -128..+127
I dont know why uint8_t save me so much compared to char...
ok small nitpick I know.. but does anyone know how to tell a IDE to turn unknown data type blue??
int8_t and uint8_t occupy the same amount of data space. However there may be a code penalty when using int8_t as it is signed and additional code handling may be required.
yes uint8_t has a range of 0 - 255 (0x00-0xff)
and int8_t has a range of -128 - +127
Both use all 8 bits, but signed is interpreted differently, and when it gets promoted to a 16bit int during a calculation, it must be "sign extended". Sign extension involves setting of clearing all 8 bits of the upper byte of the temporary 16bit value, based on the value of the sign bit of the original 8 bit value. (one of the hidden gotcha's I was referring to)
Quote:- valid point.Best practise is to always use unsigned variables unless signed operation is specifically required.From reading the links mike provided it looks like uint8_t .. would be best. It also shows a big difference in space. but I dont seen any info on the size. Can I reach 0xff? Ok I thisn I foudn the answer.
uint8_t holds 0..255 and int8_t holds -128..+127
I dont know why uint8_t save me so much compared to char...
Even though a char and a uint8_t (or an int8_t) use the same amount of storage, they are intended to represent different types of data. If you want an 8-bit integer then it's best to use an 8-bit integer rather than a character.
Mike
Great info guys, I have gone from 99.7 full to 83.1 and I'm still going through code. I may not need to upgrade after all.
One other thing that may be biting you is that the latest versions of GCC will inline functions more aggressively than previous versions. I've found the following hints from other folks that may (or may not) help you:
--------------------
> On inspection I find that the compiler has 'in-lined' at least 3
> function calls that I had written as a function to achieve compactness.
> Is there any way I can stop this, or is this a bug?
There has been some discussions about this before. After trying many different optimization settings I concluded that
--param inline-call-cost=2
is -overall- the best setting for small projects. However, if you need to minimize just one app, further reduction might be possible.
For example with things like:
-fno-inline-small-functions
-fno-split-wide-types
-fno-tree-scev-cprop
Also, you can prohibit the compiler to inline on a function by function basis.
Just to be sure you have no dead code around, include:
-ffunction-sections -Wl,--gc-sections -Wl,--relax
Ruud Vlaming
---------------------
add "OS_main" attribute to main function,
and (for an ATTiny) use the compiler switch:
-mtiny-stack
Anatoly Sokolov
---------------------
Also you can use the gcc options:
-combine
-fwhole-program
To use the options, you must compile all of your source with one call to the compiler:
avr-gcc ... -combine -fwhole-program ... main.c foo.c grunge.c gort.c mylib.c ...
Stu
I bet if you posted your code and announced with grand aplomb that no further shrinkage could be obtained by mere mortals, within a half hour you would have several further shrunk versions, which you could hopefully combine.
I bet if you posted your code and announced with grand aplomb that no further shrinkage could be obtained by mere mortals, within a half hour you would have several further shrunk versions, which you could hopefully combine.
stu_san, I dont think I will ever understand 1/2 of what you said but I will give it a try.
UPDATE:: I did save 10 more % with the compiler tricks.
