Searching \ for '[PIC]: A table question.' 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: 'A table question.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: A table question.'
2001\05\30@114618 by Roman Black

flavicon
face
Hi, has anyone done a table-less data table??

I have run out of room on a 12-core PIC and
need a small table.

I have tried:

       movlw 23        (table data byte)
       decf count,f
       skpnz
       goto table_exit
       movlw 71        (next data byte)
       decf count,f
       skpnz
       goto table_exit

But this is 4 bytes per table data byte.
Does anyone have a more efficient system?

I have thought about placing a table in
a ram bank, then using FSR to address it as
the 16C505 can address any ram with FSR without
bank switching. I think this will get me
2 bytes rom = 1 table data byte. But it is messy.

Any suggestions from the PIC masters? :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@124422 by Andrew Warren

face
flavicon
face
Roman Black <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> Hi, has anyone done a table-less data table??
>
> I have run out of room on a 12-core PIC and
> need a small table.

   Roman:

   If you don't need it to be fast (and if you can put the code in
   the lower half of a page), you can do this:

       MOVF    COUNT,W
       ADDWF   PC
       XORLW   A ^ (B ^ 1)      ;When COUNT = 0, W = A
       XORLW   B ^ 1 ^ (C ^ 2)  ;When COUNT = 1, W = B
       XORLW   C ^ 2 ^ (D ^ 3)  ;When COUNT = 2, W = C
       XORLW   D ^ 3            ;When COUNT = 3, W = D

   -Andy

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@125748 by Olin Lathrop

face picon face
> Hi, has anyone done a table-less data table??
>
> I have run out of room on a 12-core PIC and
> need a small table.
>
> I have tried:
>
>         movlw 23        (table data byte)
>         decf count,f
>         skpnz
>         goto table_exit
>         movlw 71        (next data byte)
>         decf count,f
>         skpnz
>         goto table_exit
>
> But this is 4 bytes per table data byte.
> Does anyone have a more efficient system?

How many table entries are there?  Unless the table is very small, a normal
table will be more compact than what you did above.  Are you totally out of
room or just room in the first 256 locations?

What volume will you be producing these in?  If the volumes are small, then
just getting a bigger PIC for an extra dollar or two will be much cheaper
than spending a lot of time trying to squeeze twenty pounds of code into a
ten pound PIC.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@130955 by Roman Black

flavicon
face
Andrew Warren wrote:
{Quote hidden}

Hi Andy, yes I had seen that clever system the
last time it was mentioned here. (Was that you?)
Unfortunately I can't use the bottom half of
a page, as there is no room left there. :o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@131159 by Bob Ammerman

picon face
And why can't you use a normal ADDWF PCL,F table?

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

{Original Message removed}

2001\05\30@131346 by Roman Black

flavicon
face
Olin Lathrop wrote:
{Quote hidden}

Hi Olin, yes I have no room in any table-able
area. This is a 12-core device and I have room
left in the non-table-able areas. :o)

Hence the need to make a table using some other
system. I only need about 20 entries, and can do
it with 80 words as shown above, but would prefer
60 words. Surely someone has already done this?
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@131747 by Roman Black

flavicon
face
Bob Ammerman wrote:
>
> And why can't you use a normal ADDWF PCL,F table?


Wow! Everyone on the piclist is deaf tonight! ;o)

It is a 12-core PIC, you can only put calls and
computed gotos on the bottom 256byte blocks. Those
are all full of other tables. I need a sane way
of adding a small table in another area (a high
block where tables are not possible). I can do it
with the 4:1 system I showed but that is very
unpolished. Surely someone has done this before?
:o)
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@140451 by Bob Ammerman

picon face
Use:

   movlw    tabstart
   movwf    FSR

   movlw    value1
   movwf    INDF
   incf         FSR,F

   movlw    value2
   movwf    INDF
   incf         FSR,F
   .
   .
   .

to load a table into RAM, then access it with FSR.

or:
       decf    count,f
       skpnz
       retlw    value1
       decf    count,f
       skpnz
       retlw    value2
       ...

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

{Original Message removed}

2001\05\30@140847 by Bob Ammerman

picon face
I knew it, I knew it...

There _is_ a two instruction per entry technique!

   movlw     value1^value2^value3
   decfsz    count,F
   xorlw       value1
   decfsz    count,F
   xorlw       value2
   decfsz    count,F
   xorlw       value3
   etc.

Notice what happens:

If count == 1 on entry then all the xor's except value1 occur,
leaving 'value1' in W.

If count == 2 on entry then all the xor's except value2 occur,
leaving 'value2' in W.

If count == 3 on entry then all the xor's except value3 occur,
leaving 'value3' in W.

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




{Original Message removed}

2001\05\30@142900 by O'Reilly John E NORC

flavicon
face
Would this work?

       comf            count,F
       incfsz  count,F
       retlw           value1
       incfsz  count,F
       retlw           value2
       incfsz  count,F
       retlw           value3
       incfsz  count,F
       retlw           value4
       incfsz  count,F
       retlw           value5
       etc.


John

{Original Message removed}

2001\05\30@143333 by David Cary

flavicon
face
Dear Roman Black,

Roman Black <spamBeGonefastvidspamBeGonespamEZY.NET.AU> on 2001-05-30 12:13:27 PM asked,
...
>a 12-core PIC, you can only put calls and
>computed gotos on the bottom 256byte blocks. Those
>are all full of other tables. I need a sane way
>of adding a small table in another area (a high
>block where tables are not possible). I can do it
>with the 4:1 system I showed but that is very
>unpolished. Surely someone has done this before?
>:o)
>-Roman

Hm, interesting challenge. How about something like

 ; warning, untested code by david cary
  UDATA
i res 1
 ...
 CODE
 ; somewhere in the bottom of a 256 byte block
lookup:     ; just 1 instruction needed in LO memory
 goto real_table_start
 ...
 call lookup ; w = table[i].
 ; now table[i] is in w, or if i was out of range, the default value is in w.
 ...
 ; OK to put in HI memory. (Also OK to put in LO memory, but then, what's the
point ?)
real_table_start:
 tstf i
 skpnz
 retlw Z ; for 0 == i
 decf i
 skpnz
 retlw A ; for 1 == i
 decf i
 skpnz
 retlw B ; for 2 == i
 decf i
 skpnz
 retlw C ; for 3 == i
 retlw default_value ; catches all other values of i.

I count 15 instructions / 5 values = 3 instructions/value. This looks easy to
extend to 256 values.

Here's something a little more compact, but it is limited to 9 possible values,
and the indexing is a little odd:

 ; warning: untested code by david cary
real_table_start:
 btfsc i,7
   retlw A ; for 0x80 <= i <= 0xFF
 btfsc i,6
   retlw B ; for 0x40 <= i < 0x80
 btfsc i,5
   retlw C ; for 0x20 <= i < 0x40
 btfsc i,4
   retlw D ; for 0x10 <= i < 0x20
 btfsc i,3
   retlw E ; for 8 <= i < 0x10
 btfsc i,2
   retlw F ; for 4 <= i < 8
 btfsc i,1
   retlw G ; for 2 <= i < 4
 btfsc i,0
   retlw H ; for 1 == i
   retlw J ; for 0 == i.

If some of your large tables are "smooth", you might be able to compress them,
then (at runtime) use interpolation to approximate the missing values. This is a
classic time/space tradoff. It's generally easier to find some way to compress a
big block of data than to try to individually compress little pieces one at a
time.

--
David Cary

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@143650 by Bob Ammerman

picon face
Sorry, John. This wouldn't go.

if count starts out with any value other than 1 it will return 'value1'.

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

----- Original Message -----
From: "O'Reilly John E NORC" <RemoveMEOReillyJEspamTakeThisOuTCORONA.NAVY.MIL>
To: <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Sent: Wednesday, May 30, 2001 2:20 PM
Subject: Re: [PIC]: A table question.


{Quote hidden}

> {Original Message removed}

2001\05\30@143653 by Andrew Warren

flavicon
face
Roman Black <EraseMEPICLISTspammitvma.mit.edu> wrote:

> >     If you don't need it to be fast (and if you can put the code in
> >     the lower half of a page), you can do this:
> >
> >         MOVF    COUNT,W
> >         ADDWF   PC
> >         XORLW   A ^ (B ^ 1)      ;When COUNT = 0, W = A
> >         XORLW   B ^ 1 ^ (C ^ 2)  ;When COUNT = 1, W = B
> >         XORLW   C ^ 2 ^ (D ^ 3)  ;When COUNT = 2, W = C
> >         XORLW   D ^ 3            ;When COUNT = 3, W = D
>
> Hi Andy, yes I had seen that clever system the
> last time it was mentioned here. (Was that you?)

   Roman:

   It may have been me, although I usually post it with ADDLWs
   rather than XORLWs.  If you saw it with XORLWs before, it was
   probably someone else.

> Unfortunately I can't use the bottom half of
> a page, as there is no room left there.

   Oh, ok... I thought that maybe you just couldn't spare a stack
   level for a CALL.

   If you have to locate the code in the upper half of a page, use
   Bob Ammerman's "DECFSZ" code.

   -Andy


=== Andrew Warren --- RemoveMEaiwEraseMEspamEraseMEcypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@144530 by Andrew Warren

flavicon
face
Bob Ammerman <RemoveMEPICLISTTakeThisOuTspamspammitvma.mit.edu> wrote:

>     movlw    tabstart
>     movwf    FSR
>
>     movlw    value1
>     movwf    INDF
>     incf         FSR,F
>
>     movlw    value2
>     movwf    INDF
>     incf         FSR,F
>     ....
>
> to load a table into RAM

Haven't had any coffee yet, Bob?

   movlw   value1
   movwf   tabstart

   movlw   value2
   movwf   tabstart+1
   ....

-Andrew


=== Andrew Warren --- EraseMEaiwspamspamspamBeGonecypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@145732 by Bob Ammerman

picon face
----- Original Message -----
From: "Andrew Warren" <aiwSTOPspamspamspam_OUTCYPRESS.COM>
To: <spamBeGonePICLISTSTOPspamspamEraseMEMITVMA.MIT.EDU>
Sent: Wednesday, May 30, 2001 2:35 PM
Subject: Re: [PIC]: A table question.


{Quote hidden}

Duh....

Looking for the tricky answer and look what it does to you.  But I do like
my DECFSZ/XORLW technique.

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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@151216 by joan

flavicon
face
What about a computed goto ? I have never used 12 bit CPUs,
but with 14 bit ones, it works :

       ...
       call table      ;w contains the table index
       ...             ;when returning, W contains table(index)

table   addwf   PCL,F
       retlw   '1'
       retlw '2'
       ....

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv.....spamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@154914 by Byron A Jeff

face picon face
On Wed, May 30, 2001 at 09:08:10PM +0200, Joan Ilari wrote:
> What about a computed goto ? I have never used 12 bit CPUs,
> but with 14 bit ones, it works :
>
>         ...
>         call table      ;w contains the table index
>         ...             ;when returning, W contains table(index)
>
> table   addwf   PCL,F
>         retlw   '1'
>         retlw '2'
>         ....

Joan,

As Roman pointed out in his initial message, it's a 12 bit PIC. They have
this rather bizarre rule that computed goto's and calls can only occur in
the first 256 bytes of a page.

So what Roman means by "run out of room" is that all the computable parts
of the PIC are already filled with computed goto table code.

So the challenge is how to simulate a computed goto table without actually
using a computed goto.

BAJ
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@162645 by Olin Lathrop

face picon face
> Hi Olin, yes I have no room in any table-able
> area. This is a 12-core device and I have room
> left in the non-table-able areas. :o)

The the entire memory is table-able, just not call-able.  The entire PC is
still stacked, so the RETLW instruction works anywhere.  You could put a
small stub in the call-able area that GOTOs to elsewhere, then put the
normal table code there.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinEraseMEspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@164513 by Andrew Warren

flavicon
face
Olin Lathrop <@spam@PICLISTRemoveMEspamEraseMEmitvma.mit.edu> wrote:

> The the entire memory [in a 12-bit PIC] is table-able, just not
> call-able.  The entire PC is still stacked, so the RETLW
> instruction works anywhere.  You could put a small stub in the
> call-able area that GOTOs to elsewhere, then put the normal table
> code there.

   Olin:

   I guess you haven't used 12-bit PICs much.

   As Microchip clearly explain in their PIC12 data sheets, any
   instruction that directly modifies the PC (like, say, the ADDWF
   PC at the start of "normal table code") will clear all but the
   low 8 bits of the PC.  The entire memory is NOT "table-able";
   tables must fit ENTIRELY within the lower half of a page.

   -Andrew


=== Andrew Warren --- EraseMEaiwspam@spam@cypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspam_OUTspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\05\30@164535 by Bob Ammerman

picon face
----- Original Message -----
From: "Olin Lathrop" <spamBeGoneolin_piclistEraseMEspamEMBEDINC.COM>
To: <PICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Wednesday, May 30, 2001 4:11 PM
Subject: Re: [PIC]: A table question.


{Quote hidden}

Except that, on a 12-bit core, the target of all ADDWF PCL,F instructions is
also restricted to the first  have of each 512 instruction page.

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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listserv@spam@spamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\05\31@041948 by Vasile Surducan

flavicon
face
On Wed, 30 May 2001, Byron A Jeff wrote:

-- snip
>
> So the challenge is how to simulate a computed goto table without actually
> using a computed goto.
>

 There is an example on 12C509 from design for dollars contest: DD4018,
playing music from table read. However, for me doesn't work well.
Any ideea?
Thanks,
Vasile







{Quote hidden}

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


2001\05\31@043719 by Jim Robertson

flavicon
face
At 11:32 AM 30/05/01 -0700, you wrote:
{Quote hidden}

I posted my bit banged, variable baud rate, RS232 routines for a 16C57
that used this method but it was a l-o-n-g time ago. Maybe that is
what you saw? Here's an extract:

             ;5=57600 4=38400 3=28800 2=19200 1=9600 0=4800

              movlw 07
              andwf baud,w   ;Remove control bits in upper nibble.
              addwf pc
              xorlw 5eh      ;4800 -1
              xorlw 10h      ;9600 -1
              xorlw 0bh      ;19200 -1
              xorlw 5        ;28800  34
              xorlw 6        ;38400 +4
              xorlw 7        ;57600  -.3
              movwf temp
              decfsz temp
              goto $-1

When I changed to 14-bit core parts I also when for the ADDLW's as they
are easier to calculate! ;-)


-Jim

{Quote hidden}

NEWFOUND ELECTRONICS
RemoveMEnewfoundEraseMEspamKILLspampipeline.com.au
http://www.new-elect.com
MPLAB compatible PIC programmers.

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspam_OUTspamRemoveMEmitvma.mit.edu


2001\05\31@055118 by Roman Black

flavicon
face
Bob, does this actually work?? If so, this is VERY
clever and deserves a place in Piclist history.
My system used 4:1 for a table and was rough, and I
was hoping someone could get a 3:1 system. I never
expected someone to make a straight 2:1 system!!

It's even fairly neat to read, as you would like
in a table of values.

Very impressive. :o)
-Roman



Bob Ammerman wrote:
{Quote hidden}

> {Original Message removed}

2001\05\31@075635 by Olin Lathrop

face picon face
>     I guess you haven't used 12-bit PICs much.
>
>     As Microchip clearly explain in their PIC12 data sheets, any
>     instruction that directly modifies the PC (like, say, the ADDWF
>     PC at the start of "normal table code") will clear all but the
>     low 8 bits of the PC.  The entire memory is NOT "table-able";
>     tables must fit ENTIRELY within the lower half of a page.

Yeah, you're right.  Sorry.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinspamRemoveMEembedinc.com, http://www.embedinc.com

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


2001\05\31@083713 by Bob Ammerman

picon face
Roman,

It is untested, but I am certain it will work.

Thanks for the compliment.

Oh yeah, another feature: its isochronous.

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

{Original Message removed}

2001\05\31@084649 by Bob Ammerman

picon face
A yeah, another neat attribute of this technique:

If 'count' is not a valid value on entry the result will be zero!

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

{Original Message removed}


'[PIC]: A table question.'
2001\06\01@012835 by Dmitry Kiryashov
flavicon
face
Bravo Bob ;)

You really knew it. Fast, simple and amazing.


WBR Dmitry.



Bob Ammerman wrote:
{Quote hidden}

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


2001\06\04@190603 by Mike Mansheim

flavicon
face
> Oh yeah, another feature: its isochronous.

Sorry, this thread's old, but I've been meaning to ask a
question.  I looked up "isochronous" because I didn't
know what it meant:  the definition I got was "time-
dependent" (vs. asynchronous and synchronous).  What
makes this a feature?
Is it because you can count on the routine to take the
same number of cycles each time?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservRemoveMEspamSTOPspammitvma.mit.edu with SET PICList DIGEST in the body


2001\06\04@204155 by Bob Ammerman

picon face
----- Original Message -----
From: "Mike Mansheim" <RemoveMEMichael_J_MansheimKILLspamspamTakeThisOuTGRACO.COM>
To: <spamBeGonePICLISTspam@spam@MITVMA.MIT.EDU>
Sent: Monday, June 04, 2001 7:05 PM
Subject: Re: [PIC]: A table question.


> > Oh yeah, another feature: its isochronous.
>
> Sorry, this thread's old, but I've been meaning to ask a
> question.  I looked up "isochronous" because I didn't
> know what it meant:  the definition I got was "time-
> dependent" (vs. asynchronous and synchronous).  What
> makes this a feature?
> Is it because you can count on the routine to take the
> same number of cycles each time?

Yep, that's exactly right.

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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\06\05@174526 by Mike Mansheim

flavicon
face
>>> Oh yeah, another feature: its isochronous.

>> Is it because you can count on the routine to take the
>> same number of cycles each time?

> Yep, that's exactly right.

Thanks!

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspammitvma.mit.edu


2001\06\06@095357 by Bob Ammerman

picon face
Here is another technique for handling a table in a 'non-tablable' area of a
12-bit-core PIC.

This version takes a little more than 2 instructions per index value, but
uses many fewer cycles for large tables.

The code below handles 16 table entries, but could be expanded or reduced as
needed. To handle non-power-of-two sizes you just stub out the appropriate
parts of the code.

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


get_xxxx:
   btfsc    index,3
   goto    get_1xxx

get_0xxx:
   btfsc    index,2
   goto    get_01xx

get_00xx:
   btfsc    index,1
   goto    get_001x
get_000x:
   btfss    index,0
   retlw    val_for_0000
   retlw    val_for_0001
get_001x:
   btfss    index,0
   retlw    val_for_0010
   retlw    val_for_0011

get_01xx:
   btfsc    index,1
   goto    get_011x
get_010x:
   btfss    index,0
   retlw    val_for_0100
   retlw    val_for_0101
get_011x:
   btfss    index,0
   retlw    val_for_0110
   retlw    val_for_0111

get_1xxx:
   btfsc    index,2
   goto    get_11xx

get_10xx:
   btfsc    index,1
   goto    get_101x
get_100x:
   btfss    index,0
   retlw    val_for_1000
   retlw    val_for_1001
get_101x:
   btfss    index,0
   retlw    val_for_1010
   retlw    val_for_1011

get_11xx:
   btfsc    index,1
   goto    get_111x
get_110x:
   btfss    index,0
   retlw    val_for_1100
   retlw    val_for_1101
get_111x:
   btfss    index,0
   retlw    val_for_1110
   retlw    val_for_1111


{Original Message removed}

2001\06\06@110743 by Roman Black

flavicon
face
Bob Ammerman wrote:
>
> Here is another technique for handling a table in a 'non-tablable' area of a
> 12-bit-core PIC.


Interesting idea Bob. Remember RETLW may cause
problems if not in the lower area of a 256 word page.
This might work in the FIRST byte was in a call-able
page, and the rest overflowed.

I think your other suggestion (XORLW) was better
because it is totally independant of any call/return
boundaries.
:o)
-Roman




{Quote hidden}

> {Original Message removed}

2001\06\06@115744 by Bob Ammerman

picon face
----- Original Message -----
From: "Roman Black" <spam_OUTfastvidspam_OUTspamspam_OUTEZY.NET.AU>
To: <PICLISTspam_OUTspamMITVMA.MIT.EDU>
Sent: Wednesday, June 06, 2001 11:04 AM
Subject: Re: [PIC]: A table question.


> Bob Ammerman wrote:
> >
> > Here is another technique for handling a table in a 'non-tablable' area
of a
> > 12-bit-core PIC.
>
>
> Interesting idea Bob. Remember RETLW may cause
> problems if not in the lower area of a 256 word page.
> This might work in the FIRST byte was in a call-able
> page, and the rest overflowed.

No, Roman, RETLW can occur anywhere and is independent of page boundaries
and upper/lower half boundaries (it'll even return from PA0 == 1 to PA0 == 0
space, or vice-versa).

> I think your other suggestion (XORLW) was better
> because it is totally independant of any call/return
> boundaries.
> :o)
> -Roman

This one has the advantage of shorter code path length at the cost of a few
more instructions.

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

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


2001\06\06@120802 by Roman Black

flavicon
face
Bob Ammerman wrote:
{Quote hidden}

Sure, but the RETLW requires an original CALL, and the
start address that is called must be on a lower block.
So although you can return anywhere the procedure is
limited by having it's very first byte must be positioned
on a legal lower-block. This means that it must use at
least ONE word in a lower block. I understood that,
so I think the XORLW solution is better as it does not
require a single call or return.

Also, isn't your XORLW solution smaller?? Using only
32 words for a 16 byte table?
-Roman

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


2001\06\06@133525 by Bob Ammerman

picon face
Yes: xorlw method is a bit smaller.

Yes: this method requires at least one word in low half of page.

But: this method is significantly faster.

So: horses for courses.

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

{Original Message removed}

2001\06\07@042353 by Roman Black

flavicon
face
Bob Ammerman wrote:
>
> Yes: xorlw method is a bit smaller.
>
> Yes: this method requires at least one word in low half of page.
>
> But: this method is significantly faster.
>
> So: horses for courses.


Yep it's a bit quicker, but a lot messier.
The XORLW system you posted is as neat as
a normal table, and can have more units added
to it at any point or subtracted from it.

Also with a larger table size it would get
significantly smaller (and be MUCH neater).

All in all I thought your XORLW system was
totally brilliant, only takes 2 words per
table byte and is very neat and simple.
Unless speed is the main issue I think it
would be horse chosen for my course. ;o)
-Roman


{Quote hidden}

--
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


2001\06\07@074340 by Bob Ammerman

picon face
{Quote hidden}

Of course ;-)

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

--
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


2001\06\07@103616 by David Cary

flavicon
face
This ``goto tree'' idea Bob Ammerman came up with is very clever.

Of course, this is only useful on 12 bit PICs -- there's faster and smaller
techniques available on 14 bit and 16 bit PICs.

I think Bob confused Roman Black by leaving out one tiny detail -- both the XOR
table and this ``goto tree'' table can go anywhere in memory, and can be called
from anywhere in memory, with no restrictions, period. However, the programmer
must add one instruction in a special location:
<pre>
; jump table
   ....
get_table: ; must be in the ``correct'' half of a 512 byte block !
   goto  get_xxxx ; get_xxxx() itself can be anywhere
add_16:; must be in the ``correct'' half of a 512 byte block !
   goto really_add_16 ; really_add_16() itself can be anywhere
   ....
</pre>
. Then the programmer can call it from anywhere in memory with
<pre>
   call get_table
</pre>
.
Maybe the Original Poster can free up some more space in the "special" half of
each 512 byte block by using indirect subroutine calls like that. That was the
original problem, right -- running out of space in the "special" half ?

If you have N values, this ``goto tree'' table takes up
static instructions = N (retlw table[index]) + N/2 (btfss index,0) + 2*(N/2 - 1)
(btfss... , goto..., in a tree).
So a total of (2.5 N - 2) instructions (a bit worse if N is not a power of 2).
(Not counting the specially-placed GOTO or any CALLs).

It's much faster (fewer dynamic instructions) than the XOR code, but it's not
isochronous, and it takes more static instructions: 2.5 N - 2, vs.  2 N + 1.

Looks like a classic time-space tradoff. I can usually make code run much faster
on average if I am allowed to let the worst-case run really slow. I can usually
make tradeoffs between a fast algorithm that uses more code/RAM, or a slow
algorithm that uses less code/RAM. Once in a long while I feel very proud of
myself for making something run faster (or at least the same) in every case
*and* use less code/RAM.

If the table has enough places with several consecutive duplicate values (for
example, the flat steps near the top of a sine wave), this ``goto tree'' might
take *fewer* static instructions than the XOR code, or even the ADDWF techniques
available on other processors -- the programmer can take out the redundant
test,branch,retlw instructions that all return the same value. In those special
cases, the ``goto tree'' would be faster *and* take less space than any other
table lookup I know.

Bob Ammerman <@spam@RAMMERMANSTOPspamspam@spam@PRODIGY.NET> on 2001-06-06 08:51:22 AM wrote:
>Here is another technique for handling a table in a 'non-tablable' area of a
>12-bit-core PIC.
...
{Quote hidden}

...
> Bob Ammerman wrote:
...
> > There _is_ a two instruction per entry technique!
> >
   ; lookup w := table[count] = { 0, value1, value2, value3, 0, 0, 0, ...};
> >     movlw     value1^value2^value3
> >     decfsz    count,F
> >     xorlw       value1
> >     decfsz    count,F
> >     xorlw       value2
> >     decfsz    count,F
> >     xorlw       value3
   ; Now w contains one of value1, value2, value3, or 0.
   ; If w now contains 0, then Status,Z is set
> >     etc.
...
> > Bob Ammerman

--
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


2001\06\07@161004 by Harold M Hallikainen

picon face
       I'm also impressed with the xorlw technique. I just put it in some code
where I had to pretty much do a switch-case situation where there are
only a few choices and they are not close to each other. A table would've
been huge.

Harold


On Thu, 7 Jun 2001 18:18:56 +1000 Roman Black <fastvidspamBeGonespamspamBeGoneEZY.NET.AU>
writes:
{Quote hidden}

FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
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 2001 , 2002 only
- Today
- New search...