[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert von Knobloch
Subject: Re: [avr-gcc-list] Allocating variables to a fixed address
Date: Tue, 12 May 2009 09:26:19 +0200
User-agent: Thunderbird (X11/20060911)

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
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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]