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

[Bernard Fouché]

E. Weddington a écrit :

> Bernard Fouché wrote:
>
> > IMHO PGM_P and PROGMEM should adapt to the flash space size of the 
> > target. I'm writing code that has to work for atmega64 & 128, and I 
> > have to redefine my own set of macros to have such a fonctionnality 
> > (I don't like to patch 'system' file like pgmspace.h). I don't see 
> > yet how to do so for PROGMEM since it is just a rewrite of 
> > __attribute__((__progmem__)).
> 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

Thanks for these explanations, I now understand why we had some weird 
problems while trying to use the same code for a bootloader for atmega64 
an 128 using gcc and PROGMEM. Expecting PROGMEM to store strings in the 
flash used by the bootloader in a 128 is a dead end it seems...

Bernard