----- Ursprüngliche Nachricht -----
Von: Rick Jenkins
Gesendet am: 18 Nov 2009 19:35:36
> Defining your section as:
> /* New section by rlj */
> __foobar_start = . ;
> *(.foobar)
> __foobar_end = . ;
> . = ALIGN(2);
> /* End new section by rlj */
> allows the section to be the exact size of the contents, in my case a single
> function.
There you'll see why I don't like the linker approach:
while I think I'm a fairly good programmer, I have no clue about how to script
the linker :)
I'm sure that when I start to fiddle around with it and actually see all of its
functionality in use, I can easily determine how to use it to my advantage
(this is why I'm employed, at least partially), but I never had a reason
to do so. (yet)
But I already had to take a look at the assembler to analyze one or the other
weird warning or error message.
>> You have seen my assembly hack? If you put your fucntion into a separate
>> object file, it will be 100% safe, even with -o3. Without any linker
>> hacking.
> I have, and it's clearly the most elegant solution to my original problem.
thanks :)
> In particular, it confines the "trickery" to the source file containing the
> function, instead of requiring an obscure, dissociated entry in a linker
> script. After trying it out I'm convinced this is the cleanest way to go.
I too prefer to put all project dependent stuff into the source files and (if
it's really necessary) into the makefile.
I'd really prefer to have the target processor put into the source file (all my
sources include a 'system.h' as the very first thing, where all
hardware-dependent things adn config are defined, including the include of the
proper MSPx.h).
Unfortunately the target process has to be set using the -mmcu= commandline
parameter in the makefile, requiring the makefile to be changed when the target
processor changes.
A pragma doing htis form source level would be much better.
> If I felt a little less fallible, I'd use the method of a fixed, unchangeable
> reprogrammer in a non-erased section of ROM. I just have a nasty, sinking
> feeling that, the moment this was widely deployed, I'd find a bug in it...
by placing the plain 'flash write' function into ram, you can even reprogram
the boot loader, if necessary.
Provided that the write function can handle the size of the loader in one
piece.
And of course if something goes wrong exactly at this moment, there's no way
back (except for using the original BSL and doing a completely new setup, if
hardware allows using the BSL).
But this is also the case when all the flashing is done inside ram.
So it minimizes risk for 'normal' updates.
> Thanks to all who have taken the time to respond.
you're welcome.
JMGross
