Does this mean my program is too big for my AVR ?

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

From the build messages :
(Should I worry about "204.9% Full")

    Device: atmega8515

    Program: 1284 bytes (15.7% Full)
    (.text + .data + .bootloader)

    Data: 1049 bytes (204.9% Full)
    (.data + .bss + .noinit)

    Build succeeded with 0 Warnings...

Jon Russell

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

Quote:
Should I worry about "204.9% Full"
I think so, you are using too much RAM, perhaps you have a lot of strings that can be moved into flash space using PROGMEM.

The 8515 has only 512 bytes of ram and you need to use AT LEAST 1049 + stack etc. I guess.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Super. Thanks. Thought so. I am playing with a 8x8 LED matrix. I have a char array font declared as "const unsigned char" with upper and lower case chars :-) That'll be it... The same code works if I remove all but 10 chars ... Just need to find a language with just 10 letters and I'm done !

Time to learn about PROGMEM :-)

Out of interest, isn't that worth a "warning" ? I just saw "Build succeeded with 0 Warnings..." and programmed my chip. Took me a while to work out what was up ... Is there any situation when you'd want to program the chip, when it knows it is sending too much data ? Seems a silly thing to allow you to do ?

Thanks.

Jon Russell

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

Quote:
Seems a silly thing to allow you to do ?
That'll teach using C instead of assembler... :lol: as the movie says "it's complicated" but progmem should sort things out.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
I have a char array font declared as "const unsigned char" with upper and lower case chars Smile That'll be it... The same code works if I remove all but 10 chars ... Just need to find a language with just 10 letters and I'm done !

No, you need to put your constant data into flash, not ram. You have plenty of room there. Read the thread on the use of PROGMEM in the Tutorials forum.

Regards,
Steve A.

The Board helps those that help themselves.

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

If you code each letter and number into 8bytes (a bit per pixel=8x8bits) you can get them all into <512bytes of ram (26+26+10)*8=496 bytes. I would still recommend using PROGMEM though.

Denis.

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

BigJon wrote:
Out of interest, isn't that worth a "warning" ?

In the specific case of the ATmega8515, it is possible to tack on up to 64K of additional external SRAM via '8515's integrated EMI (External Memory Interface). When the EMI is enabled and configured, it will allow that additional external SRAM to be accessed transparently, and the CPU will use the same instructions as though it was accessing the built-in SRAM.

The compiler and linker don't actually have any way of knowing whether or not you've added an external SRAM chip, or whether or not the EMI has been enabled. So it sort of makes sense that it wouldn't say anything about possibly legitimate uses of external memory.

On the other hand, there are lots of other AVRs which don't have anything equivalent to an EMI, and it would make sense for the compiler/linker to complain if your program's data usage exceeded those chips' internal SRAM size.

There may also be a case to be made that the linker should be modified to allow you to configure your project options and inform the linker, on a project-by-project basis, whether or not the EMI is actually being used, and the size of the external SRAM if it is being used. That way, the linker would be able to make sensible decisions about data memory warnings.

However useful that may be, nobody has seen fit to submit patches to give the linker such a capability (it is open source, after all, so if enough users REALLY wanted it, they could band together to create it), so it is left up to the operator to inspect the compiler's output more carefully to catch such potential errors.