This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C013F2.45625720
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> ...
> PC = 00 is the reset vector   - when the PIC is reset the PC is set to 00
> and the instruction found there is executed. Most often you should put a
> 'goto start' instruction here.

If you ever jump to 0 from your code to do a "reset", then you have to make
sure PCLATH is set before the GOTO.  Since its hard to make effective use of
the 4 instruction locations at 0, I usually do:

     clrf    intcon
     pagesel start
     goto    start

This can use up to all 4 instructions, and allows code anywhere to do a GOTO
0 to perform a complete reset.

> PC = 04 is the interrupt vector   - when an interrupt occurs the current
PC
> is stored on the stack and the PC is set to 04. Most often you should put
a
> 'goto interrupt_routine' instruction here.

I recommend instead putting your interrupt routine right there.  Some code
will end up right after the interrupt vector, so it might as well be the
interrupt routine.

> Most often you should put a 'org  06' instruction in front of your code so
> that the vectors are left well alone.

I don't see much reason on a 16C to ORG executable code anywhere but 0 and
4.  Except in rare cases where you might care about page boundaries, just
let the remaining code end up where it ends up.

Even better, use the linker.  I set up one linker section per page, thereby
guaranteeing that no single module will cross a page boundary.  This means I
can use simple GOTOs and CALLs inside the module and reserve PAGESEL for
external locations.

> Because look-up tables mustn't cross a page boundary you can put them
> exactly where you want. Usually you put them at org 06 and have your code
> start after them (if you have goto start at org 00)

There is no restriction about lookup tables crossing page boundaries.  It
all depends on how carefully you do the table offset math.  There is a
restriction to not crossing 256 word boundaries if you use the rather stupid
lookup code example in the manual.  Lookup tables can be anywhere and large
if you do the full 16 bit arithmetic and load PCLATH appropriately.  I have
standard routines that make this easy.  I've attached one of them as an
example.  This is actaully an include file for reasons that aren't important
here, and it uses my "standard" macros, but you should be able to get the
picture.

------=_NextPart_000_001B_01C013F2.45625720
Content-Type: application/octet-stream;
        name="lookinc.ins.aspic"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="lookinc.ins.aspic"

;   Subroutine LOOKINC
;
;   Perform a table lookup at a specified address, and increment the =
address.
;   On this processor, tables of constants are implemented as successive =
RETLW
;   instructions, each encoded with the specific 8 bit value for that =
table
;   entry.  The 8 bit value from the table is returned in W.  The =
address
;   is passed as follows:
;
;     REG1  -  low byte of table entry address to look up
;     REG2  -  high byte of table entry address to look up
;
;   The table entry address will be incremented by 1.  Successive calls =
to
;   this routine will therefore return successive table values.  Note =
that
;   all manner of destruction can occur if the passed address is not
;   a valid table entry, and therefore not a RETLW instruction.
;
.lookinc code
         glbsub  lookinc, noregs

         movf    reg2, w     ;get entry address high byte
         movwf   pclath      ;set high byte of computed goto

         incf    reg1        ;make low byte address for next time
         skip_nz             ;no carry into upper address byte ?
         incf    reg2        ;propagate carry

         decf    reg1, w     ;make low byte of this table address in W
         movwf   pcl         ;jump to table entry, loads W and returns =
to caller

------=_NextPart_000_001B_01C013F2.45625720--


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olin@cognivis.com, http://www.cognivis.com

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