> I remember reading, probably a few times, that using ORG 0 or ORG 0x00
> or similiar is bad practice now that there is something better. What
> *is* the "something better" or the alternate method?

The ORG directive is only bad in that it implies absolute mode.  The better
way of doing things is breaking up your project into separate relocatable
modules.  This implies using the linker.

> Also, how would
> this alternate method work when one is using the interrupts?

Using interrupts and absolute/relative mode are independent of each other.
For an example of implementing interrupts with relative mode, see my
QQQ_INTR.ASPIC template module at http://www.embedinc.com/pic.  You can also
follow the links to the HAL and HOS examples for complete projects using
relative mode and interrupts.

> I've read multiple times that BANKSEL is the "preferred" method to
> select what bank operations are taking place in, as BCF/BSF of the
> STATUS registers is prone to human error. I don't really understand how
> BANKSEL is supposed to be used.

Think of BANKSEL as "set the banks to whatever it takes to access this RAM
location".  The normal beginner method is looking up an SFR, for example,
finding the bank it's in, then manually coding BSF/BCF on RP0 and RP1.  At
best you won't mess up any of those steps and end up with something
identical to BANKSEL.

Go ahead and use BANKSEL for a while until you feel comfortable with what's
going on.  After that, consider that BANKSEL always emits two RP0/RP1
setting instructions whether they were really needed or not.  For example, 2
BANKSELs in a row will emit 4 instructions.  For a beginner project, don't
worry about it.  It may waste an occasional instruction, but it's reliable.
That's one less thing to worry about when your'e trying to get that first
project working.

When you're ready, check out my DBANKIF and related macros in STD.INS.ASPIC
on the same web page I gave a link to above.  These try to keep track at
assembly time of the bank settings, and only emit the minimum instructions
to switch banks.  More than one DBANKIF in a row to the same address won't
emit any more code than one of them.  DBANKIF can be very handy and I use it
a lot, but you have to be aware of what's going on and cooperate with it.
Mostly that means invalidating the assembler assumptions when they could be
wrong, like immediately after a jump target.  That's what UNBANK and related
macros are for.  Other macros automatically invalidate the bank assumptions
at the start and end of subroutines (GLBSUB, LEAVEREST) as part of bigger
jobs.

There are a bunch of other macros and useful features in my PIC development
environment you probably want to check out since you're asking the right
questions.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads