I did a little test today to see how much program memory is being used when the LCD library is loaded. This is about as basic as one can get; it puts a character and integer on the first line of the LCD. Here is my test code...

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"

int main() {

    // start up the LCD
    lcd_init();

    while(1) {
        lcd_home();
        lcd_write_string(PSTR("A: "));
        lcd_write_int16(1);
    }

    return 0;
}

The hex for this is 6792 bytes, which means anytime I start one of my NerdKits projects and I want to use the LCD library as is, roughly 40% of program memory is used up right out of the gate!

Looking at the disassemby it looks like the biggest contributor to the problem is the stdio library of functions. So, I'm considering dropping lcd_putchar which I think would eliminate the references to stdio.

Does anyone have any recommendations on the best way to "skinny down" the LCD library, so that I can use the LCD, but not carry so much overhead with it?

Actually stdio is going to be used in a LOT of what you code if you're doing any sort of communications... All the standard printf, scanf, etc stuff is in there... In fact, not just for the MCU, but in C itself usually your starting "template" always has stdio included right from the get go... If you don't use it at all, then you can certainly remove it...

Now... Here's the thing... You've got 16k of program space to work with... Plus 1k of SRAM... And even though it doesn't sound like much, you've also got 512 bytes of EEPROM in there as well...

Even though the basics are taking up a lot of the program space, you'd be amazed at how much you can do with the rest...

In other words... Unless you actually run into space problems, and you can't optimize your code, I wouldn't really worry about it...

Rather you're talking about C or asm, effiencieny is really the key... There are thousands of ways to accomplish the same thing, but generally only a few to do it as compactly and effieciently as possible... I still remember way back in the day coding asm "loaders" for uhhh well uhh "software packages"... Playing music through a soundblaster, 3d renderings, crazy graphics routines, etc... All kinda crazy stuff and compacted down into a RIDICULOUSLY small .com file... The "show off" part came in doing the MOST with the LEAST... fun times... ;) When you start thinking in that way you'd be amazed what can be accomplished... One of the oldest tricks in the book for graphics stuff was shifting bits for multiplication... Talk about FAST! not to mention small and easy... ;)

Thanks rusirius.

Actually, I am beginning to run up against space limits and that's why I asked the question. I am programming a game and there are graphics and sound as well (the sound I have stored in an external dataflash). I am not really using standard printf, scanf stuff, so that is probably where I will trim. I hadn't really considered the use of SRAM which is a good suggestion. I may store some of my strings in the dataflash and load them into RAM for display rather than keeping them in the program space where they are now.

IvonV,

I had success cutting away vfprintf, which is a humongous beast, and I don't really need it. I don't remember how big the savings were but I do remember I was o_O . Actually, avr-libc provides you with three different versions of vfprintf: vfprintf that does all the standard format conversions except floating point ones; printf_min a stripped-down one that only does some basic integer and string formatting; and a full-blown printf_flt when you want to format those pesky decimals. By default vfprintf is linked to vfprintf references, naturally :), unless you override it as a parameter to gcc, like so:

-Wl,-u,vfprintf -lprintf_min    // undefine avr-libc's vfprintf, link in libprintf_min instead

or:

-Wl,-u,vfprintf -lprintf_flt -lm // undef vfprintf, pull in printf_flt AND some stuff from libm!

Now check your Makefile. ;)

For a more complete explanation refer to avr-libc page on stdio.h and the GCC man page.

Well, it's late and my mind is wandering, so I made a few mistakes in the above post without even noticing them. Not that they are substantial errors, but I still need to amend myself for clarity's sake.

There is only one name for all three different vfprintf variants, and that is vfprintf. printf_min and printf_fmt are libraries libprintf_min.so.something and libprintf_fmt.so.something on Linux for example. Adding -lprintf_min instructs GCC to read symbols from libprintf_min.so.* in addition to other dynamic libraries it uses; and libprintf_min contains a shorter version of vfprintf which then takes place instead of the one we just undefined via -Wl,-u,vfprintf .

There, now I am at peace. =)

Thanks wayward, that saved a few good bytes!

Nice wayward... I added that to my "future notes that are good to know" file... LOL!

IvonV... If you still run into issues, you could consider adopting the "Microsoft Way"... You know... "Bigger is Better".. LOL... Check out the ATMega644... I picked one up a while back to play around with... Not much more than the 168, but that bad boy has 64k of program space, 2k of EEPROM, and 4k of SRAM... If you're doing a game thats probably a good one to look into... It also has 32 I/O pins, but that probably won't make much difference to you... They only run about $7.50, so not much more than the 168...

Ohh, I should have added, though it should be obvious that it won't have the NK bootloader on it, so you would need an SPI programmer (or use the 168 to MAKE one... ;)

Holy mega cow... LOL... I just did a quick search to make sure I gave you the right pricing info and ran across this... Didn't even realize it existed...

May I introduce you to the ATMega1284.. 128k program space, 4k EEPROM, 16k SRAM, and 32 I/O lines... Also only $7.53

If you can't do it with that beast you probably outta just buy a laptop... LOL...

OMG... what would I do with all that program space... and all those pins???

I'm not at my computer with my libavr stuff installed, but is the comiler (linker really) optimizing the binary output to strip away any unused symbols?

Wow! 16K SRAM! I was drying off after my shower this morning thinking about the fact that this chip has only 1024 BYTES of memory... 1024... Wow. Hrm... Where did you see $7.53? I don't see anyone selling it -- just the product release information stating Q4 2009:

http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=NR_m1284P_9_29.html

Ahh, here's more: http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega1284P

Very interesting. Reading time. :)

Sorry, should have mentioned it is a pre-order... but available none the less... Mouser is where I generally get most of my stuff... Great prices, great people to deal with, and even though I usually place orders between $10 and $100 occasionally $300 or $400, they treat me like a customer that orders millions of dollars of parts every year when I call...

http://www.mouser.com/Search/Refine.aspx?Keyword=ATMega1284

Thanks for the hook-up to mouser.com. I've scoured the 'net and have accumulated quite the link list. My best find today was the MIT courses that are in iTunes-U -- now I can learn some electronics from a lecture.

MikeDoug