Structures and functions related to 3D tables, such as VE, Spark Advance, AFR etc.
More...
Structures and functions related to 3D tables, such as VE, Spark Advance, AFR etc.
Logical:
- each 3D table is a continuous height map spread over a cartesian (x, y) plane
- Continuous: we expect to interpolate between any 4 points
- The axes are
- Bounded. I.e. non-infinite
- Non-linear. I.e. x[n]-x[n-1] != x[n+1]-x[n]
- Increasing. I.e. x[n] >= x[n-1]
- Do not have to start at [0,0]
E.g. for a 3x3 table, this is what the TS table editor would show:
Y-Max V6 V7 V8
Y-Int V3 V4 V5
Y-Min V0 V1 V2
X-Min X-Int X-Max
In memory, we store rows in reverse:
- Both axes are inverted:
x[0] stores X-Max
x[2] stores X-Min
y[0] stores Y-Max
y[2] stores Y-Min
- The value locations match the axes.
value[0][0] stores V6.
value[2][0] stores V0.
I.e.
Y-Min V0 V1 V2
Y-Int V3 V4 V5
Y-Max V6 V7 V8
X-Min X-Int X-Max
◆ table3d_axis_t
The type of each axis value.
◆ table3d_dim_t
Encodes the length of the axes.
◆ table3d_value_t
The type of each table value.
◆ AxisDomain
Encodes the real world measurement that a table axis captures.
| Enumerator |
|---|
| Rpm | RPM (engine speed)
|
| Load | Load
|
◆ TableType
Table type identifiers. Limited compile time RTTI.
With no virtual functions (they have quite a bit of overhead in both space & time), we have to pass void* around in certain cases. In order to cast that back to a concrete table type, we need to somehow identify the type.
Once approach is to register each type - but that requires a central registry which will use RAM.
Since we have a compile time fixed set of table types, we can map a unique identifier to the type via a cast - this enum is that unique identifier.
Typically used in conjunction with visitTable3d()
| Enumerator |
|---|
| table_type_None | |
◆ getConversionFactor()
◆ rows_begin()
◆ x_begin()
◆ x_rbegin()
◆ y_begin()
◆ y_rbegin()
◆ Load
◆ Rpm