[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: Wed, 02 Mar 2005 20:33:50 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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.


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


reply via email to

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