piclist 2001\04\20\125004a >
Thread: Page Switching Problem
face BY : David Cary email (remove spam text)

[Executive summary: When I looked at absolute mode vs. the linker, Olin
Lathrop's system made the most sense to me for handling ROM paging, so I'm using
it. Also, I liked James Cameron's stack-based math package]

Dear Olin Lathrop,

Olin Lathrop <olin_piclistspamspamEMBEDINC.COM> on 2001-04-19 12:45:56 PM wrote:
> I don't like manually allocating anything.
> First, I use the linker.  I don't know why more people don't do this
> I have NEVER yet used absolute mode.

Same for me -- so far all my programs have used the linker.

I hate manually specifying stuff like addresses when I don't even care what the
address is. When I assign a specific address, you can be sure there is a reason.

> You can now group functional blocks into separate modules.  This also
> provides a natural place to document the interfaces between the functional
> blocks.

Yes, the ".inc" files in assembler now act just like the ".h" header files I'm
used to from the C language.

> 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
> once in over two dozen PIC projects

Same for me. Each code module (in its own file) is far less than 1 ROM page.
I got to play with the
 by Nikolai Golovchenko
which is very cool and saved me a *lot* of time.
But at 96 chars * 3 or more words per char, it immediately overflows a single
page (fortunately, I could just cut-and-paste code from
to handle it).

> It is the
> responsibility of the caller (or GOTOer) to set PCLATH to the new page.

It's impossible to get around setting PCLATH here, anyway.

>  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.
> I
> get the impression that I'm preaching to deaf ears, but I'm not sure why.
> Do others think my method is silly, don't "see the light", have something
> better, don't understand the description, don't think it solves the problem,
> or what?  I don't think it's lack of interest because this issue of PCLATH
> and code pages seems to come up every week or two.  Meanwhile I'm cranking
> out reliable, maintainable PIC projects without wasting time on PCLATH bugs.

I think your GCALL is great. Thanks for putting your file online.

I'm just using MPLAB directly right now, your development system sounded a
little complex ... but eventually I'll want to build my projects by typing
"make" or clicking a button (including re-generating fonts from modified font
".png" files), so I'll probably end up with something like your system. Why does
everyone have to re-invent the wheel ?


--- file std.ins.aspic at http://www.embedinc.com/pic
setpage  macro   adr
        pagesel adr
 if fam_16 && (ncodepages == 2) ;need NOP bug workaround ?
mypage   macro
        local   here
        setpage here
--- end file

Um, I've deleted that ``nop'' in my copy of that file. This works for me in code
I have currently running on a 16F877 chip:

--- file std.ins.inc on david's development machine:
mypage   macro
        local   here
        pagesel here

fcall     macro subroutine_name
    lcall subroutine_name
    mypage    ; just in case we do *local* calls or gotos before the next

> this issue of PCLATH
> and code pages seems to come up every week or two.  Meanwhile I'm cranking
> out reliable, maintainable PIC projects without wasting time on PCLATH bugs.
> Olin Lathrop

I'm guessing that people who use your macros or something similar never have a
problem, so they don't even think about it any more. It's newbies who are trying
to write code from scratch and are trying to deal with "pages" and "banks"
manually with BCF and BSF, spending lots of time manually adjusting them, who
get more and more confused and post lots of questions. (Fortunately, my MPASM
quick reference guide lists the PAGESEL, BANKSEL, and BANKISEL pseudo-ops right
up front, so I was saved from most of this confusion).

I'm just using the MPLAB environment directly now, typing code in its editor
(wish I had a editor with proper syntax coloring).

My application (at the moment) is RAM limited and ROM limited, rather than speed
limited. I like
 James Cameron's stack-based math package.
His subroutines are a little longer and slower than some of the super-optimized
macros I've seen here, but I only need 1 copy of this "increment a 32 bit
counter", rather than a separate routine for each counter I have. Since I use a
HP calculator, I'm familiar with stack operations.

I'm pretty sure that recycling common subroutines ("factoring", in FORTH-speak)
saves more bytes than the few I "waste" on extra PCLATH manipulation. Currently
I don't worry about the data stack (it's 8 deep in the 16F87x series I use); if
I ever do overflow it -- well, I'll worry about that then.

-- David Cary

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistserv@spam@spamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


See also: www.piclist.com/techref/power/priswitch.htm?key=switching
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) Page Switching Problem

month overview.

new search...