Creating a large lookup table with a PIC16F684 (or similiar)

[Steve311]

Hi All, I am trying to create a very large look-up table using a PIC1F684 (or something of the same family if needed like a 1824). I am writing in .asm

The table will consist of 3 input variables (I'll call them X, Y and Z), and from these 3 values which all range from 0x00 to 0xFF, there will be 700 possible outputs (I'll call them A and B).

I need to basically read each X, Y and Z (all 0xFF) and determine the output (0 to 700) that the 3 inputs match up to.

What is the best and most efficient way of doing a table like this? EEPROM?

 

[ChrisP58]

What is the relationship between the values of X, Y, Z and the output?

Would it work to have three tables, one for each of X, Y Z, then do something with the three results to get the output?

 

[Jon Wilder]

Sounds to me like you're going about this in a way that's making it more complicated than it needs to be.

Can you post up a schematic of the circuit as well as an explanation of what you're trying to make the circuit do?

 

[Nigel Goodwin]

If you check my tutorials the 8x8 LED matrix one shows how to implement large tables, like the others I'm a bit bemused about your x, y, z requirement?.

 

[Steve311]

Hi Guys, Sorry for the confusion and thanks for the response. I don't have a detailed schematic as of yet, but I am currently using a Kionix 3-axis accelerometer with a pic16f684 using i2c. The accelerometers outputs X, Y and Z are all unique to one another and non-linear. From rotating the accelerometer, and for my application, there will be 700 different possibles of where X, Y and Z all land at the sample time of the acceleration outputs. I consider it to be 700 outputs.

Due to the outputs being non-linear, I will need some sort of look-up table to produce something like the following :

(When I have all 3 accelerometer outputs sampled and stored for evaluation, I will need to compute "If X = 0x10, and Y = 0x12 and Z = 0x13, then the output is Output 1"). And if the values do not match, then I need to check Output 2...and Loop through the table until it finds the right output.


X Y Z
Output 1 = 0x10 0x12 0x13
Output 2 = 0x20 0x22 0x23
.
.
.
Output 699 = 0xF7 0xF8 0xF9
Output 700 = 0xFA 0xFB 0xFC


All 700 outputs (of where X, Y and Z are sampled at) that I have are known from test and evaluation of the accelerometer. I do know what each X, Y and Z value will be for each output...

Hope this helps, and thanks guys!
Steve

 

[Nigel Goodwin]

Don't you just need three separate smaller tables anyway?.

 

[Ian Rogers]

I would have thought only one...... All three signals are similar, so all could access the same table! Well at least the tilt and yaw could....

 

[bobledoux]

For an altimeter that I built, with a range of 0 to 12,000 feet, with 2 foot resolution, I used the techniques in this Microchip application note. It resulted in small tables, reporting on non-linear data

**broken link removed**

 

[Steve311]

Thats a great app note I definately think this puts me on the right track. I guess I am still confused with the .inc file that has the look up table and the segments...

Is this .inc file just extra memory that I can call out anytime within my program?

 

[bobledoux]

I didn't use the include file; rather, I developed the ideas for my own use.

You reference three , 8 bit variables for input. This could potentially require three tables, each up to 256 steps long. The app note is generally used for more than 8 bits of resolution. My altimeter used 15 bits.

Suppose you use the upper nibble of your data for your step. This creates a 16 step table. Steps would increment as follows; b00000000, b00010000, b00020000....b1111,0000. The upper nibble is your table value and returns a value corresponding to the sensor output for the upper nibble. You add to this the portion of the lower nibble/16 times the change between the two adjacent nibbles.

This is exactly the technique used in the app note except we are using nibbles instead of bytes.

You end up with three, 16 step tables. If it makes calculations easier, add a second table showing the difference between adjacent nibbles.

I hope these notes aren't too cryptic. But they should make sense once the app note is understood.

 

[Steve311]

I like the sounds of that. Very intuitive....

I understand the 16 steps of the table, but why add it to the lower nibble and divide by 16 times the change between two adjacent angles? Its not jumping out at me from the app note.

And also, how would showing the difference between adjacent angles make calculations easier?

I'm going back now to re-read the app note.

Thanks, I appreciate your help.

 

[bobledoux]

The upper nibble table reports the actual value to return for the nibble read. The difference between two adjacent nibbles is split into 16 parts by the lower nibble. So you have to add a proportionate part of the difference based on lower nibble divided by 16.

Example: Suppose the Kth nibble has a nibble readout of 20. The next nibble up, the Kth+1 nibble has a sensor readout of42. The low nibble, 16 bits, represents a change of 32 between the upper nibbles.. So each bit in the lower nibble represents an increase of 2 which must be added to the Kth lower nibble.

The app note suggests subtracting the Kth+1 value from the Kth value. This value is use to prorate the lower nibble. But a second table can be built which shows the result of subtracting the two nibbles. For the Kth nibble the first table would have the value 20 and the second table Kth would have the value 32.

In effect, the two upper nibbles are two points on a regression line. The lower nibble allows interpolation between these two points.