12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

The help file is indeed full of good information about using the linker.
The MPLINK linker is no different than hundreds of linkers that have gone
before on dozens of operating systems. However, if you don't have that
history, the information in the help files can be a bit daunting.

Let me suggest before wading through the help files (and don't forget the
MPLINK Reference manual), you go over to
http://www.amqrp.org/elmer160/lessons/ and read Lesson 16. It happens to
focus on the PIC16F84, but all the 8 bit PICs are pretty much the same in
this regard. You might also want to have a quick peek at Appendix D.

Without having your code, it is pretty tough to identify what is missing.
It sounds like you have the bases covered, but apparently you are
overlooking something, and without seeing what you have it is only guessing
what that might be.

72/73 de WB8RCR http://www.qsl.net/wb8rcr
didileydadidah QRP-L #1446 Code Warriors #35

----- Original Message -----
From: "rtstofer"
To:
Sent: Wednesday, September 17, 2008 12:26 PM
Subject: [piclist] Re: mpasm linker - using .o files
> --- In p...@yahoogroups.com, "Jan Didden / Linear Audio"
> wrote:
>>
>> You can fix the subroutines with an ORG statement. But possibly
> there is a
>> better way.
>>
>> Jan Didden
>
> You absolutely don't want to do this (pun intended).
>
> Read through the documentation (RTFM) because it talks about how to
> link to object files and how to use UDATA. I'm not on my WinxP box at
> the moment so I can't point to the specific part of the help file but
> there is a LOT of information on separate assembly, relocation and
> linking.
>
> There is a method for declaring global variables so that other files
> will know their address AT LINK TIME. Similarly there is a scheme for
> declaring a variable to be external to the present file so the address
> doesn't have to be known AT ASSEMBLY TIME.
>
> This is all standard stuff for relocating assembler/linkers.
>
> Richard
>
> ------------------------------------
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, "John J. McDonough, WB8RCR"
wrote:
>
> The help file is indeed full of good information about using the
linker.
> The MPLINK linker is no different than hundreds of linkers that
have gone
> before on dozens of operating systems. However, if you don't have
that
> history, the information in the help files can be a bit daunting.
>
> Let me suggest before wading through the help files (and don't
forget the
> MPLINK Reference manual), you go over to
> http://www.amqrp.org/elmer160/lessons/ and read Lesson 16. It
happens to
> focus on the PIC16F84, but all the 8 bit PICs are pretty much the
same in
> this regard. You might also want to have a quick peek at Appendix
D.
>
> Without having your code, it is pretty tough to identify what is
missing.
> It sounds like you have the bases covered, but apparently you are
> overlooking something, and without seeing what you have it is only
guessing
> what that might be.
>
> 72/73 de WB8RCR http://www.qsl.net/wb8rcr
> didileydadidah QRP-L #1446 Code Warriors #35

The provided link points to an extremely good set of tutorials. It
is well worth the time to read and especially lesson 16.

Now, about libraries: Libraries are simply a collection of object
modules. They may be related, like a math library. They may just be
a collection of stuff you want in one file - not necessarily related
to any particular area of application. The librarian just adds and
removes modules.

See http://ww1.microchip.com/downloads/en/DeviceDoc/33014J.pdf

Library modules are not linked, the librarian only cares about
certain symbols (generally function names) and makes no attempt at
resolving links.

The linker just looks at the library as a long list of object
modules. The linker resolves the symbols and produces the loadable
hex file.

If you have multiple object modules that you want to distribute, it
is probably best to distribute them as a single library
(MyCompanyLibrary.lib). Any particular executable need not use (link
to) every module in a library so, as long as module names are
different, one library can cover multiple hardware
devices/platforms/products.

There is one 'gotcha' to libraries depending on the implementation of
the linker: by default, ld (the GCC linker) makes just one pass
through libraries in the order they are listed. If a later library
contains a reference to an earlier library, it will not be resolved.
It may even matter if there are 'backward references' within a
library, I don't know. So, you just need to experiment a bit to see
if mplink will process libraries as you expect. ld does have a
feature to allow recursive linking of libraries but it is NOT the
default.

Ah, the joys of asm, link and lib! Regardless of the platform...

Richard

Richard

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )