[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Someting I don"t understand with PGM_P et pgm_read_by
Re: [avr-gcc-list] Someting I don"t understand with PGM_P et pgm_read_byte_far()
Tue, 1 Mar 2005 11:00:43 -0800
On Mar 1, 2005, at 10:29 AM, E. Weddington wrote:
I might be wrong, but I recalled one post 1 year ago talking about the
problem. The problem is that gcc wants the address be "byte
addressable" while Atmega128 program flash should be addressed by word
Bernard Fouché wrote:
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
E. Weddington a écrit :
Bernard Fouché wrote:
So it appears that, even for an ATMEGA128, a PGM_P data type is a
16 bits pointer.
That is correct.
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
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
So could we somehow make gcc addressing flash as word address for
AVR-GCC-list mailing list