[Top][All Lists]

[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

From: Bernard Fouché
Subject: Re: [avr-gcc-list] Someting I don"t understand with PGM_P et pgm_read_byte_far()
Date: Tue, 01 Mar 2005 19:51:27 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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.


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...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]