Olin Lathrop wrote:

> I prefer to have the linker file only contain the unique address
> information about the particular chip, and have all application
> decisions in the source files.  I can have one linker file for a
> chip that gets used for all projects for that chip.


Jan-Erik wrote:

> Yes, I see how that works. One (and at the moment only)
> drawback I can see, is that you need to maintain application
> specific LNK files. Personally I try to regard the LNK files as
> PIC-model specific. And most of the time using them as
> they are delivered from Microchip. It's mostly a matter
> of taste, I'd say.



Hi Olin and Jan-Erik,

It all comes down to different viewpoints and whatever works for the
programmer for the task at hand. Variety is the spice of life. :)

Olin, perhaps I'm missing your point in your first sentence in your quote
above, but those string addresses I mentioned *are* within the address range
of the particular chip (and obviously are application-specific). I tend to
view linker files as application-specific since I modify them to fit the
specific application at hand. Currently, for me, it's not a problem making
the linker scripts application-specific. I'm not familiar with actually
using your development environment, but I'm sure your method works great for
you.


However, let me ask you both this question:

Since you both don't seem to like to modify the linker scripts, how do you
handle the situation in which various projects (that use the same PICmicro
and linker scripts) have to have *different* memory sections PROTECTED? A
situation like this would mandate unique linker scripts that use PROTECTED
regions of memory, and thus, you would have to modify the linker scripts,
correct? I don't see any other way.



Ken wrote:

> > App_ID_string                CODE

Olin wrote:

> You could just as well put a label here to get the same effect.  If you
> wanted this to be at a specific address, you could specify that address as
> the CODE directive parameter.  This is how I would do it.

Yes, I'm fully aware of this with regard to the CODE directive, but like I
said in various threads, I usually do not like to specify explicit addresses
(hard-coded) with the CODE directive in the source code (even with reset and
interrupt vectors). I'm not convinced at this point that what you say would
work in the situation outlined in this thread -- remember that this thread
is focused on the new operators that will be eventually documented in the
next release of the 'MPASM User's Guide with MPLINK and MPLIB'. I'm not sure
what you proposed will actually work with these new operators, but I have
not tried it. However I do know that what I previously proposed does work
with these new operators since I tested them out.


Jan-Erik wrote:

> B.t.w, you code example uses PIC18 syntax. I guess that the
> symbols are available when building the a PIC16 also, right ?

Well, you can try it out for other architectures. I have not seen any reason
why they would be PIC18 architecture-specific.


Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist