This might be kept as meta-data or embedded in the table, but I want to post the possible types.
Formats:
2D/3D
Types:
UINT8 (1)
UINT16 (2)
UINT32 (4)
SINT8 (1)
SINT16 (2)
SINT32 (4)
FLOAT (4)
So:
7^2 + 7^3 = 392 types
+ other arbitrary types, such as 1D lookups (7), config, ram vars, etc
If we include 64 bit values it jumps to 1100
If we drop float it falls to 252 just for 2d/3d
If we drop all 32 bit stuff it is a mere 80, and this is all we're likely to use.
Types including 64 bit:
UINT8 (1)
UINT16 (2)
UINT32 (4)
UINT64 (8)
SINT8 (1)
SINT16 (2)
SINT32 (4)
SINT32 (8)
FLOAT (4)
DOUBLE (8)
For a single region, that's less than 4 bits, even if you include BITS 8,16,32,64. If we make the type field 16bit and store it as metadata then we could do:
TYPEXXXXYYYYZZZZ
Or something like that and be completely future-proof. Type would be group, 1d, 2d, 3d, ram-vars, config-structure, etc. Those 6 cover all of our current needs and leave headroom for 10 more.
What have I missed? Thoughts?
Fred.
Location/Table Type Identifier
Location/Table Type Identifier
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Location/Table Type Identifier
If we forgo the neatness then we get
14 + 14^2 + 14^3 = 2954
Which still occupies 12 bits "101110001010" leaving the same 4 spare, no change.
If we give special values 0 = unused 15 = mixed, it could mean things such as type of structure on it's own.
XXXX00000000???? = 1D
XXXXYYYY0000???? = 2D
XXXXYYYYZZZZ???? = 3D
111111111111???? = config or ram or group
Or, if all four first bits are one, then reuse the later bits in any way.
Or, more clearly, and differently, first 4 mean something, such as a group of types:
0000: ???? ???? ????
0001: XXXX ---- ----
0010: XXXX YYYY ----
0011: XXXX YYYY ZZZZ
0100 to 1111: ???? ???? ????
Or reduce the leading to 2:
00: ?? ???? ???? ????
01: ?? XXXX ---- ----
10: ?? XXXX YYYY ----
11: ?? XXXX YYYY ZZZZ
Where the bonus bits could mean something?
So many possibilities :-)
Fred
14 + 14^2 + 14^3 = 2954
Which still occupies 12 bits "101110001010" leaving the same 4 spare, no change.
If we give special values 0 = unused 15 = mixed, it could mean things such as type of structure on it's own.
XXXX00000000???? = 1D
XXXXYYYY0000???? = 2D
XXXXYYYYZZZZ???? = 3D
111111111111???? = config or ram or group
Or, if all four first bits are one, then reuse the later bits in any way.
Or, more clearly, and differently, first 4 mean something, such as a group of types:
0000: ???? ???? ????
0001: XXXX ---- ----
0010: XXXX YYYY ----
0011: XXXX YYYY ZZZZ
0100 to 1111: ???? ???? ????
Or reduce the leading to 2:
00: ?? ???? ???? ????
01: ?? XXXX ---- ----
10: ?? XXXX YYYY ----
11: ?? XXXX YYYY ZZZZ
Where the bonus bits could mean something?
So many possibilities :-)
Fred
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Location/Table Type Identifier
Bump, does anyone know what factory computers use for this sort of task? IIRC Subaru have a similar scheme.
It might also be useful to have a flag data type for the Z axis of a 3D table, Y axis of a 2D table, and data from a 1D table. But not useful in the axes, that's for sure. You'd have to ensure no interpolation went on, and instead, a closest vertex algorithm was used.
To reitterate for my own thought process:
And types:
If the metadata was read first, the axes types could exist at the head of the block, although it's wasteful to put this in RAM, especially completely brain dead for variable blocks such as the current CoreVars etc. So instead, it could come at the end of the metadata block, and to save space, each type could use only what it needed, and the unused parts could be random and ignored for smaller types.
eg
Current flags are:
Yep, I'm tired, the above may not make perfect sense. But hey, better than nothing :-)
Fred.
It might also be useful to have a flag data type for the Z axis of a 3D table, Y axis of a 2D table, and data from a 1D table. But not useful in the axes, that's for sure. You'd have to ensure no interpolation went on, and instead, a closest vertex algorithm was used.
To reitterate for my own thought process:
- Config/structure
- 1D lookup
- 2D curve
- 3D contour
- 4D spacial
And types:
- UINT8 (1)
- UINT16 (2)
- UINT32 (4)
- UINT64 (8)
- SINT8 (1)
- SINT16 (2)
- SINT32 (4)
- SINT64 (8)
- FLOAT (4)
- DOUBLE (8)
- BITS8 (1)
- BITS16 (2)
- BITS32 (4)
- BITS64 (8)
- confg/ramvars = 1, requires strucural definition.
- 1D = 14 data types with lookup always being by unsigned value with memory and usually ADC bit count being the limiting factors
- 2D = 10x14 = 140 possible types
- 3D = 10x10x14 = 1400 possible types
- 4D = 10x10x10x14 = 14000 possible types, if done this way.
- 1
- 10
- 7x10 = 70
- 7x7x10 = 490
- 7x7x7x10 = 3430
If the metadata was read first, the axes types could exist at the head of the block, although it's wasteful to put this in RAM, especially completely brain dead for variable blocks such as the current CoreVars etc. So instead, it could come at the end of the metadata block, and to save space, each type could use only what it needed, and the unused parts could be random and ignored for smaller types.
eg
Code: Select all
MaxType mt;
getDetails(mt, id); // populates mt based on ID
uint8 type = (mt.type & mask);
if (type == Type3D) {
Type3D threeD = (Type3D) mt;
// Do 3D things
zType = threeD.ZaxisType; // Unsafe for 2D, 1D, and config/structure
yType = threeD.YaxisType; // Unsafe for 1D and config/structure
xType = threeD.XaxisType; // Unsafe for configh/structure
// And only if 3D, because if not 3D, ZaxisType would have random bits in it and not be safe to use, let alone meaningful. etc.
}
- PARENT_MASK
- IN_RAM_MASK
- IN_FLASH_MASK
- INDEXABLE_MASK
- READ_ONLY_MASK
- VERIFIED_MASK
- BACKUP_RESTORE_MASK
- SPARE_FLAG_7_MASK
Yep, I'm tired, the above may not make perfect sense. But hey, better than nothing :-)
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Location/Table Type Identifier
Actually, the verified flag will become pointless, as everything will be verified except 1D lookup tables, which by definition can't be. Thus any app can just know that, and the flag can go away.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!