Hulatt, Jon wrote:
> What is confusing me though, is if I have the linker allocate a
> variable, I do not know where it has put it, hence I don't know which
> bank to select to access it. I know I can select the correct bank with
> "banksel", but surely this means I have to do it every single time I
> access a variable?

Give each section a known name, and allocate variables into specific
spections only.

For example on a normal fully banked machine like 16F876 I define sections
.BANK0, .BANK1, .BANK2, and .BANK3 for the banked RAM and name the single
global RAM section .udata_shr.  I then use assembly constants that define
which bank variables go into.  Global variables go into the GBANK bank,
where GBANK is usually defined as 0.  The constant GBANKADR is
automatically derived from GBANK, and is an address within the GBANK bank
for use with my bank switching macros.

Local variables in individual modules generally go into the LBANK as
defined in that module, and LBANKADR is an address with than bank derived
from LBANK.  Sometimes a module needs a large buffer that you don't want
forced in the same bank as other local variables in that module.  In such
cases, make up a new xxxBANK and xxxBANKADR constants.

You can see all this in action with complete examples at
http://www.embedinc.com/pic.  Note the GBANKADR definition in the project
include file and the LBANKADR definition in each module, and the use of
the DBANKIF and related macros.  All this code assumes the linker control
files that will be in the SOURCE/PIC directory after installation.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.