> With the C44, we used the EQU statement to set the variables (not
> the best way, I know, but that's how the boss did before I started
> here and you know how that is).

Yes, bad idea, but it was the only choice a long time ago.

> With the demo program, Microchip
> used the RES statement in the various modules.

I'm glad to hear that Microchip is finally producing example code using
the linker.  It used to be that Microchip examples were very badly
written.

> How do you know
> which variable is where?

You don't at assembly time, but the point is you don't need to most of the
time.

> For example, we use a receive buffer. At
> the receive interrupt, we load the literal number of REC1 (start
> of buffer) into the FSR with the auto increment. However, with the
> RES statements spread throughout different modules, I don't see
> how you are guaranteed to have them consecutive.

You aren't, but spreading a "receive buffer" over several modules sounds
really silly.  If you want a contiguous buffer, define it that way:

rec1   res   bufsize          ;receive buffer

> Can I use the ORG statement with RES?

No, see manual.

> IOW, can I put an ORG
> 0x0100 statement before my buffer to have it start in bank 1? Is
> it better to use the CBLOCK statement and, if so, can it be more
> than 8-bit (i.e., CBLOCK 0x0100)?

No, no, and doesn't apply.

However, there are ways to force particular variables to particular
regions or locations.  You can put a section name as a label in front of a
UDATA directive.  The section can then be located in a particular memory
region in the linker control file.  You can also put a fixed address after
a UDATA directive, giving you essentially an ORG capability.

> The RES directive seems to have started the variables at address
> 0x80.

No, the linker did that.

> I would like to have some context saving registers and flag
> registers in the Access Bank - should I use the CBLOCK for that?

Bad idea.  The symbols will be defined but they will be just constants so
there will not be any memory allocation associated with them.  Use the
UDATA_ACS to allocate memory in the access bank.

> One last question (for now), what happens with the variables
> RES-ed in the module, but not made Global? Does the assembler just
> use undeclared RAM space?

That was two, but the assembler has nothing to do with placing RAM
variables.  The linker does that.  There is no difference between how
global and local variables are allocated.  The only difference is whether
other modules can import the symbol.  The linker allocation algorithm is
well described in the manual.

One of the big advantages of using the linker is that a project can be
broken into multiple modules, each with their own local namespace.  For
example, you can write a UART handler module and an A/D handler module and
not worry about name collisions between local labels.  Each module can
have a label "init_hw", for example, without any problem.

> I read through the MPASM w/ MPLINK manual,
> but it just didn't come together for me.

Then read it again.  Now that you've read it thru once, the earlier parts
should make sense the second time.  Start with the "Directive Language"
section of MPASM, then read the entire linker chapter again.  It's all in
there, assuming you generally understand the concept of linkers.  If not,
you need to start with some general computer science text.  The Microchip
documentation assumes you already understand this.

When you're ready, see my PIC development environment at
http://www.embedinc.com/pic.  It uses the linker exclusively, and contains
many examples of allocating variables and the like.  It also contains a
bunch of linker control files that define standard memory regions and
section.  But, my stuff isn't intended to teach you about relocatable code
and linkers in general, only to provide a nice way of using MPASM and
MPLINK.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu