Searching \ for 'Recocatable table read with 16x84 (not a faq!)' in subject line. ()
Help us get a faster server
FAQ page: techref.massmind.org/techref/mems.htm?key=table
Search entire site for: 'Recocatable table read with 16x84 (not a faq!)'.

Truncated match.
PICList Thread
'Recocatable table read with 16x84 (not a faq!)'
1998\10\14@103538 by Harri Suomalainen

I've been writing all the code using MPLAB 3.99. I did choose
relocatable objects so that I could reuse code fragment with
ease (perhaps even make librarys).

Table read has to be made with a jump/call table. (With chips
like 16x84 or 12c50x) This is simple when page boundries are
not crossed. With non-relocatable code it is simple in that
case as well. (Covered well in the Microchip AppNotes)

However, with *relocatable* code it seems impossible. Example
of code:

PROG  CODE      ; Relocatable code
       ....
if ( (HIGH TableStart) & 1 )
       bsf PCLATH,0          ; set PCLATH right eg. this way
endif
       ...
       ...     ; make the computed call here
       ...
TableStart
       retlw 1     ; table here
       retlw 2
       ...

This code makes MPLAB complain about the expression being
too complex. (at the if command) Very logical as address is not
know before linking. Yet, the address is needed at the time of
code assembly.

Unfortunately this problem does arise with every external label,
even if the external label was defined by putting some table at
*known* (fixed) location. Well, it is still external and therefore
not known. A multi-pass assembler would solve this one
with ease.

Anyone found a way around these problems? Perhaps some other
approach that might work? Table reading is very common thing
to need. I'd hate to have to write non-relocatable code just for
that!


--
Harri Suomalainen     spam_OUThabaTakeThisOuTcc.hut.fi

We have phone numbers, why'd we need IP-numbers? - a person in a bus

1998\10\27@144616 by John Payson

1998\10\28@023643 by Morgan Olsson

At 13:46 1998-10-27 -0600, John Payson wrote:
>>Table read has to be made with a jump/call table. (With chips
>>like 16x84 or 12c50x) This is simple when page boundries are
>>not crossed. With non-relocatable code it is simple in that
>>case as well. (Covered well in the Microchip AppNotes)
>
-snip-
>
>I think you could probably do something like:
>
>        ;movwf  TableOffset,w   ; If needed...
>        movlw   HIGH    TableStart
>        movwf   PCLATH
>        movlw   LOW     TableStart      ; Find out the state of the carry
flag
>        addwf   TableOffset,w
>        btfsc   C
>         incf   PCLATH
>        movwf   PCL
>
>Pretty annoying code, though

I can't think of anything more versatile.

But to minimize size and time, we can just let the *compiler* check if the
table crosses a page boundary, and if so warn us.

I use this style:

adtable:
       VARIABLE tablestart = $       ; <-- REMEMBER BEGINNING
       addwf   PCL,F
       retlw   b'00000010'             ; our table...
;etc...
       retlw   b'10010010'
       IF high $ != high adtable     ;<-- COMPARE HIGH BYTE OF START WITH HIG
H BYTE
OF END
               ERROR "addwf PCL overflow in table!"
       ENDIF

So, if we get this error, we either relocate the table, or add Johns code
for run-time method  solution above.

It would have been wonderful if we could have a way to set a variable and
then trigger a second pass for the compiler.  Then we could make some kind
of automated selection of what to  compile, based on earlier compile pass
errors.

(A whish for next MPLAB)

/Morgan
       Morgan Olsson                   ph  +46(0)414 70741
       MORGANS REGLERTEKNIK            fax +46(0)414 70331
       H€LLEKS    (in A-Z letters: "HALLEKAS")
       SE-277 35 KIVIK, SWEDEN         .....mrtKILLspam@spam@iname.com
______________________________________________________________

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...