Re: [avr-gcc-list] Allocating variables to a fixed address

[Robert von Knobloch]

David Kelly wrote:
> On Mon, May 11, 2009 at 08:21:37AM -0600, Weddington, Eric wrote:
>   
>>>> Sounds to me as if you are making the "bootloader" too big and
>>>> should simply link an entire application for every possible 
>>>> target. What you are doing would make more sense if the loadable
>>>> modules could run out of RAM.
>>>>         
>>> That would be no use, the loadables must be non-volatile. This is a
>>> tester that will be sent to a factory (somewhere). When a new
>>> product is to be tested, I can e-mail them the test routine which
>>> they then burn into flash (each of these is 0x900 bytes, there can
>>> be up to 0x0a of them).
>>>       
>> Why is this method superior to having a regular bootloader, and you
>> have N applications, where each application is the individual test
>> routine and the common portion? Why do you have create this custom
>> interface which has its own set of problems? Alternatively, creating a
>> custom Makefile to handle building 10 different applications is
>> certainly easier in comparison.
>>     
>
> I agree, thats how I would handle it. Either build a custom linked
> application for each customer or provide the customer with the tools to
> build one of their own. What he is trying to do is in effect create a
> run time program linker.
>
>   
Eric, David etc.,

Thanks for the suggestions but it seems I haven't explained the problem
properly.
The end users of this equipment will be factory operators who cannot
compile, link or do any of these software things.
Thus I have developed an extremely simple (read idiot-proof [i hope])
interface to use with a terminal program (minicom, teraterm etc.).
This is far more simple than any existing boot loader (OK, I *could*
write my own, but I'm too far along now).
The loadable elements are small (0x900) and will only ever be updated
one at a time.
If I compiled and linked the whole lot, then each small change would
requite the sending & loading of 64k of code, which I think is much too
much for these people (and, for compatibilty with modern PCs, the comms.
is run over a USB virtual RS-232 port which produces far too many serial
errors for my liking - but that's another issue).
I have the entire application written and am knocking the last bugs out now.
I confess that GCC seems to me to be mostly something to fight with,
perhaps I have been spoiled in the past using manufacturer's C compliers
that were tailored especially for the target.
I simply require a way to fix absolutely this jump table in memory.
Whether I write it in C or assembler seems to me to be irrelevant, as is
using an array of pointer to functions, because I still have the problem
of fixing these at absolute addresses.

If anyone knows a way to do this, I would very much appreciate it.

Many thanks for all the input,

Robert.