RBob

iTrader: (1)

This post describes how GM's 2D and 3D table lookups operate. These tables would include the SA table, the knock retard tables, the VE table, MAF scalar tables, TCC tables, and a host of others. A 2D table is a one dimensional array of values while the 3D table is a 2 dimensional array of values. In the C3 & P4 ECMs the maximum number of rows and columns for a table is 17.


For a 2D table a single argument (arg) is used to locate the proper value within the table. A 3D table has 2 arg's in order to locate the proper value within the table. The value of the argument can span from 0 to 255, a single byte value. Most of the time the arg value does not fall directly on a row or a row/column intersect. Because of this the lookup routine interpolates between the row & column table values.

The arg terms may be any number of different sensor or internal values. Some common ones are RPM, CTS, TPS, AFR, MAP, MAF, battery voltage, and knock counts.

A 2D table of 17 rows is the easiest to understand. It is used in the following example. With 17 rows there are 16 steps and 16 arg increments between each row. This 16 * 16 = 256.

Bascially speaking the code will do a 16 point interpolation between the rows.

Here is our 2D table:

The lookup arg is RPM. In this case the ECM value for RPM is RPM / 25. So an RPM of 2450 is: 2450 / 25 = 98, the 98 being the value that the ECM uses internally for that RPM. Note how the table rows are labeled, starting at 0 RPM, then the next row being 400 RPM, the next being 800 RPM. There is a 400 RPM difference from row to row. This is because of the 16 arg increments between each row: 16 * 25(rpm per increment) =

400(rpm between each row).

Staying with 2450 RPM what is the looked up value?

First divide the 98 (2450 / 25) by 16: 98 / 16 = 6.125, with the ECM keeping 6 (no fractions allowed, although the code will round to one place: 10.6 becomes 11).

A) Multiply 16 * 6 for a 96 and subtract that from 98 (the arg) for a 2.

B) Go to row 6 and get the value 102 (at 2400 rpm).

C) Go to row 7 and get that value: 122 (at 2800 rpm).

D) Sub the row 7 & 6 values: 122 - 102 = 20

E) Divide 20 by 16(increments between rows): 20 / 16 = 1.25, or 1

F) Multiply the 1 * 2 (from step A): 2 * 1 = 2

G) Add the 2 (from step F) to the 6th row value of 102: 102 + 2 = 104


** 104 is the final value and is the value the lookup routine returns.


In step A the value of 2 means that the lookup is 2/16's of the way to the next row.



The 3D lookup routine does the exact same math three times. Once each for the two sets of rows, then once again between those values (for the column interpolation).



Now for the tricky stuff: not all tables are like the one above.

Here is a table that has been compressed:

Notice how each row increments by 800 rpm. It is a 9 line table as shown by the row count (yes, they don't match and is correct). In this case the lookup routine will properly handle the table while doing a 32 point interpolation between rows.


Another case is where the table starts at at 0 RPM with a maximum of 3200 RPM:

The code will first check if the RPM is over 3200 and if it is set the arg to 3200 RPM (128). The lookup routine is then called. It will do the regular 16 point interpolation.


Copyright 2003 RBob All Rights Reserved.

87400tpi

RBob,did you work for GM.:hail:

blue86iroc

iTrader: (2)

Thank you, RBob! That makes sense to me now. Why do you think GM chose to do the lookup that way?

I'm pretty sure that this next method won't work for finding the values you stated above but say, for instance, that the 2D table's values were coordinates on a graph. Plot the points and create a regression line. Then the value that isn't on the table could be predicted. It might be a little less accurate, but a lot easier on the ECM. What do you think?

EDIT: One more thing. In the part before Step A, you get a decimal answer. If you don't get a decimal answer, do you just go directly to that row (i.e. if I get a 7 after I divide by 16, should I go directly to row 7 and skip the rest of the math? It seems so.).

Doctor J

RBob-

Thank you, that was an excellent explanation. As always - you bring light to a topic (rather than heat).

That being said, may I offer a suggestion & a question?


Suggestion: IMHO some nascent code experts might benefit from an explanation of why 256 is such a signigicant nunber for an 8-bit computer, or an 8-bit A/D converter. You might be the best candidate to write that piece of fundamental understanding for the record, if you wished to volunteer.


Question: I haven't done anything with the 165-type ECM's myself, but I am under the impression they used a 128K PROM - compared to the 256K PROM on the 730-type ECM's. I am also under the impression the 256K was used by GM to store more look-up tables and instructions for the later ECM. However I've never seen a quantitative comparison of the two, in terms of capacity, speed, number of tuning tables, or the like. Do you have a concise comparison handy? I've always been curious about it.

Thanks again for your contributions.

Edited to correct typo.

RBob

iTrader: (1)

I really can't say why GM did it this way. It does eliminate large steps between data rows. I would imagine that CPU cycle overhead also came into play.

As far as an extrapolation, many tables are not a line but rather a curve. Now the CPU would need to do polynomials.

Yes to if the arg is right at a table data point. Just use that value as is, no interpolation required.

RBob.

RBob

iTrader: (1)

I am not that up on the '165s and that amount of space used/unused. I do know tha thte '749 w/the $58 mask is packed into 128Kb. A 256Kb EPROM is a drop in on this ECM.

The $8D mask in the '730 has a lot of open space. Although it still will not fit into a 128Kb EPROM.

The difference between a C3 ('8746) and a P4 ('730/'165) is about double: twice the clock speed, twice the RAM, twice the instruction set, and much more EPROM address capability.

RBob.

Doctor J

Thanks!

funstick

i thought all p4 ecms could adress upto 256kb. am i wrong ?the only thing im lost on is how is the arg written in the code exactly ?

RBob

iTrader: (1)

I do not know whether all P4's can address 256Kb of EPROM.

The arg for a looup is typically from RAM as most of the time (all?) it is a variable. Here is the code that looks up the PE SA value from the $8D mask:

The LDAA L0057 is loading reg A from RAM location $57, which holds an RPM term. This RPM term is the actual engine RPM.

RBob.

Grim Reaper

This should be a "sticky".