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

[Stu Bell]

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

I actually agree with the OP about the application and what he is trying
to do. Yes, to a certain extent is an run-time linker, but for this
application it may make the most sense.  His modules can be much smaller
and self-contained.  You can think of the application as a bootloader
extender.

As I've thought more about it, I think the assembly-language jumptable
is probably a better idea than what I presented before.  It is smaller
and a lot less work than my approach.

This is a different approach than most of us might choose, but that does
not make it wrong.  It does mean that he is now on the "bleeding edge"
of what we know about GCC and the AVR and he will be running into
problems that many of us have never encountered.  If he is brave enough
to tackle that, it will be interesting to see the results.

Stu