piclist 2001\01\09\095331a >
Thread: Anyone have a solid strategy for code that spans pages?
www.piclist.com/techref/microchip/devices.htm?key=pic
face picon face BY : Olin Lathrop email (remove spam text)



> There is always something that has a problem with running in a certain
page
> or being accessed from another page. To save me from
> death-through-debugging, I wanted to ask the group what strategies people
> had for managing large code the spans pages on these chips.

I make each code page a separate linker section.  This guarantees that each
module is entirely on one page.  I also make it a convention that PCLATH is
set for the page the code is on.  If you do these two things, then you can
always do local GOTOs and CALLs without having to worry about paging.  You
only have to set PCLATH when jumping or calling to an external routine.  You
also have to reset PCLATH to the current page after a return from an
external subroutine.

I use a bunch of macros to make this easy.  See http://www.embedinc.com/pic.
Take a look at the macros GCALL (global call), MCALL (module call), and
GJUMP (global jump) in STD.INS.ASPIC.  These rely on page switching macros
like SETPAGE and MYPAGE.  Note that SETPAGE works around the PAGESEL bug.
(Didn't know there was a PAGESEL bug, did ya?)

> It is a bit more complex than saying "Put the less-used subs in Page 1" as
> nothing in my code is much less used than anything else.

Right.  If you do what I suggested above then you just let the linker plunk
each module wherever it wants.  The only things you need to put at specific
addresses are the startup vector and the interrupt routine.  (In theory you
could put the interrupt routine anywhere as long as the vector is at the
right location, but I always start the interrupt routine right at the vector
address.  This saves a few instructions on every interrupt, and it also
allows for optimizations in the interrupt routine if you know it is always
in page 0.  For example, you can to a CLRF PCLATH instead of loading it with
the some non-zero value).

> A typical problem is as follows: You have a large number of calls to a
> subroutine from various spots, all residing in page 0. You decide to move
> the subroutine to page 1, because you're desperate for space in page 0.

There's your problem.  You shouldn't be messing with page allocations
manually.  Doing it yourself is error prone and makes the code difficult to
maintain.

> I am interested to hear if anyone has been down this path before and
thought
> out a really good way to have a large piece of code with LOTS of
subroutines
> run happily across multiple pages with minimal page swapping macros.

Yup, I've done multi-page projects many times without having to deal with
this stuff.  Just don't worry about the small number of extra instructions
it takes to call accross page boundaries.  The vast majority of times, two
or three extra cycles isn't an issue when you are calling an external
subroutine.  If it is, then maybe you should put the code in a macro in an
include file and insert it in line when speed is important.  Since 2
instructions make a difference, the "subroutine" code is presumably small.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, TakeThisOuTolin.....spamspamembedinc.com, http://www.embedinc.com

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


<002101c07a4b$212d80e0$260bf6cd@pc> 7bit

See also: www.piclist.com/techref/microchip/devices.htm?key=pic
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Anyone have a solid strategy for code that spans pages?

month overview.

new search...