Program / data bytes?

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Program is flash usage, Data is ram usage.

Quote:
Can I give more to program?

Nope, this is fixed. But many AVRs have an upgrade path.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Nope, this is fixed. But many AVRs have an upgrade path.
- Yeah I went from atmega8 to atmega168, I need the pin layout to remain the same. I dont think the 88 is any bigger then the 168 and I think I have reached the max size I can get out of this style chip. Going to work on getting the flash size down.

Any tricks on this. For example does variable size even matter? I'm guessing not since its all compiled to asm .

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

look at the mega328

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thx Koshchi

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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...
_ I'm so glad I checked back... how many bits per character? Or how do you know when you step over 8? Or are you referring to data types? Like short int 1 -bit , char 8-bit

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

true.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stu_san wrote:
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.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
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.

Here's a thread I started about a similar issue a while ago. And you provided the workaround, using an 8-bit temp.

https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Last Edited: Thu. Jul 2, 2009 - 12:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Best practise is to always use unsigned variables unless signed operation is specifically required.
- valid point.

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??

Last Edited: Thu. Jul 2, 2009 - 03:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
Quote:
Best practise is to always use unsigned variables unless signed operation is specifically required.
- valid point.

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


It's not so much about saving space or time as about using the appropriate representation for your data. Do this and, yes, you will likely gain a speed and/or space advantage over using inappropriate representations.

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
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.
my code is 13 c files and a few h files. Most from 300 to 600 lines long. Not only do I think it would not fit in a post, there is no one here in there right mind that wound go through all of that trouble for someone.

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.