out of range rage

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

Hey guys, for some reason I am trying to compile my source onto an attiny2313 and it is saying:

avrdude: ERROR: address 0x0810 out of range at line 129 of main.hex

Now, I have been under the assumption that meant basicly your source is too large for the mcu!

but I am almost 100% sure my source is large enough to fit onto my attiny... im pretty sure I have loaded the same include files onto 2313's before with alot more code then this! so I dont understand why its doing it... I just put this code togather to start on a project and it just will not compile... here is all the files just:

main.c usart.c usart.h and the makefile:
main = http://www.ursrc.com/index.php?s...
usart.h = http://www.ursrc.com/index.php?s...
usart.c = http://www.ursrc.com/index.php?s...
makefile = http://www.ursrc.com/index.php?s...

Take a look for yourself! theres no way thats too small... is there a way to check how big the file is? is the .hex file itself how large its going to be on the chip? the .hex file is forsome reason 6.34 KB!! that cannot be!

someone please look at my source and tell me why its compiling so large!!

Last Edited: Sat. Jan 27, 2007 - 04:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also here is my main.lst, usart.lst, and main.map files... I dont know if that helps or not:

main.lst = http://www.ursrc.com/index.php?s...
main.map = http://www.ursrc.com/index.php?s...
usart.lst = http://www.ursrc.com/index.php?s...

I dont know if these are usefull or not for this... so I will show you them anyways :)

unrelated: is the .lst file the one you guys normaly look at to see what the code is doing? like the differnce between while(1) and for(;;) or what ever?

the usart.lst seems to be alot larger, and it is a very small amount of code as well, I made the USART include file to be small, so I could use it on attinys, or what ever other project and not have to worry about usart not fitting... i guess not ;)

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

I put it all into 1 file to try and mod it, and I got it to work by removing all stdio stuffs...

so why is stdio take up so much space?

new code http://www.ursrc.com/index.php?s...

this file takes up more then half the space itself!! why is it so big?! it seems to be vary small code!

1324 bytes of flash verified

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

1) The .LSS file is the intermixed source/ASM listing. Useful for working out what lines of code produce what assembly. However, at high optimization levels whole functions or blocks may be inlined or removed, making matching C line to ASM lines difficult.

The .MAP file tells you where all the different symbols (functions, etc.) are located. Useful for determining which of your functions are the largest. Also useful for determining which libraries (and which routines IN the libraries) are being used, as well as other useful info.

2) Actual .HEX file size != size of binary data. The .HEX file contains overheads (data is HEX written as ASCII rather than bytes, checksum and addressing data) which aren't loaded into the AVR. You can check the size of the resulting binary from the compile results.

After building your project, you should see some lines similar to the following. If not, update your makefile:

AVR Memory Usage
----------------
Device: Unknown

Program:   13616 bytes
(.text + .data + .bootloader)

Data:        659 bytes
(.data + .bss + .noinit)

EEPROM:      468 bytes
(.eeprom)

3) Some of the functions like (s/f)scanf, (s/f)printf etc are VERY large. This is because they are designed to handle ridiculously complex input - all the different datatypes, different format strings, etc. You should really avoid them if possible, and switch to the minimal versions in your makefile.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

As Dean says, printf() is a very large function and your main.c uses it. You can almost immediately say goodbye to 2K of your flash space as soon as you have even one invocation of printf(). On a 16K Mega16 or a 128K Mega128 then it's a small price to pay but on a 2K Tiny2313 you blow virtually the whole memory in one fell swoop.

As your only using printf() to output a fixed string and not having it process variable substitution you would be far better advised (in a Tiny2313) to first write yourself a UART_put_character() - in fact your uart_tx() is already this - and then your own UART_put_string() based on this and if you ever need to output decimal variables then perhaps use the itoa() and ltoa() library function followed by UART_put_string() to ouput the string they produce. These limited library functions are far smaller than printf()/sprintf()

Cliff

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

I use something like (strings from RAM)

/**
 * Send a string to the serial port.
 */
void PutStrNl (char *data, bool newLine)
{
    while (*data) PutChr(*data++);
    if (newLine)
    {
        PutChr('\r');    // optional
        PutChr('\n');
    }
}

You just have to replace PutChr by your routine ('bool' can be uint8_t).

Embedded Dreams
One day, knowledge will replace money.