Exact match. Not showing close matches.
'[PIC] MPLAB-SIM PCLATH higher bits problem? Please'
Rochester, 8 augustus 2005.
Yesterday I tried to simulate code for the 16F628 with MPSIM. The
following is a routine that is called multiple times:
It is supposed to get the ASCII code of the letter (which is pointed
to by FSR), shift it three bits (ignoring the most significant bit)
and add the line number within the character ("Letterline", from 0-7).
With the most significant bit set, the result is moved into PCLATH/PCL
so that the code jumps there and returns with the appropriate number.
The code works fine when executed on the actual PIC. However, when
simulated in MPLAB-SIM, the result is quite odd. The first time the
routine is called everything is fine, but the second time the value in
PCLATH is correct (0x1D, but because of the 16F628 having only 2KWord
memory, this is 0x05) but even though W is 0x00, when I move W into
PCL, PCL becomes 0x63.
If I do a clrf PCLATH,f at the beginning of Fetchletter, the result is
correct: PCLATH becomes 0x05 and PCL becomes 0x00).
My conclusion is that MPLAB-SIM seems to deal incorrectly with weird
bits set in the upper part of PCLATH, whereas a normal device ignores
these bits and executes normally. Did other people notice this
Also, I realise that it is highly unorthodox to just continue shifting
the bits of PCLATH around like this, and that a clrf PCLATH,f would be
the preferred method of coding, as this would allow compatibility if I
ever upgrade to a PIC16F88 with 4 KWord memory. However, this routine
is in my critical path and needs to be as short as possible. Any
recommendations on making it even shorter are welcome.
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...