Re: [avr-libc-dev] noinitdata section ?

[daniel_laptop]

"Theodore A. Roth" wrote:

> On Wed, 28 Aug 2002, daniel_laptop wrote:
>
> :)I am talking about external device battery backed SRAM
> :)(or nvram - www.simtek.com
> :)http://www.simtek.com/Technology/SimtekQuantumTrap.pdf
> :)- www.zmd.de   http://www.zmd.de/nvsram_overview.html  )
> :)That can be programed once by itself and then normal runtime changes
> :)and if flash MCU software upgrade still keep data.
> :)eg counter of something since board installed.
> :)(to many changes for normal eeprom).
>
> Seems to me if you map the nvram into the external sram space (which you
> almost have to), then you would not have problem. The chip erase
> functionality is implemented internally in the avr's and shouldn't to my
> knowledge
>

Using hard coded memory addresses outside the range the linker has been
set for

it all WORKS fine :-)
(the reason for my upgrade to cvs from last stable release
is all the new (GOOD) sfr macros etc.)

What would be nice (but not necessary) is to use the future ?
>>  - .noinitdata section, like BSS but not cleared after reset, for data
>>    in SRAM with battery backup, use __attribute__((section(".noinitdata")))
>>    in C declarations of such variables
to allocate the locations and then keep a map of this for flash software
upgrade use.
(can be expended in upgrades but not reduced)
(working from end of ram backwards ?)

(I am only asking because I saw "noinitdata" in other emails)

>
> In the worst case, couldn't you mmap a latch byte into the external space
> which disables the sram on a reset or powerdown and then gets renabled after
> the standard initial? Maybe in the .init8 section? You might even be able to
> disable latch in .init0. Of course, this would probably mean external
> circuitry, so it isn't as nice as a software solution.
>
> I wonder if you could find some voodoo or incantantion to place in one of
> the .initN sections which would do want you want. Hmmm...
>
> Ted Roth

AAARG... now that's thinking.
I'm glad it works with hard coded memory addresses.
(outside linker settings)

Thanks
Daniel