Searching \ for '[PIC]: Lookup table with >256 elements' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=table
Search entire site for: 'Lookup table with >256 elements'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Lookup table with >256 elements'
2002\08\25@175835 by Bernard Boudet

flavicon
face
Hi,

I need to implement a lookup table for about 1500 8-bit values.  This is
on a 16F628.  The table read will be made from an interrupt routine.

The index for the lookup would obviously need to be supplied in two
registers.  Does anyone have some working, and preferably commented,
code that they are able to share?

I did search back through the archives, but while there were some
discussions that might (together with AN556) help me to eventually code
my own routine, it seems there are several traps to watch out for.

I noticed also that many people save and restore PCLATH in interrupt
service routines, something I have not done before.  Presumably this is
something I will have to do now?

What rule of thumb should one apply to determine if saving PCLATH in an
ISR is required?

Cheers,
-bernie.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\25@182207 by Olin Lathrop

face picon face
part 1 1593 bytes content-type:text/plain; (decoded 7bit)

> I need to implement a lookup table for about 1500 8-bit values.  This is
> on a 16F628.  The table read will be made from an interrupt routine.

That doesn't leave much space for code since the 16F628 only has 2K words of
program memory.  The remaining 1/2 K won't go very far.

> The index for the lookup would obviously need to be supplied in two
> registers.  Does anyone have some working, and preferably commented,
> code that they are able to share?

This processor can't read its own program memory directly, so you have to
use the RETLW method of building a table.  The attached file
LOOKINC.INS.ASPIC is one of several routines I have for providing an easy
interface for such tables.

> I noticed also that many people save and restore PCLATH in interrupt
> service routines, something I have not done before.  Presumably this is
> something I will have to do now?

You only need to save/restore what you clobber during the interrupt.  The
16F628 only has one code page, so you would usually not need to save/restore
PCLATH each interrupt on this processor.  On processors with multiple code
pages you will need to set PCLATH to the interrupt code if it contains any
GOTOs or CALLs.  That is pretty much all the time, so my interrupt routine
template saves/restores PCLATH on such processors and doesn't on processors
with single code pages.  See QQQ_INTR.ASPIC at http://www.embedinc.com/pic.
In your case you will be actively stomping on PCLATH in the interrupt in the
table lookup code, so you have to save/restore it.


part 2 1310 bytes content-type:application/octet-stream; (decode)

part 3 328 bytes

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\26@133528 by Bernard Boudet

flavicon
face
> > I need to implement a lookup table for about 1500 8-bit values.  This is
> > on a 16F628.  The table read will be made from an interrupt routine.
>
> That doesn't leave much space for code since the 16F628 only has 2K words of
> program memory.  The remaining 1/2 K won't go very far.

Yep, but it doesn't have to do much else.  Just read successive lookup
values and write them to an output port at a specific periodic rate.

> This processor can't read its own program memory directly, so you have to
> use the RETLW method of building a table.  The attached file
> LOOKINC.INS.ASPIC is one of several routines I have for providing an easy
> interface for such tables.

Thanks.  I have used the RETLW method before, but always avoided the
PCLATH issue.  Your code expects REG1 and REG2 to already hold the
computed goto, but that was easy enough to figure out:

       movlw HIGH table
       movwf reg2
       movlw LOW table
       movwf reg1

> In your case you will be actively stomping on PCLATH in the interrupt in the
> table lookup code, so you have to save/restore it.

But only if PCLATH is used outside the interrupt routine too, otherwise
I can stomp on it all I like, right?  (Same should go for FSR, and even W).

Cheers,
-bernie.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\26@164038 by Olin Lathrop

face picon face
> > In your case you will be actively stomping on PCLATH in the interrupt in
the
> > table lookup code, so you have to save/restore it.
>
> But only if PCLATH is used outside the interrupt routine too, otherwise
> I can stomp on it all I like, right?  (Same should go for FSR, and even
W).

All true, but unless you really really really need every last cycle this is
a bad idea.  If you aren't doing a table lookup or computed GOTO and are on
a processor with a single code page, you could in theory trash PCLATH in the
interrupt routine.  Trashing FSR is slightly more dangerous because you are
more likely to use it without thinking about it, like an implicit software
stack operation.  Unless the foreground program does nothing (everything is
done in the interrupt), you will need to save W.

All these things are very dangerous because they are bugs just begging to
happen.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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