There are some tech notes that are related to this might be of interest. If you place a ROM on the external bus, you can let the compiler place your constants and strings there. On some (few) AVR chips there is an optional external bus. You will in that case have to use either _flash or _generic pointer keywords.
When I include 'ior5f100ga.h' and 'ior5f100gaext.h' files in the source code generated through Applilet3, I am getting plenty of errors in these 2 header files. There is also the _flash extension keyword that can be used which probably does what you want, but taking a pointer to such object will yield a flash pointer that is incompatible with a default (keyword-less) pointer. Hi All, I am working of 'R5F100GAAFB' controller with IAR compiler.
IAR has choosen approach (1) and we consider adding approach (2) in the upcoming version 3 compiler. This can very easily cause massive code explosions if there are multiple pointer parameters of different types in the program. Generate multiple variants of g() to deal with various encountered pointer types. But that would prevent some correct ISO/ANSI C programs from compiling or running, maybe not so desirable.Ĥ. Relax ISO/ANSI C and put it in flash anyway. There are also two less reasonable ways to deal with the problem:ģ. Put 'limit' in flash and use a tagged pointer that is inspected at runtime before each pointer is dereferenced to select the appropriate access method. Put 'limit' in data memory so that it can be pointed to.Ģ. I can see two reasonable ways to deal with this problem:ġ. Flash and data are different memories and different instruction sequences are required to access them. If 'limit' above was placed in flash, the function g() would be in trouble as the first call would be with a flash pointer and the second call with a data pointer. But, you are still allowed to make a pointer to it. Since 'limit' is defined const, you hint that you want it in read only memory.
The following C code should work according to ISO/ANSI C: 654: declaration modifiers are incompatible with previous declaration 655: the modifierThe reason is that the IAR compiler is an ISO/ANSI C compiler.