Re: [avr-gcc-list] Re: placing a variable in flash

[David Kelly]

On Nov 22, 2004, at 11:18 PM, Royce & Sharal Pereira wrote:
...
> I first program the entire device. This automatically erases it, 
> setting
> 0x1fff to 255.
> Now, using feature (1), I read the calib. byte for 4MHz, & pipe SP12 
> output
> to a stream editor, sed, which extracts the calib byte.
> Using feature (2), I write the extracted calib byte to 0x1fff in
> flash(program) memory.
>
> My challenge was creating a variable in flash at 0x1fff so that the 
> Mega8
> could read this byte at reset & save it in OSCCAL.
> I then realised that I really didn't need a 'label'.
> So this works:
>
>           OSCCAL=pgm_read_byte(0x1fff))

I'm only now in the reading phase at getting started with avr-gcc but 
in other toolsets for embedded CPUs one generally has to do a lot more 
work with the linker before ultimately able to create a project. And 
your need smells a lot like a job for the linker.

In /usr/local/avr/lib/ldscripts/ you will find the linker script used 
for your CPU. Copy one to your project and edit it. I don't know this 
linker well enough yet but its likely you can create your symbol 
totally within this file.

Another possible solution would be to create a single C source file 
containing nothing but your one byte constant definition. When linking 
in the Makefile follow one of the examples and load that one object 
file to a specific section and spell out the starting address (0x1fff) 
of that section on the command line. Might be able to force it into 
.text at that location, might not. Might need to create a .mytext 
section in the linker script and stuff it in there.

As I said, I'm still reading. Thinking if your byte is declared 
constant then avr-gcc will use the proper addressing to pluck it from 
FLASH.

One last solution, you could simply throw the byte in the normal 
constant "variable" pile and use your scripts to find it in the object 
table while you are determining the correct calibration value. If its 
referenced only in one file then the optimizer may remove its 
allocation. (Seems like that would require optimization in the linker.) 
If its created global in one file and declared constant there, but only 
"extern" elsewhere then it might fool the optimizer.

On the other hand as long as your program code never overflows to 
0x1fff for storage your current solution works fine and is simple.

--
David Kelly N4HHE, address@hidden
========================================================================
Whom computers would destroy, they must first drive mad.