Olin Lathrop wrote:

> First, I use the linker.  I don't know why more people don't do this since
> it's easy and has a number of advantages.  Most of the code I see here has
> ORGs in it, indicating that the assembly is in absolute mode.  I have NEVER
> yet used absolute mode.  The big advantage of using the linker is that code
> can be in separate modules.  This makes things much more maintainable and
> reusable.  Each module also gets its own namespace for local symbols, so you
> don't have to worry about name collision with some unrelated part of the
> code.  You can now group functional blocks into separate modules.  This also
> provides a natural place to document the interfaces between the functional
> blocks.
>
> Since the code is now a collection of relatively small modules, you can
> dictate that each module must be entirely on one page.  I do this by setting
> up a separate linker section for each code page.  Except for the code at the
> startup location and the interrupt routine, I just let the linker stick a
> module wherever it wants to.  It does this quite nicely based on a best fit
> algorithm.  I have never yet had a code module that was bigger than a page,
> or even close to it.  I have had data modules bigger and handled that by
> making separate one-off exceptions in the linker control file for that
> project.  I've only had to do that once in over two dozen PIC projects, and
> that happened to be a personal project.
>
> Now that the code within a module is all guaranteed to be on the same page,
> I use the convention that PCLATH is always pointing to that page.  It is the
> responsibility of the caller (or GOTOer) to set PCLATH to the new page.  I
> can forget about PCLATH when doing GOTOs and CALLs within a module.  To call
> a global routine in some other module, I use the GCALL marco.  This sets
> PCLATH before the call and restores it after.
>
> The GCALL and other macros are in STD.INS.ASPIC which can be found at
> http://www.embedinc.com/pic.  This page also describes a bunch of "standard"
> modules I use with most PIC projects and provides template modules where you
> can fill in the blanks to make your own PIC project.  These are the same
> template files I use when creating a new project.  Click on the "HAL example
> project" link to see the modules and source code for a real project.  You
> can see that the executable part of this project was broken into 9 separate
> modules.


Hi Olin, again thanks for taking the time to disect
your system for us. I have spent the last couple of
days reading chapter 4 of MPASM guide, How to use
relocatable objects, and checking my own projects
I realised i've been doing a similar thing by cut
and pasting my code modules in text format, and
many of my common routines are in separate .asm
files that I include when I need them in the main
.asm file.

I think that it's time to start refining some
of my routines to relocatable modules but i'm a
bit confused as to some of the problems;

Do you use your GCALL macro for every call from
the main routine to the modules?? I understand your
modules use local calls within themselves.
It would be nice if the linker were optimising,
and only inserted the minimum code for any call.

As many modules use the same shared (global) data
to manipulate it, do your modules use banksel on
every access of these variables?? Isn't that slow?

Sorry to fire questions at you, I downloaded the
files from your embedinc.com page and the hal
project also but haven't had the chance to go
right through them yet. :o)
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics