ECU Version Definitions

[cboles]

Ok, after getting about 90% done with implementing includes, I've just gone back and undone all the work. I decided in the end it'd be better to not support them. I was kind of hesitant since I'd put so much work in to it, but I think it'd actually be a bit more confusing for the end user.

Here's what I'm doing instead. In one file (say ecu_defs.xml) I'll have the ECU definitions with all of the relevant data in each rom tag. Just like in Colby's example, but each ECU version will basically be combined with the base it included in Colby's version. Then, to help ease with adding new ECU versions, I'll have another file (maybe ecu_base.xml) that will be imported in to the ECU definition editor, basically just as defaults for the user to work with.

I think this will make adding new ECU versions easier. Instead of choosing between being bound to the base and overwriting certain fields or creating the definition from scratch, the user will be able to open wrxbase and make the appropriate changes. It'll also make writing applications that use them easier and, as I found out, reduce complexity by a whole lot.

Ultimately, this is very similar. All my includes do is overlay the same object several times, each time adding more detail, and then in the end only presenti the complete, valid objects to the user. My heirarchical approach can always be flattened out when it goes to save a file, and can also load any other file as a template, so I think it will be pretty easy to maintain compatibility between the two programs.

In some ways things would be easier using a database in terms of having each type of object only described once (descriptions, scaling, table types, addresses) and then just build the ROM metadata by reference to these various things. I think the XML is a lot easier for most people to play around with and understand though.

[crispyduck]

...In some ways things would be easier using a database in terms of having each type of object only described once (descriptions, scaling, table types, addresses) and then just build the ROM metadata by reference to these various things. I think the XML is a lot easier for most people to play around with and understand though.

IMHO a database might be easier however you need to ensure you keep the installation simple. If you go with a database you might want to consider SQLite which is a simple OpenSource SQL interface around a flat file - no database to install!

XML is nice but if we step back and look at what requirements you are addressing one might say you need the ability to import others 'schemas'. Perhaps a simple import procedure would solve that. Anyway just food for thought.
-Steve.

[qoncept]

I think a database would definately be the easiest, and a flat text file would also be pretty easy to implement. The portability of XML and the fact that Colby and I will both be using the same (or at least very similar) format will make it the better choice I hope.

[epifan]

Here's what I'm doing instead. In one file (say ecu_defs.xml) I'll have the ECU definitions with all of the relevant data in each rom tag. Just like in Colby's example, but each ECU version will basically be combined with the base it included in Colby's version. Then, to help ease with adding new ECU versions, I'll have another file (maybe ecu_base.xml) that will be imported in to the ECU definition editor, basically just as defaults for the user to work with.

I'm suspect why you choose strategy with 2-files and replication of all tags - that BC it's more SIMPLE for developing than support real inherited descriptions IMHO, this way is nothing to help for easy describe of similar ECU's

[qoncept]

I'm suspect why you choose strategy with 2-files and replication of all tags - that BC it's more SIMPLE for developing than support real inherited descriptions IMHO, this way is nothing to help for easy describe of similar ECU's

Nah. Like I said, I was almost finished with it. I just don't see it being very useful. If a user goes in and wants to edit the XML, it seems it would be a lot easier to have all the relevant info in front of them instead of having to scroll back to the top of the file over and over again.

Then again, I suspect no matter what I say you're going to think it's because I'm lazy or incapable. So be it.

[epifan]

If a user goes in and wants to edit the XML, it seems it would be a lot easier to have all the relevant info in front of them instead of having to scroll back to the top of the file over and over again.

So, it's like top description without any inheritance Follow your description organization, If after month of research we are found some changes in base map description we are must make changes in ALL concerned maps this is not good

[qoncept]

If a user goes in and wants to edit the XML, it seems it would be a lot easier to have all the relevant info in front of them instead of having to scroll back to the top of the file over and over again.

So, it's like top description without any inheritance Follow your description organization, If after month of research we are found some changes in base map description we are must make changes in ALL concerned maps this is not good

Find/replace works great in notepad

[epifan]

If a user goes in and wants to edit the XML, it seems it would be a lot easier to have all the relevant info in front of them instead of having to scroll back to the top of the file over and over again.

So, it's like top description without any inheritance Follow your description organization, If after month of research we are found some changes in base map description we are must make changes in ALL concerned maps this is not good

Find/replace works great in notepad

notepad is very useful for end-level users

[qoncept]

notepad is very useful for end-level users

Look at the intended user. I'm not planning on many end level users that can't function properly with notepad, and I'd say that finding the addresses of these tables, figuring the conversion method and doing everything else required to make a map is a whole lot more involved than using a text editor.

If you want to argue about it, please do it in a private message.

[qoncept]

I've added another attribute to the <scaling> node -- format. This will define how real world numbers are formatted.

<scaling units="degrees" type="linear" scalefactor="0.3515625" offset="57" format="#.00" />

[qoncept]

I've had to make a few changes to the XML format to facilitate some creature comforts and calculations of values that couldn't be done with just the offset and scalefactor. So I ended up using epifan's method of expressions for real value calculations.

I've also revisited the <include> function and decided that it will be best. I was underestimating how similar different revisions really are -- for example, every 2004 WRX map is the same, so we'd be creating the exact same definition for half a dozen ECU revisions. I haven't decided whether I'm going to do this along with bug fixes for 0.2.xxx or if I'm going to wait till the next point release, when I'll be adding other functionality (0.3.xxx).

My current format is viewable here: http://www.enginuity.org/viewtopic.php?t=5

[Kha0S]

I've had to make a few changes to the XML format to facilitate some creature comforts and calculations of values that couldn't be done with just the offset and scalefactor. So I ended up using epifan's method of expressions for real value calculations.

What linear function can't be represented with simply a scale factor and offset?

What nonlinear conversion is required in the Subaru ECU?

[epifan]

What nonlinear conversion is required in the Subaru ECU?

Like this: ([value]-x)*y.
May used in Temperature values to convert from Celsius to Fahrenheit

[Kha0S]

What nonlinear conversion is required in the Subaru ECU?

Like this: ([value]-x)*y.
May used in Temperature values to convert from Celsius to Fahrenheit

That's still linear.

([value - x]) * y is identical to [value] * y - x * y. It's the associative property of addition (and subtraction)... (a+b) * c = a*c + b*c.

In your example, C -> F is:

F = C * 9/5 + 32, or
F = C * 1.8 + 32

This fits the normal scale/offset form.

Now, the other direction:

C = (F - 32) * 5/9, or
C = (F - 32) * 0.556

This can easily be represented as:

C = F * 0.556 - 160/9, or
C = F * 0.556 - 17.78

All linear equations can be algebraically converted to the form f(x) = ax+b. Unless there's a conversion somewhere in the ECU that is truly nonlinear that I haven't come across yet, ax+b applies to every table in the ECU.

[epifan]

ax+b applies to every table in the ECU.

certainly! But I'm use full expression support for clearness and useful.
BTW, only one scaling factor is not a correct solution, it require adding/subtracting item