LookUp tables vs Word variables?

[MPep]

Hi All,

Is it possible to use Word variables with Lookup tables?
Am trying to use it like so:

symbol search = W3
symbol dispcode = W4

Tab2:
lookup search,("D2C3,D2CD,D2D7,D2E1,D2EB,D2F4,D2FE,D307,D310,D319"),dispcode
return

Thing is, is this, in fact, okay to use?

MPep.

 

[Dippy]

Why don't you just try it?

Works for me.
But with a small number of values like that in your LookUp why does search have to be a word sized variable?

If I make search=4 then dispcode is returned as 44 which is ASCII comma - correct.

Or are you asking something else really?

 

[hippy]

I think you want ...

lookup search,($D2C3,$D2CD,$D2D7,$D2E1,$D2EB,$D2F4,$D2FE,$D307,$D310,$D319),dispcode

 

[Dippy]

That new Nuclear Powered crystal ball is good!

 

[boriz]

Maybe it is. But we have yet to learn the long term consequences of exposure.

 

[Janne]

Yes I can confirm that word sized variables work with the lookup table. The only limitation is that the table can only have 255 slots, above that and it goes haywire.. Which I bruntly discovered as I tried loading some ascii art as an easter egg to a picaxe project

edit. What i meant to say that table values greater than 255 work ok, but you can only have 255 values in a table.

 

[westaust55]

Might I suggest to try and avoid using the term "table" with respect to the LOOKUP command. Yes I know that the Rev Ed manual 2 included the term "lookup table" under the LOOKUP part of the manual.
Maybe a "lookup list" might be a better choice of words.

In the LOOKDOWN command description the manual uses the word "list"

The lookdown command should be used when you have a specific value to compare with a pre-known list of options.

However, X1 and X2 parts can have a part of the program memory set up as table memory at the time the program is downloaded (akin to the EEPROM command/directive).

From manual 2:

Some PICAXE chips enable lookup data (e.g. LCD messages) to be embedded in a table within the program (via the table command). This is a very efficient way of storing data. See the ‘table’ command for more details.

This "lookup" data table (hmm "lookup" is not the best choice of terminology here) is then read into variables using the READTABLE command.

 

[MPep]

I think you want ...

lookup search,($D2C3,$D2CD,$D2D7,$D2E1,$D2EB,$D2F4,$D2FE,$D307,$D310,$D319),dispcode

This does work. Thanks Hippy.
Initially had something like this, but included the quotation, 'speech', marks as shown in the example in the manual. eg("Hello world")

@WA,
I agree that the manual appears confusing regarding TABLE, LOOKUP, and LOOKDOWN.

My impression was that TABLE is only good for 256 bytes, whereas with LOOKUP I can have multiple entries under differing Labels. Each having a maximum of 256 bytes. In my example I have Tab2. I also have a Tab1, 3, 4.
I need to use 400 bytes, but with the extra "$" makes it 600 bytes.

If my understanding of this issue is incorrect, please correct me.

@Janne,
I did understand THAT issue correctly.

Thanks all.

MPep.

 

[hippy]

Each LOOKUP is limited to 256 entries, but each entry can be bit, byte or word.

I'm not sure how you mean you need to use 400 bytes but the extra $ makes it 600, and how are you measuring these bytes ? If it's from the Memory Used message on Syntax Check or Download, that will show a higher number of bytes used than number of entries as the LOOKUP has some overhead which can be thought of as having the commas of the LOOKUP stored - for the techinally minded it's a 'new entry follows' flag plus an indicator of how big the next entry is.

 

[MPep]

Hi all,

My application requires 200 Word constants to be able to be looked up. Not including the '$' sign.
Therefore I require 600 bytes, total, to be stored and available.
I am selecting which separate array to use by means of Select/Case.
So far, working well. At least in the simulator, no hardware yet.

Must admit, my opinion, that the manual is not 100% clear on how a LookUp array can be set up. I certainly understand how to use it.
As far as LookDown is concerned, I don't fully understand the difference to LookUp.

My question has been answered, and I certainly appreciate it.

MPep.

 

[westaust55]

It is not as simple as 200 entries each need 3 bytes and thus 600 bytes of memory in total.

The "$" symbol itself is not an extra byte as the $D2C3 is just 53,594 which takes 2 bytes to store. You need to think about how we represent data for ourselves to understand versus how a value is store in PIC memory

$D2C3 0xD2C3 take different numbers of characters in the PE and .bas file but are stored in the PICAXE with 2 bytes.

If you take your program snippet,
With no LOOKUP = 4 bytes
with 1 value in lookup = 9 bytes - most of the extra 5 bytes are the code for the lookup not the data values
with 2 values in lookup = 11 bytes - 1 extra entry = 2 bytes (as expected for a word variable)
with 6 values in lookup = 22 bytes - need 8 bytes for 4 extra words plus some more overhead
with 10 values in lookup = 32 bytes - need 8 bytes for 4 extra words plus some overheads


Seems as a rough estimate that each word value takes on average 2.5 bytes allowing approx 0.5 bytes per data entry for program overheads so allowing for overheads untested but 200 words variables might need 500 bytes not 600 bytes.

 

[MPep]

Thanks WA. Understood.

 

[hippy]

My application requires 200 Word constants to be able to be looked up. Not including the '$' sign. Therefore I require 600 bytes, total, to be stored and available.

This is what was confusing me; 200 words would be 400 bytes.

You could use SELECT-CASE and LOOKUP entirely.

You could store 256 bytes in Data Eeprom and handle the rest through SELECT-CASE and/or LOOKUP.

On the X2's you can store 200 in Data Eeprom and 200 in Table.

On the 28X2 and 40X2 you could copy the data ( from wherever stored ) when the program initialises and keep all 200 words / 400 bytes in Scratchpad for subsequent program execution to use. That would likely be the most efficient way of doing things if you can do that.

 

[MPep]

This is what was confusing me; 200 words would be 400 bytes.

You could use SELECT-CASE and LOOKUP entirely.

You could store 256 bytes in Data Eeprom and handle the rest through SELECT-CASE and/or LOOKUP.

On the X2's you can store 200 in Data Eeprom and 200 in Table.

On the 28X2 and 40X2 you could copy the data ( from wherever stored ) when the program initialises and keep all 200 words / 400 bytes in Scratchpad for subsequent program execution to use. That would likely be the most efficient way of doing things if you can do that.

Sooo.... Data EEPROM and Table are different locations?

Speed in my case is not too important. Completely set by other factors such as quadrature encoder rotation.

I understand now that the '$' is not stored, having thought about it some more.

Will keep using SELECT-CASE and LOOKUP as this works for me, as I understand these.

 

[hippy]

Yes, Data Eeprom and Table are separate and both non-volatile, remain intact through power-cycles and program resets.

Table lets you pre-store up to 256 bytes of data which cannot be changed at run time. Use READTABLE to read.

Data/Eeprom lets you pre-store 256 bytes of data which can be changed at run-time if one chooses to. Use READ to read, and WRITE to update the data stored.

 

[westaust55]

Or . . . if you have an X1 part laying around (28X1 or 40X1) they also have both EEPROM and Table memory like the X2 parts.

Table memory is (when used) actually a part of flash program memory where your BASIC program is downloaded to.

 

[MPep]

In that case gents, are there any problems having these arrays embedded as part of my code?
AFAIK, there should not be any issues with losing data. Correct?

Or is this more to use 'correct' coding techniques?

 

[westaust55]

No issues with embedded data.

As hippy has already mentioned, EEPROM and TABLE memory will retain their contents when power is removed.

Go for it . . . .

 

[MPep]

I did think that embedded data would not be lost either.
So, in this case, 1/2 dozen of one OR 6 of the other.

Thanks for clarification.

Each LOOKUP is limited to 256 entries, but each entry can be bit, byte or word.

This bit of info should be included in the manual as this is not implied.
Yes, just re-read that bit of info and understood its implications.
Rethinking things as suggested, I only need to worry about 200 entries, in WORD variable form.
Therefore SELECT-CASE is not required, just a straight LOOKUP. Certainly simplifies things somewhat.


For others reading this post, if more than 256 entries are required to be stored, then you need to use IF...THEN, or SELECT-CASE to select the appropriate array.

Thanks all,
MPep.

 

[westaust55]

A thought:

200 entries:

put the high bytes in say EEPROM and the low byte in TABLE memory.

Then for one required word value:

reference pointer in say b1 (in the range 0 to 199

word variable to go into say w4 (= b9:b8)

so
READ b1, b9
READTABLE b1, b8



otherwise you can use word variables in both area but then need to do a text
IF pointer > 199 THEN
READ pointer, WORD w4
ELSE
READTABLE pointer, WORD w4
ENDIF

and pointer must be incremented in steps of 2
ie pointer = index *2 ; where index is in the range 0 to 199 for 200 entries

 

[MPep]

READ b1, b9
READTABLE b1, b8

I like that method. I could actually use that, incase some of the values need adjustment.
I am presently storing frequency setting codes for a LTC6903/4. Datasheet here.