Re: [avr-gcc-list] Someting I don"t understand with PGM_P et pgm_read_byte_far()

[Bernard Fouché]

E. Weddington a écrit :

> >
> If you take a look at  PROGMEM, there's nothing in there that has to 
> do with the size of pointers. It's an attribute to put the data into a 
> specific section.
>
> PGM_P is just a fancy way of saying a pointer to a byte in program 
> space. Personally I don't care for the capitalized #define and I don't 
> necessarily find the definition useful.
>
> The BIG problem is the size of pointers. For the AVR target, they are 
> 16 bits, across the board. This is fine for almost all the current AVR 
> devices except for the mega128 and now the upcoming mega256x. This is 
> why, when you put some data in the Program Space using PROGMEM, it 
> automatically goes into the bottom half of the mega128, so it can be 
> accessed with a 16-bit pointer. Right now this is an artificial 
> limitation with the mega128. The main reason why the pgm_*_byte_far() 
> macros were implemented was in case someone had a hard coded value in 
> the hex file at a high address space and also for implementation of 
> bootloaders so they can access the entire space. Those 
> pgm_*_byte_far() macros then accept a 32 bit value (a uint32_t) as 
> their "address"; they do not accept a true pointer as it is 16 bits. 
> Ok, well they accept it but it will only reference a 16 bits address. 
> You have to send a true 32-bit value to get to the upper half of a 
> mega128.
>
> Eric
Re-thinking about what you wrote, how one can use with maximal security 
something like the atmega128 with gcc(if you have data in flash)? From 
what I understand, if I do not take any particular precaution, a 
fprintf_P() can fail because the string referenced in flash is not in 
the same 64K bank than the code of fprintf_P() itself. So things may 
start to fail at some point when one makes the application grow or 
simply because one has modified a Makefile and the link order is 
different. If the code is maintained by people unaware of such a 
behavior, that's a real pain.

Or will gcc complain about 'an impossible pointer'? If there are no 32 
bits pointer, a linker warning or error might save people a lot of time. 
Or at least a statement in the "Program Space String Utilities" in 
avr-libc-user-manual. Something like "warning, if your constant tables 
are not in the same 64K boundary than the functions that use them, 
unless you explicitely manage RAMPZ, your program will fail."

Bernard