I learned about the 128KB program space limit a while ago was due to the version of compiler (4.3.2?). With the new IDE and more recent version of avr-gcc (4.8.1), can I access the upper 128KB program space now? I don't have a program that is nearing the limit but sometime from now I might.
liudr:
I learned about the 128KB program space limit a while ago was due to the version of compiler (4.3.2?). With the new IDE and more recent version of avr-gcc (4.8.1), can I access the upper 128KB program space now?
I think there was a bug with programs of more than 128KB in size shortly after the MEGA2560 was released. And as far as I know, it was a bug caused by the linker and not by the compiler.
But I think that bug was fixed several months later and now is fixed for years, even with the 1.0.x versions of Arduino.
But one thing should be remembered: The PROGMEM segment is always a 64 KB segment and you cannot put more than 64 KB of PROGMEM data into this segment.
OK, do you mean 64 kilo words instead of kilo bytes? I read on a post online mentioning the version of the compiler made the difference since the version that 1.0.x IDE has been using is before ATMEL had 256KB FLASH. I can't test this anyway. I don't have a long enough program.
liudr:
OK, do you mean 64 kilo words instead of kilo bytes? I read on a post online mentioning the version of the compiler made the difference since the version that 1.0.x IDE has been using is before ATMEL had 256KB FLASH. I can't test this anyway. I don't have a long enough program.
PROGMEM is limited to 64 kilo bytes.
And flash usage with Atmega2560 is limited to 256 kilo bytes.
Minus the size of the bootloader in default configuration which would mean that the total program size is limited to 258048 bytes.
When program size reaches 128 K (bytes) or more, function calls may be put into a "trampoline" section of the flash memory by the linker. So calling functions may take longer using the extra "trampoline" to reach the flash above 128K. I never needed that and I never tried to program a sketch that uses so much code.
But for someone who wanted to put a lot of image data into his sketch I've once created an example program that can put data in some extra flash segments. I.e. 32K arrays of byte, until you have reached the final flash size. Unfortunately reading and handling the extra flash data segments is a little bit more complicated than reading and handling of data from the PROGMEM flash segment.
So at least creating and uploading programs that contain some code and additional 200 KBytes of image data is no problem using Arduino 1.0.x and MEGA2560. I've done that around two years ago and it worked.
Thanks for the explanation. I was a bit confused. I did some digging on the doc:
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
Under detailed description, the only need to restrict PROGMEM in 64KB is imposed by the _P library functions:
NoteThese functions are an attempt to provide some compatibility with header files that come with IAR C, to make porting applications between different compilers easier. This is not 100% compatibility though (GCC does not have full support for multiple address spaces yet). If you are working with strings which are completely based in ram, use the standard string functions described in <string.h>: Strings. If possible, put your constant tables in the lower 64 KB and use pgm_read_byte_near() or pgm_read_word_near() instead of pgm_read_byte_far() or pgm_read_word_far() since it is more efficient that way, and you can still use the upper 64K for executable code. All functions that are suffixed with a _P require their arguments to be in the lower 64 KB of the flash ROM, as they do not use ELPM instructions. This is normally not a big concern as the linker setup arranges any program space constants declared using the macros from this header file so they are placed right after the interrupt vectors, and in front of any executable code. However, it can become a problem if there are too many of these constants, or for bootloaders on devices with more than 64 KB of ROM. All these functions will not work in that situation. For Xmega devices, make sure the NVM controller command register (
NVM.CMDor
NVM_CMD) is set to 0x00 (NOP) before using any of these functions.
So if I use the pgm_read_far functions to manually fetch data to SRAM before using them, this should not be limited to 64KB. And if the compiler/linker can compile code to run with long jumps, then what I'm looking at is to carefully fill up the lower 64KB with PROGMEM defs that use _P library functions such as strcpy_P and then fill the rest with more PROGMEM defs that I can only handle with pgm_read_far and program code.
liudr:
So if I use the pgm_read_far functions to manually fetch data to SRAM before using them, this should not be limited to 64KB.
I see, but this might be a problem with the old compiler versions and Arduino 1.0.x versions: These old IDE versions not only come with old GCC compilers, they come also with old versions of the AVR LIBC library. And old AVR LIBC versions have no pgm_read_XXX_far functions.
I'm not quite sure, but I think you must have Arduino IDE 1.5.7 or higher to have the pgm_read_XXX_far functions contained in the newer version of AVR LIBC.