Here is a trick I use to avoid problems with PCLATH/PCLATU and interrupts on
18C chips:

given:
       rcall    lookup_func

instead of:

    <align to page start if needed>
lookup_func:
    addwf    PCL,F,A
    retlw      1
    retlw      2

I have used:

    <align to page start if needed>
lookup_func:
    rcall    lookup_index
    retlw    1
    retlw    2

lookup_index:
    addwf    TOSL,F,A
    return

; For large tables you can:

lookup_index:
    addwf    TOSL,F,A
    btfsc      STATUS,C
    incf        TOSH,F,A
    return

In the program where I use this, I consider PCLATH/PCLATU to be resources
usable _only_ in my interrupt handler. I use the above trick for code at
task level. This seems to work quite well. It saves me the requirement of
saving PCLATH in my interrupt handler (which is _very_ pressed for time).

I have _not_ seen the pattern of MOVFF somehow being interrupted in the
middle. Are you saying that the instruction is basically skipped when this
happens (ie: it doesn't execute before entering the interrupt and it doesn't
execute on return from the interrupt). I'd love more particulars here if
possible.

Also, in regard to the LFSR instruction. As far as I know, all silicon
currently available is broken. Just say _no_ to the instruction. It is a
shame, because this would be a _very_ useful instruction.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: Thomas C. Sefranek <tcs@CMCORP.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Monday, September 18, 2000 9:56 PM
Subject: [PIC]: 18C452 problems


> > I have independently confirmed the reports of LFSR not working...
> > Sometimes!
>
> DON'T try to use it with interrupts!
> It writes the LSB of the pointer at the location it's pointing at!
> Microchip says don't use it at all!
>
> O.K. So I'm reading the "B" version note,
> Where is the "A" note?
> Who has "B" version chips, and what do I have since I bought them months
> ago
> and they have neither A or B markings.  And what do I do with all these
> broken chips?
>
> What else is wrong?
>
> Let me answer that in part...
>
> I have discovered if you have in interrupt happen while using a MOVFF,
> It may NOT complete the 2 part of the instruction,  and when you return
> from interrupt
> You get bogus results...
>
> As Murphy would have it, I'm doing table lookups for a JUMP table and the
> PC get some
> pseudo-random value!
> No, I'm not using MOVFF something, PCL.  That's been pointed out as a
> no-no.
> I am using MOVFF something, WREG, which is specifically encouraged in the
> MOVFF
> instruction manual.  Well the value in WREG get clobbered by interupts...
> sometimes.
> I didn't trust the RETFIE FAST to restore W, so I added my own
> save/restore in the
> interrupt service routine.  Didn't help either way.
>
> I've solved the problem by not using interrupts, but I'm going to HAVE to
> use them soon.
>
> Help me MicroChip, your my only hope.
>
> --
>   *
>   |  __O    Thomas C. Sefranek   tcs@cmcorp.com
>   |_-\<,_   Amateur Radio Operator: WA1RHP
>   (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz
>
> http://hamradio.cmcorp.com/inventory/Inventory.html
> http://www.harvardrepeater.org
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's