Location/Table Type Identifier

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Location/Table Type Identifier

Post by Fred »

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.
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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Location/Table Type Identifier

Post by Fred »

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
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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Location/Table Type Identifier

Post by Fred »

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:
  1. Config/structure
  2. 1D lookup
  3. 2D curve
  4. 3D contour
  5. 4D spacial
Where config/structure can be ram variables, config settings, in various forms, and the usage is determined by what type of memory it lives in, and whether it can be written, or not. 4D could be possible, but would blow our type listing out of the water. It would also eat memory like there's no tomorrow, and require some fairly special behaviour which is a super set of existing 3D behaviour, so maybe best in a custom managed high level structure utilising ordinary 3D tables in a set.

And types:
  1. UINT8 (1)
  2. UINT16 (2)
  3. UINT32 (4)
  4. UINT64 (8)
  5. SINT8 (1)
  6. SINT16 (2)
  7. SINT32 (4)
  8. SINT64 (8)
  9. FLOAT (4)
  10. DOUBLE (8)
  11. BITS8 (1)
  12. BITS16 (2)
  13. BITS32 (4)
  14. BITS64 (8)
So if we just multiply out, we get:
  • 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.
If we shoot our own feet and say "64 bits, who'll need that!" then we reduce to the following:
  • 1
  • 10
  • 7x10 = 70
  • 7x7x10 = 490
  • 7x7x7x10 = 3430
So then, if we have the first 8 bits mean type, and rule out 4D tables, then we have 4 types (2 bits), and 252 type / 6 bit headroom/wasted space, or space for existing flags. If we ignore 4D then it's a maximum of 2 8 bit bytes and 1 16 bit shortword.

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.
}
Current flags are:
  1. PARENT_MASK
  2. IN_RAM_MASK
  3. IN_FLASH_MASK
  4. INDEXABLE_MASK
  5. READ_ONLY_MASK
  6. VERIFIED_MASK
  7. BACKUP_RESTORE_MASK
  8. SPARE_FLAG_7_MASK
And eliminating one of them should be easy enough. backup/restore necessary/used? Not likely. It's implicit from being in flash. Indexable is good to know. Verified is good to know (UI tool should do pre-verification of its own). Parent is only good fof config anyway, I think. The flag needs to stay, but the actual value could occupy the same bytes as the axes/data types for the table types. Rather than be dedicated. Read only is good to know, too.

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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Location/Table Type Identifier

Post by Fred »

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!
Post Reply