I think the lcall "command" is actually a supplied macro. If you
disassemble the assembled program you find that you now have a line
setting/resetting the appropriate PCLATH bit. followed by a line performing
the call itself. This is fine unless you immediately precede the lcall with
a conditional skip instruction. In this event you only skip the bit
set/clear command but still execute the call (to a local address).

Things can get very confusing & hard to figure what's gone wrong. (I found
this (eventually) the hard way!)

I find it better to avoid the lcall etc. "commands" and  use an obvious
macro. - or just set/clear the PCLATH bit manually.

Richard P



My first (unsuccessful) attempt to locate some routines on Page 1 and to
call them from Page 0 has sent me scrambling for the datasheets and
whatever
other online resources I could find.  There seems be a variety of
approaches
to the PCLATH issue, most of which have confused the daylights out of me.
Perhaps someday I'll be up to the more sophisticated techniques (macros,
etc.), but for now, could I not just make every single CALL in my program
an
LCALL and call it good?  Would that work, or would that cause the PIC's PC
to go on some unwanted long-call sallies?  As always, I would extremely
grateful for any and all guidance.

Rob Robson

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu