----- Ursprüngliche Nachricht -----
Von: Peter Bigot
Gesendet am: 13 Dez 2011 13:48:16

>>> You can use asm statements, as are done with the peripheral register
>>> declarations.  Something like:
>>> volatile unsigned int specialdata __asm__("0x1320");
>>> will force the definition of specialdata to be placed at address 0x1320.
>
>> That's the obvious way.
>> However, it must be used with care.
>> The variable locations are put as direct addresses into the
>> compiler-generated assembly output.
>> The linker won't see them or know of them.

> Which is why the real peripheral register declarations use:
> volatile unsigned int P1OUT __asm__("__P1OUT");
> where __P1OUT is a symbolic constant defined at final link time from
> the MCU-specific periph.x file.  The same thing can be done in this
> case so ensure all modules get the same address.  

I was rather talking about two modules defining two independent
"superstatic" variables which happen to end up at the same
memory location because they don't knwo of each other.

The linker script variant is nice if you have a closed system
(everything known), but would require to mess with
linker scripts each time a new software library uses this feature
and for every processor you want to use this library with.

> The original request
> was for a simple way that didn't muck with linker scripts, but if the
> potential for inconsistency is a concern the symbol value can also be
> provided on the linker command line; see the msp430-ld man page.

It's the potential for undetected coincidency of independent work 
that was my concern. :)

JMGross


------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to