My program became too big for the ATmega168, so I switched to the ATmega328P, which has 32KB of flash memory (double of the ATmega168). My program's hex file is now 80,973 bytes, which is obviously a lot more than 32KB. How can I tell much flash it's taking up (so I know how close I'm getting to the 32KB max)?

It turns out there is a program installed with WinAVR called avr-size that tells a few things about your hex file:

C:\Dev\NerdKit\code\Wifi>avr-size wifi.hex
text    data     bss     dec     hex    filename
0       28780     0     28780    706c   wifi.hex

According to another internet post, it works better with .elf files than .hex files because with .elf files "it can also show you both how much ram you need (data+bss) and how much flash will be used (text+data). With the .hex file only shows you the second figure (labeling it data)."

So, in my case the data column shows 28780, which is 28kB. Since the ATmega 328p has 30kB available for a program (32kB minus 2kB for the bootloader), I have just 2kB left. That's not much, since I just started writing the app. The libraries I'm using to talk to a WiFi chip take up a lot of space.

I had a similar issue with a lib for an SD card taking so much space that I didn't have room for the rest of my app. To solve the problem I put the rest of the app on a new chip and it talks to the SD app via I2C whenever access to the SD card is needed. Works good so far.

So, you have to MCUs for that app?

A few more things you can do...

1 - int8 vs int16 - Get rid of any 16 bit numbers that you don't actually need to use.

2 - breakdown formulas - I found that often times formulas that are somewhat long tend to compile smaller if broken down into multiple statments. (I don't really have a pattern but basically "doing several steps seems to be more efficient than one large step".) Just "change" and "compile" trying other possibilities.

3 - Error Message Table - Often test messages in general are highly compressible. On Projects that are getting full store the "words for messages" in a table and then "create the messages by strining together indexes for the words"... If I have less than 256 words, which is most often the case, then a string of byte values, otherwise a string of word values.

4 - C Standard File I/O - The c Language Standard File I/O is nice, flexible, and convenient, but there is an overhead for that. I have found that often I get a smaller set of code if I avoid using that and code it all myself. (Only rarely do I ever need to be able to easily send a given output stream to other devices.)

5 - Integer Math - If you don't need floating point don't use it. i.e. If you want to have a percentage and you want to have accuracy to .x% then use a int16 and know you are keeping in in 100ths. (So it will go from 0-10,000) Just keep track for yourself that the value is i00ths.) Also if you are taking 30% of something... answer = int16 * 3 answer = answer / 10. Often that will come out better than answer = int16 * .3.

Yes, two MCU's. One for the SD card I/O and the other for my original sensor monitoring app. I have to admit I am being lazy by using existing libraries where possible so there is probably a lot of overhead included that could be squeezed out but I don't care much and using two chips is fun anyway. My project is a one off or maybe I'll have another at some point but not enough of them to worry about an extra chip in the mix. Besides now that my SD functionality is on separate chip it's easier to add it to new projects.

Jim raises good points if you want to stay on one chip but sometimes there is not enough room on a single chip no matter what you do to conserve. There are avr chips with larger flash too, 64kb is next up and 128 or 256 after that. But you get a lot more pins on those chips and few are available in DIP configuration.