OK. Note that constants for all USB buffer memory blocks are
pre-defined in the msp430f5529/periph.x script, so you should only
need to reference __USBSTABUFF and others, with or without offsets.
A structure placed at those addresses with an asm directive would not
require touching the linker scripts and would work with other MCUs
that might place the USB buffers at a different location.
Peter
On Tue, Dec 13, 2011 at 9:56 AM, Timothy Logan <timothy.lo...@gmail.com> wrote:
> Thanks,
>
> That's actually exactly what I am doing (porting over some USB driver code),
> so unfortunately refactoring to remove this requirement isn't possible for
> me. I will look into appending my code into the existing linker scripts to
> do what I want.
>
> Cheers,
> Tim
>
>
> On Tue, Dec 13, 2011 at 9:38 AM, Peter Bigot <big...@acm.org> wrote:
>>
>> On further thought, you'd be better clone-and-owning the standard
>> linker scripts (msp430.x at least, maybe a couple of the other ones,
>> but you shouldn't need to touch the mcu-specific ones). Insert a
>> section specifically for your variables into the correct region
>> (presumably REGION_DATA). The main script assumes that it has full
>> knowledge of everything that goes into each region, and sets markers
>> to denote the start and end addresses for things like initializing BSS
>> and copying initialized data from ROM into RAM. I think there would
>> be subtle problems that would arise if you tried to append something:
>> either the variables you declare would overlay other ones placed by
>> the linker, or the address markers would be wrong.
>>
>> Not knowing your application I can't suggest removing the requirement
>> that variables be placed at specific locations, though it's an avenue
>> I would seriously explore if it were my problem. The primary case I
>> can think of that justifies what you describe involves overlaying
>> structures on data placed in peripheral memory (such as the USB
>> buffers), in which case this can be done without modifying linker
>> scripts (re-use existing symbols, or define new ones).
>>
>> Peter
>>
>> On Tue, Dec 13, 2011 at 9:17 AM, Timothy Logan <timothy.lo...@gmail.com>
>> wrote:
>> > Thanks for everyone's input.
>> >
>> > I agree that having a linker script would be a cleaner way of
>> > implementing
>> > this and think I am just going to buckle down and use a linker script so
>> > I
>> > do not end up shooting myself in the foot.
>> >
>> > I want to make it however so that the "sections" that I define like
>> > CrazyCasta said are merely appended to the end of the default linker
>> > script.
>> > Reading into the msp430-ld man page, it has the following to say:
>> >
>> > "If the linker cannot recognize the format of an object file, it will
>> > assume
>> > that it is a linker script. A script specified in this way augments the
>> > main linker script used for the link ..... Specifying a script in this
>> > way
>> > merely augments the main linker script, with the extra commands placed
>> > after
>> > the main script; use the -T option to replace the default linker script
>> > entirely, but note the effect of the "INSERT" command."
>> >
>> > So, making a linker script like this (called linker.x):
>> >
>> > 1 SECTIONS
>> > 2 {
>> > 3 .mySection 0x0100:
>> > 4 {
>> > 5 variable1 = 0x2280;
>> > 6 variable2 = 0x0820;
>> > 7 variable3 = 0x22C8;
>> > 8 variable4 = 0x2288;
>> > 9 variable5 = 0x2278;
>> > 10 variable6 = 0x2270;
>> > 11
>> > 12 }
>> > 13 }
>> >
>> > And passing it in to the linking step of my Makefile like:
>> >
>> > $(CC) -Wall $(LDFLAGS) linker.x $(ALLOBJS) -o $(BUILDDIR)/EXAMPLE.ELF
>> >
>> > should do the trick, right? I do get the following warning:
>> >
>> > /usr/lib/gcc/msp430/4.5.3/../../../../msp430/bin/ld: warning: linker.x
>> > contains output sections; did you forget -T?
>> >
>> > .. but maybe this is normal?
>> >
>> > Sorry if this is going too deep into generic-linker questions.
>> >
>> > Cheers,
>> > Tim
>> >
>> >
>> > On Tue, Dec 13, 2011 at 6:48 AM, Peter Bigot <big...@acm.org> wrote:
>> >>
>> >> On Tue, Dec 13, 2011 at 6:03 AM, JMGross <msp...@grossibaer.de> wrote:
>> >> > ----- Ursprüngliche Nachricht -----
>> >> > Von: Peter Bigot
>> >> > Gesendet am: 12 Dez 2011 21:39:15
>> >> >
>> >> > On Mon, Dec 12, 2011 at 2:31 PM, Timothy Logan
>> >> > <timothy.lo...@gmail.com>
>> >> > wrote:
>> >> >>> I am porting some code from IAR which involves me having to place a
>> >> >>> few
>> >> >>> different structures in very specific addresses in the MSP430
>> >> >>> memory.
>> >> >
>> >> >> 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. 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.
>> >>
>> >> Peter
>> >>
>> >> > So if two independent compilaiton units (C files)
>> >> > Use their own "superstatic variable" and it happens
>> >> > to be placed on the same location, you won't get
>> >> > an error or even a warning. And the two code parts
>> >> > will mess with each others storage then.
>> >> >
>> >> > Especially dangerous when using libraries, where
>> >> > the particular code is not checked/adjusted for every project.
>> >> > (so it could be noticed)
>> >> >
>> >> > JMGross
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Systems Optimization Self Assessment
>> >> > Improve efficiency and utilization of IT resources. Drive out cost
>> >> > and
>> >> > improve service delivery. Take 5 minutes to use this Systems
>> >> > Optimization
>> >> > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
>> >> > _______________________________________________
>> >> > Mspgcc-users mailing list
>> >> > Mspgcc-users@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Systems Optimization Self Assessment
>> >> Improve efficiency and utilization of IT resources. Drive out cost and
>> >> improve service delivery. Take 5 minutes to use this Systems
>> >> Optimization
>> >> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
>> >> _______________________________________________
>> >> Mspgcc-users mailing list
>> >> Mspgcc-users@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>> >
>> >
>
>
------------------------------------------------------------------------------
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and
improve service delivery. Take 5 minutes to use this Systems Optimization
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
