Go Down

Topic: ATmega328 having trouble with sketch > 16K fixd (Read 607 times) previous topic - next topic

TeraHz

Aug 16, 2010, 10:42 pm Last Edit: Aug 17, 2010, 03:16 am by terahz Reason: 1
Hi all,

I've been working on a project that recently went over 16K, which I expected to not be a problem on the 32K ATmega328, but it is. The sketch compiles and uploads successfully (or so does the IDE tell me), but after it passes about 16400 bytes, the code just stops working. It is like some of the binary didn't make it to the chip. I know it isn't code related, because I can add/remove any non-essential line(like a System.println();) to make it under/over the ~16K mark and when it is under it works 100%, when it is over, it doesn't even initialize my components (like LCD, RTC etc).

So I'm at a loss what is going on.  I know the chip is the right one. It is not a commercial Arduino, but a diy one, though I doubt that could be related.

So any help would be much appreciated.

deSilva

This is nothing simple...
I just checked with a simple program
Code: [Select]
Serial.println(i++);
Serial.println(i++);
Serial.println(i++);
Serial.println(i++);
Serial.println(i++);
Serial.println(i++);


which flawlessly runs with 500 (12kB) and 1000 line (24kB).

retrolefty

Could you be running out of SRAM (used to hold variables, arrays, and stack) rather then flash? That fact that it compiles and uploads OK doesn't sound like it's a simple flash size problem.

Lefty

TeraHz

Well if I just use Serial.println in the loop it works fine even > 16K, but for some reason my sketch stop working.

retrolefty, could be SRAM limit... If that's the case, it would be pretty bad, as I'm not even close to done :(

I do have an big data structure that is probably 1K... I might have to clean it up or put it in the eeprom and read it in small chunks.

darn these limits :)

I'll play with that a bit and see if that helps. Thanks for giving me the idea!

RuggedCircuits

Don't forget to use the right types, too. An array of int's will take up twice as much space as an array of char's (or uint8_t). If you can fit your numbers into 8 bits, uint8_t makes a lot more sense.

Also think about byte packing. I've seen a lot of people post arrays that look like:

Code: [Select]
uint8_t arr[] = { 0, 0, 1, 1, 0, 2, 3, 0, 1, ....

If you've got REALLY small integers then you can pack multiple integers into one byte. For example, numbers in the range 0-15 fit into 4 bits so two such numbers fit into a single 8-bit byte.

--
Check out our new shield: http://www.ruggedcircuits.com/html/gadget_shield.html

TeraHz

Yep, it was the SRAM. I had a big struct of char[] that was the data structure for a menu. I didn't realize till now that the sram is quite small. After removing the tooltips for the menu options the sketch at 20K works like a charm.

RuggedCircuits: yes, I try to use byte and even #define wherever possible, but somehow I forgot that having 50 char[20] strings takes a lot of space :)

liudr

Since you're using an LCD, you must have a lot of strings to print. Try using PROGMEM to store the messages in flash instead of in defined variables. That will free up hundreds of bytes if you have many messages to display. Today I used my ATMEGA168 (16K flash, 1K SRAM) up to 8 bytes left in flash with 1,300 lines of code, no hicups, no freezes. You have to leave enough SRAM. That's the fun side of programming a microcontroller. Resources are limited and people need to be resposible!  ;D

TeraHz

liudr, that's a goo idea. Next time I hit the sram limit (and I'm sure I will :) ) I'll start moving to PROGMEM.

Indeed programming a micro adds some new aspects to the sport :)

Go Up