MPLAB IDE 6.53

[Tim Wescott]

Hi all,
Please excuse me if this seems a daft question, but I am writing a
program in ASM using MPLAB. That is going fine, I have no probs here,
but what I would like to know is (and I'm not that experienced in this
kind of thing) is there a way I can simply break my subroutines into
smaller seperate files and call them on request, or something away from
the main program, since its getting pretty big and it could make things
alot neater to have various completed objects to the program seperate
from the core of it.

Any pointers or advice would be great

Thanks,

Ed

According to Microchip, the MPLAB 6.6 includes a linker. Assuming that
it's there on 6.53 you want to assemble and link separately.

Usually your assembly files will be run through the linker to produce
object files. An object file is a strange intermediate step where the
assembly (or C code) has been turned into machine language, but which
can still have a few locations defined by name instead of number. Then
you run the batch of assembly files through the linker, which looks for
all of the names that you've asked for, and links it all up into an
executable file. MPLAB probably links directly to a hex file, but it may
go through a "loader" as well.

You need to tell the assembler what you're planning with assembler
directives. There will be something like ".export" to tell the
assembler that you want to make a symbol available, and ".import" to
tell the assembler to assume that a symbol is available at link time.
Every assembler has a different syntax, so you'll have to look in your
documentation to see what you have to do.

Expect to dink with this a bit -- I'm a paid professional, and whenever
I use a new toolchain I always have to mess with it some before I get
all my i's dotted and t's crossed just exactly the way the tools want
them to be. A batch file to invoke the assembler and linker is helpful,
when you get frustrated with everything assembling every time you build
you'll want to learn how to use make, but do that on another day.

 

[Ed]

Hi all,
Please excuse me if this seems a daft question, but I am writing a
program in ASM using MPLAB. That is going fine, I have no probs here,
but what I would like to know is (and I'm not that experienced in this
kind of thing) is there a way I can simply break my subroutines into
smaller seperate files and call them on request, or something away from
the main program, since its getting pretty big and it could make things
alot neater to have various completed objects to the program seperate
from the core of it.

Any pointers or advice would be great

Thanks,

Ed

 

[Ed]

According to Microchip, the MPLAB 6.6 includes a linker. Assuming that
it's there on 6.53 you want to assemble and link separately.

Usually your assembly files will be run through the linker to produce
object files. An object file is a strange intermediate step where the
assembly (or C code) has been turned into machine language, but which
can still have a few locations defined by name instead of number. Then
you run the batch of assembly files through the linker, which looks for
all of the names that you've asked for, and links it all up into an
executable file. MPLAB probably links directly to a hex file, but it may
go through a "loader" as well.

You need to tell the assembler what you're planning with assembler
directives. There will be something like ".export" to tell the
assembler that you want to make a symbol available, and ".import" to
tell the assembler to assume that a symbol is available at link time.
Every assembler has a different syntax, so you'll have to look in your
documentation to see what you have to do.

Expect to dink with this a bit -- I'm a paid professional, and whenever
I use a new toolchain I always have to mess with it some before I get
all my i's dotted and t's crossed just exactly the way the tools want
them to be. A batch file to invoke the assembler and linker is helpful,
when you get frustrated with everything assembling every time you build
you'll want to learn how to use make, but do that on another day.

Hi Tim,
Thanks for the quick reply, I'm having a look at it now. Ive never gone
this far with mplab before, and so its as much learning the program as
finding if what I want to do is possible!

It looks like I have to use an intergrated application called MPLINK to
do this. It seems to be the program that handles all the external files.

I think what I shall do is make a backup of all I have done now (which I
should have by now done anyway) and cut a subroutiene out and try making
this work as a seperate linker file. This should be Fun...! I dont yet
know how this will work

Ed

 

[Tim Wescott]

If you're writing big programs you use "include" and linking for two
different things. I would only use "include" instead of linking if I
had a cheap toolchain that didn't support linking.

You make an include file to declare all of the symbols that you make
public in some other file -- so if you have a utility file called 'foo'
that has a subroutine called 'bar' you make 'foo.inc' that declares
'bar'. Then you have 'foo.asm' that actually has the code for 'bar'.
Then if you have a file that uses 'bar' you'd have "include foo.inc",
and you'd use 'bar'.

As part of this you should never put actual code in an include file.
Constant definitions, macros, "import" declarations yes, code, no. This
is such common practice that many debuggers can't deal with code in
include files, or do it badly.

This does several things for you:

1. By linking programs you keep private data private. The file 'foo'
can use a variable called 'x1', the file 'foo2' can use a variable
called 'x1', etc., and as long as they're not exported to the linker
they are all seperate varables (this sounds like a rampant waste of
memory space but surprisingly it's not -- especially if you work hard at
storing variables on the stack by pushing and popping within subroutines).

2. You can always rest assured that the files 'xxx.inc' and 'xxx.asm'
go together. Furthermore, if you are good about commenting you should
only have to look at comments for function definitions in 'xxx.inc' to
see what the functions do (this happens about 30% of the time in
reality, if that much, but it's a noble goal).

3. If you have a file that includes 'xxx.inc' you get a good idea that
the code in your file depends on code in 'xxx.asm'.

 

[Ken Smith]

public in some other file -- so if you have a utility file called 'foo'
that has a subroutine called 'bar' you make 'foo.inc' that declares
'bar'. Then you have 'foo.asm' that actually has the code for 'bar'.
Then if you have a file that uses 'bar' you'd have "include foo.inc",
and you'd use 'bar'.

I have standardized on foo.ext for the externals that go with
foo.asm. There can also be a foo.inc, it declares things like constants
and gets included into foo.asm and by foo.ext so that the routine and the
user of it always agree on the constant.

8051ish Example:

****** main.asm *****
$include(Destruct.ext)

mov a,#DontExplode
lcall DestructArm
.... etc ...


***** Destruct.inc ****

$ifndef DESTRUCT_INC
$set(DESTRUCT_INC)

Explode equ 0
DontExplode equ 1

$endif

***** Destruct.ext ****

$ifndef DESTRUCT_EXT
$set(DESTRUCT_EXT)
$include(Destruct.inc)

extrn code(DestructArm)
$endif

***** Destruct.asm ****

public DestructArm

DestructArm:
cjne a,#Explode,DestructDisarm

mov SDR,#1
ret

DestructDisarm:
mov SDR,#0FEH
ret

****

Now all you need is a make that works right and changes to the constants
in Destruct.inc won't cause a costly mistake.

 

[Activ8]

According to Microchip, the MPLAB 6.6 includes a linker. Assuming that
it's there on 6.53 you want to assemble and link separately.

Usually your assembly files will be run through the linker to produce
object files.

No. The asembler generates object files and the linker links them
and produces an executable.

An object file is a strange intermediate step where the
assembly (or C code) has been turned into machine language, but which
can still have a few locations defined by name instead of number.

I'm not overly thrilled with MPLAB, but I remember when it wouldn't
do relocatable code. It handles that ok now. My first MPLAB didn't
even fixup jumps or calls to labels, it'd leave a goto with some
incorrect address (maybe zero) and you'd have to go through the
listing to find the address assigned to the op code with the line
label and manually put it into the goto - or calculate it from the
..org directives.

Then
you run the batch of assembly files

object files

through the linker, which looks for
all of the names that you've asked for, and links it all up into an
executable file. MPLAB probably links directly to a hex file, but it may
go through a "loader" as well.

You need to tell the assembler what you're planning with assembler
directives. There will be something like ".export" to tell the
assembler that you want to make a symbol available, and ".import"

"global" and "extern" for MPLAB, for the OPs edification. It's all
in the help file under asm directives which is the starting point to
understanding how to get the linker to do relocatable code. It
explains how to declare the data and code blocks and use the linker
(.lkr) files for which there are templates for each PIC.

It all works pretty well these days. I can keep keypad and LCD
modules in separate files and configure them (conditional assembly)
for each application.

to
tell the assembler to assume that a symbol is available at link time.
Every assembler has a different syntax, so you'll have to look in your
documentation to see what you have to do.

Expect to dink with this a bit -- I'm a paid professional, and whenever
I use a new toolchain I always have to mess with it some before I get
all my i's dotted and t's crossed just exactly the way the tools want
them to be. A batch file to invoke the assembler and linker is helpful,
when you get frustrated with everything assembling every time you build
you'll want to learn how to use make, but do that on another day.

Scott Dattalo's gpsim is worth a look as an MPLAB alternative. I may
as well mention Olin Lathrop's toolkit for MPLAB at www.embedinc.com

 

[Rob]

Ed - I've not tried it myself but would the assembler directive - "include"
do this.

Maybe try renaming routines routineXXX.inc and then place the following line
in the main asm file;
include <routineXXX.inc>

Workable??? What is the right way to do this, I am interested also.

rob

 

[Rob]

Thanks Tim, a good reply - now to try it out!

regards
rob