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

Hi - I need some advice on setting up and using mpasm for a particular
application and would appreciate some help.

I have a suit of 3 .asm files for the 12f629 processor. Call them
a.asm, b.asm, c.asm I want to put together a package of files for
other users in such a way that one of the source files (c.asm) can be
edited by the user, and then linked to the other source files; the
other source files should remain unchanged by the user. I do not want
to release to the users the original source files a.asm & b.asm

The approach I am using is to pre-assemble a.asm and b.asm to produce
relocatable object files a.o and b.o, and distribute these together
with c.asm. After c.asm has been edited by the user, I want mplab to
assemble c.asm and then link it to a.o and b.o to produce the final
executable .hex file.

I reserve ram storage for variables used in c.asm by using the udata
directive in a.asm, and declare the variables as global in a.asm. I
then declare the variables as external in c.asm.

If I assemble a.asm, b.asm, and c.asm together, all works well - no
errors are produced. But if I pre-assemble a and b to produce a.o and
b.o, and then create a project which includes a.o, b.o, and c.asm, I
find that when I build the project, the linker cannot resolve the
external references in c.asm. The error appears as a linker error (no
error is produced while assembling c.asm). I include a linker script
file in the project.

Can anyone tell me what I must do to get the linker to work correctly
in this application ?

Thanks in anticipation, Tigger
------------------------------------

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 )

If you assemble the modules separately, there's no way they can know of the
location of variables in the other.
I think the only way to fix this is to have a list of hard-allocated RAM as
equates or something and use the same list as a .inc in each assembly
process.

Jan Didden

_____

From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of
tigger
Sent: Wednesday, September 17, 2008 1:01 PM
To: p...@yahoogroups.com
Subject: [piclist] mpasm linker - using .cod files

Hi - I need some advice on setting up and using mpasm for a particular
application and would appreciate some help.

I have a suit of 3 .asm files for the 12f629 processor. Call them
a.asm, b.asm, c.asm I want to put together a package of files for
other users in such a way that one of the source files (c.asm) can be
edited by the user, and then linked to the other source files; the
other source files should remain unchanged by the user. I do not want
to release to the users the original source files a.asm & b.asm

The approach I am using is to pre-assemble a.asm and b.asm to produce
relocatable object files a.o and b.o, and distribute these together
with c.asm. After c.asm has been edited by the user, I want mplab to
assemble c.asm and then link it to a.o and b.o to produce the final
executable .hex file.

I reserve ram storage for variables used in c.asm by using the udata
directive in a.asm, and declare the variables as global in a.asm. I
then declare the variables as external in c.asm.

If I assemble a.asm, b.asm, and c.asm together, all works well - no
errors are produced. But if I pre-assemble a and b to produce a.o and
b.o, and then create a project which includes a.o, b.o, and c.asm, I
find that when I build the project, the linker cannot resolve the
external references in c.asm. The error appears as a linker error (no
error is produced while assembling c.asm). I include a linker script
file in the project.

Can anyone tell me what I must do to get the linker to work correctly
in this application ?

Thanks in anticipation, Tigger



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

--- In p...@yahoogroups.com, "Jan Didden / Linear Audio"
wrote:
>
> If you assemble the modules separately, there's no way they can know
>of the
> location of variables in the other.
> I think the only way to fix this is to have a list of hard-allocated
>RAM as
> equates or something and use the same list as a .inc in each assembly
> process.
>
> Jan Didden
>
Hi Jan - thanks for your comments. I have done this and it now links
ok.

I have removed the variables from the udata list and declared them as
fixed locations using equ in both a.asm and c.asm, after referring to
the map file to find suitable free locations. I am happy with this.

However, there is another area where I am less happy. c.asm is used
to define fixed data which varies with different applications of the
software. The data is defined using equ directives at assembly time
(e.g. data1 equ h'1').

The data is then loaded to ram at execution time using subroutines
containing movlf instructions (e.g. movlf data1,dat1 ;dat1 being a
ram location, data1 being the previously defined data).

c.asm contains the loading subroutines, and these are called from
a.asm. I must therefore link the labels of the subroutines from one
module to another as well as the values of the ram locations.

I have done the former by assembling all three modules, and then
finding the values of the labels of the subroutines from the map file.
I then edit the calling and the called modules so that the subroutine
labels are declared using equ directives in both, rather than by using
global and extern. This works, but seems to be very clumsy, and
inflexible, and I feel that there must be another way of doing it.
Any offers ?

Andy
------------------------------------

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 )

----- Original Message -----
From: Jan Didden / Linear Audio
To: p...@yahoogroups.com
Sent: Wednesday, September 17, 2008 7:24 AM
Subject: RE: [piclist] mpasm linker - using .cod files
> If you assemble the modules separately, there's no way they
> can know of the location of variables in the other.

Wrong. The whole point of the linker is to allow you to assemble the files
separately. I regularly use libraries of assembled and tested routines on
multiple projects.

Clearly, there is something else that OP isn't telling us, probably because
he doesn't realize it is a problem.

Are the .o files being included in the project as object files? Is there
some issue with the linker script?

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

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 )

You can fix the subroutines with an ORG statement. But possibly there is a
better way.

Jan Didden

_____

From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of
tigger
Sent: Wednesday, September 17, 2008 4:10 PM
To: p...@yahoogroups.com
Subject: [piclist] Re: mpasm linker - using .o files

--- In piclist@yahoogroups .com, "Jan
Didden / Linear Audio"
wrote:
>
> If you assemble the modules separately, there's no way they can know
>of the
> location of variables in the other.
> I think the only way to fix this is to have a list of hard-allocated
>RAM as
> equates or something and use the same list as a .inc in each assembly
> process.
>
> Jan Didden
>
Hi Jan - thanks for your comments. I have done this and it now links
ok.

I have removed the variables from the udata list and declared them as
fixed locations using equ in both a.asm and c.asm, after referring to
the map file to find suitable free locations. I am happy with this.

However, there is another area where I am less happy. c.asm is used
to define fixed data which varies with different applications of the
software. The data is defined using equ directives at assembly time
(e.g. data1 equ h'1').

The data is then loaded to ram at execution time using subroutines
containing movlf instructions (e.g. movlf data1,dat1 ;dat1 being a
ram location, data1 being the previously defined data).

c.asm contains the loading subroutines, and these are called from
a.asm. I must therefore link the labels of the subroutines from one
module to another as well as the values of the ram locations.

I have done the former by assembling all three modules, and then
finding the values of the labels of the subroutines from the map file.
I then edit the calling and the called modules so that the subroutine
labels are declared using equ directives in both, rather than by using
global and extern. This works, but seems to be very clumsy, and
inflexible, and I feel that there must be another way of doing it.
Any offers ?

Andy



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

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

Hi John, Hi Richard. Thank you for your inputs to this. I feel that
you must be right, and that I am missing something. What I am doing
at present is in defiance of what a linker should do (or rather I am
doing manually what a linker is supposed to do automatically in order
to earn its living).

So if you can identify what it is that I should do in order to get the
linker to function as I want it to I would be grateful.

When I run the project 'wizard' I just add the .o files using the 'add
files to project' button. I do not declare them in any particular
way. I add them in the same way that one would add .asm files.

The script file simply identifies usable areas of memory, so it has
not occurred to me that this is concerned with resolving labels. I
have not thought carefully about the file or included anything special
in it. Should I have done so , if so what ?

I have a thick file of info here on MPLAB, and have read many parts of
it. There are several diagrams showing .o files being created by
different assembly paths (i.e. not being assembled together as one
project) and then being linked, so I am confident that this is a
legitimate requirement. Likewise the librarian is supposed to store
completely independent source files for later linking.

Thanks again for what you have said, and if you can illuminate me
further it would be a great help- Andy G4OEP

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

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 )