View unanswered posts | View active topics It is currently Thu Nov 23, 2017 12:29 pm



Reply to topic  [ 4 posts ] 
Location/Table Type Identifier 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14878
Location: Home sweet home!
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!


Sun Jun 10, 2012 1:51 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14878
Location: Home sweet home!
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!


Sun Jun 10, 2012 2:07 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14878
Location: Home sweet home!
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:
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!


Mon Jul 06, 2015 6:47 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14878
Location: Home sweet home!
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!


Mon Jul 06, 2015 7:25 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 4 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.