ECU Version Definitions

Developer topics relating to software that provides a tuning UI to alter ECU code and data

Moderator: Freon

ECU Version Definitions

Postby qoncept » Thu Dec 22, 2005 5:56 pm

epifan is using an XML file to define maps for use in ecuEdit. I'd like to use this same format for Enginuity and hopefully it'd become standard across all editors people make in the future. epifan's XML works great, but I'd like to open it up to suggestions for improvement to allow for the greatest flexiblity and future needs. Below is a small excerpt from one of the maps:

Code: Select all
<ecu_struct id="A4SE900D" type="Euro WRX 02">
  <map name="Low Det Fuel Map" type="3">
    <rows count="18" offset="#292b5" power="2" format="%.0f" func_2val="[value]*50" func_val2="[value]/50" desc="RPM"/>
    <cols count="16" offset="#292d9" power="2" format="%.4f" func_2val="[value]/8192" func_val2="[value]*8192" desc="Load (Air/Cylinder charge)"/>
    <data offset="#292fc" power="1" format="%.2f" func_2val="14.7/(1 + ([value] / 128))" func_val2="(14.7*128)/[value]-128" color_dir="1" inc_dir="0" desc="Air/Fuel Ratio"/>
  </map>
</ecu_struct>

One suggestion I have is that it might be more intuitive to have the number of rows and cols in the <map> tag instead of having to hunt for them in the <rows> and <cols> tag.

Also, rather than defining the formula to calculate common units in every map, define them above. IE, <formula name = rpm> tag, or something like that.

Finally, rather than an 2 equations, for converting to real world numbers and then back to a byte, it'd be nice if you only needed one. I understand why epifan did this, but there should hopefully be a function in each language to reverse the formula. This could be a place we run in to a problem, if Delphi can't do that and epifan needs both equations, while in Java you'd only need one or the other. This is something we'd need to come to an agreement upon.

Anyway, that's my input for now. Anyone else?
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Re: ECU Version Definitions

Postby epifan » Fri Dec 23, 2005 1:44 am

qoncept wrote:Also, rather than defining the formula to calculate common units in every map, define them above. IE, <formula name = rpm> tag, or something like that.

You are read my mind! :lol: btw, this is my next addition to functionality

qoncept wrote:Finally, rather than an 2 equations, for converting to real world numbers and then back to a byte, it'd be nice if you only needed one. I understand why epifan did this, but there should hopefully be a function in each language to reverse the formula. This could be a place we run in to a problem, if Delphi can't do that and epifan needs both equations, while in Java you'd only need one or the other.


For convert expression represented in string I use parser (interpreter) wich extract form string operators, values, functions etc. This parser haven't reverse function and I think that you don't find common parser class with reverse function in Java. Imho, reverse function is to be hard realizable. I wouldn't be to start realize this future :wink:
epifan
 
Posts: 197
Joined: Sat Nov 26, 2005 1:23 am

Re: ECU Version Definitions

Postby qoncept » Fri Dec 23, 2005 4:40 am

epifan wrote:For convert expression represented in string I use parser (interpreter) wich extract form string operators, values, functions etc. This parser haven't reverse function and I think that you don't find common parser class with reverse function in Java. Imho, reverse function is to be hard realizable. I wouldn't be to start realize this future :wink:

That is a very high level function. There are free Java classes available that'll do it though. I'd suggest, then, that when a user creates a new definition in ecuEdit or any other program someone creates, that you plug in a number and convert it both ways to make sure you end up with the same result upon saving. Hopefully that'll keep people from screwing anything up :)
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Re: ECU Version Definitions

Postby epifan » Fri Dec 23, 2005 7:52 am

qoncept wrote:
epifan wrote:For convert expression represented in string I use parser (interpreter) wich extract form string operators, values, functions etc. This parser haven't reverse function and I think that you don't find common parser class with reverse function in Java. Imho, reverse function is to be hard realizable. I wouldn't be to start realize this future :wink:

That is a very high level function. There are free Java classes available that'll do it though.

Sorry, but I can't believe that exists free Java Class with this abilty.
Please, build simple Java App wich able to convert input expression string ( like 14.7/(1 + ([value] / 128)) ) in reverse format... But if we are include [value] twice in expression, without optimization (example: [value] + [value]/50), I think we would be need MathCad...
epifan
 
Posts: 197
Joined: Sat Nov 26, 2005 1:23 am

Postby cboles » Fri Dec 23, 2005 8:53 am

I might as well throw my hat in the ring here too... here is a snippet of the XML format I am currently using. It allows for some "inheritance" via <include> tags to allow you to derive one set of ROM metadata from another. The nice thing about this is that you can define the tables and scaling factors once, and then only define what is different (e.g. the memory addresses) in each rom. The <romid> structures allow ROMs to be identified by matching bytes within the ROM itself, from SSM / other OBD type ECU ID responses, case ID, etc. This works for STi, EVO, Mini, etc. This implementation also supports multiple scalings for each table. I definitely like the epifan's formula interpreter - I need to find an open source version of one of these.

Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ecurom>
<roms>
   <rom>
      <romid>
         <xmlid>wrxbase</xmlid>
      </romid>
      <table type="3D" name="Main Ignition Map" category="Timing" swapxy="false" flipx="false" flipy="false" storagetype="uint8" endian="little" sizex="16" sizey="16">
         <scaling units="degrees" type="linear" scalefactor="1" offset="0"/>
         <table type="X Axis" name="Engine Load in Air per Cylinder Charge" storagetype="uint8"
            endian="little" sizex="16">
            <scaling units="grams" type="linear" scalefactor="1" offset="0" />
         </table>
         <table type="Y Axis" name="Engine RPM" storagetype="uint8" endian="little" sizey="16">
            <scaling units="grams" type="linear" scalefactor="100" offset="0" />
         </table>
         <description>"This is a map of base ignition values."</description>
      </table>
      <table type="2D" name="Rev Limit" storagetype="uint8" endian="little" sizey="2">
         <scaling units="RPM" type="linear" scalefactor="0.1953125" offset="0" />
         <description>"RPM at which limiter turns on and off."</description>
         <table type="Static Y Axis" name="Condition" units="" sizey="2">
            <data>on</data>
            <data>off</data>
         </table>
      </table>
      <table type="1D" name="Injector Flow Scaling" category="Fuel" storagetype="uint16" endian="little">
         <scaling units="cc" type="inverse" scalefactor="2447960" offset="0" />
         <description>"Injector flow rating in cc/min"</description>
      </table>
   </rom>
   <rom>
      <romid>
         <xmlid>A4SGD10C</xmlid>
         <internalidaddress>200</internalidaddress>
         <internalidstring>A4SGD10C</internalidstring>
         <caseid>AF423</caseid>
         <ecuid>1234567890</ecuid>
         <make>Subaru</make>
         <market>USDM</market>
         <model>Impreza</model>
         <submodel>WRX</submodel>
         <transmission>Manual</transmission>
         <year>2002</year>
         <flashmethod>wrx02</flashmethod>         
         <memmodel>68HC16Y5</memmodel>
      </romid>
      <include>wrxbase</include>
      <table name="Main Ignition Map" storageaddress="0x283BA">
         <table type="X Axis" storageaddress="0x283A0" />
         <table type="Y Axis" storageaddress="0x283B0" />
      </table>
      <table name="Rev Limit" storageaddress="0x29AE7" />
      <table name="Injector Flow Scaling" storageaddress="0x29AE7" />
   </rom>   
</roms>


Here is the XML format I am using to define the memory architectures of ECUs / CPUs. This has simplified the reflash code for the various cars and allows for efficient sparse mapping of ECUs with non-contiguous or strange memory pages.

Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ecumemmodel>
<ecumemmodels>
   <ecumemmodel version="1.0" model="68HC16Y5">
       <memsegment name="FB01" type="FLASH" start="00000000" length="4000" />
       <memsegment name="FB02" type="FLASH" start="00004000" length="4000" />
       <memsegment name="FB03" type="FLASH" start="00008000" length="4000" />
       <memsegment name="FB04" type="FLASH" start="0000C000" length="4000" />
       <memsegment name="FB05" type="FLASH" start="00010000" length="4000" />
       <memsegment name="FB06" type="FLASH" start="00014000" length="4000" />
       <memsegment name="FB07" type="FLASH" start="00018000" length="4000" />
       <memsegment name="FB08" type="FLASH" start="0001C000" length="4000" />
       <memsegment name="RAM"  type="RAM"   start="00020000" length="2000" />
       <memsegment name="FB09" type="FLASH" start="00028000" length="4000" />
       <memsegment name="FB10" type="FLASH" start="0002C000" length="4000" />
   </ecumemmodel>
   <ecumemmodel version="1.0" model="SH7055">
       <memsegment name="FB01" type="FLASH" start="00000000" length="1000" />
       <memsegment name="FB02" type="FLASH" start="00001000" length="1000" />
       <memsegment name="FB03" type="FLASH" start="00002000" length="1000" />
       <memsegment name="FB04" type="FLASH" start="00003000" length="1000" />
       <memsegment name="FB05" type="FLASH" start="00004000" length="1000" />
       <memsegment name="FB06" type="FLASH" start="00005000" length="1000" />
       <memsegment name="FB07" type="FLASH" start="00006000" length="1000" />
       <memsegment name="FB08" type="FLASH" start="00007000" length="1000" />
       <memsegment name="FB09" type="FLASH" start="00008000" length="8000" />
       <memsegment name="FB10" type="FLASH" start="00010000" length="10000" />
       <memsegment name="FB11" type="FLASH" start="00020000" length="10000" />
       <memsegment name="FB12" type="FLASH" start="00030000" length="10000" />
       <memsegment name="FB13" type="FLASH" start="00040000" length="10000" />
       <memsegment name="FB14" type="FLASH" start="00050000" length="10000" />
       <memsegment name="FB15" type="FLASH" start="00060000" length="10000" />
       <memsegment name="FB16" type="FLASH" start="00070000" length="10000" />
       <memsegment name="RAM"  type="RAM"   start="FFFF6000" length="8000" />
   </ecumemmodel>
   <ecumemmodel version="1.0" model="SH7058">
       <memsegment name="FB01" type="FLASH" start="00000000" length="1000" />
       <memsegment name="FB02" type="FLASH" start="00001000" length="1000" />
       <memsegment name="FB03" type="FLASH" start="00002000" length="1000" />
       <memsegment name="FB04" type="FLASH" start="00003000" length="1000" />
       <memsegment name="FB05" type="FLASH" start="00004000" length="1000" />
       <memsegment name="FB06" type="FLASH" start="00005000" length="1000" />
       <memsegment name="FB07" type="FLASH" start="00006000" length="1000" />
       <memsegment name="FB08" type="FLASH" start="00007000" length="1000" />
       <memsegment name="FB09" type="FLASH" start="00008000" length="18000" />
       <memsegment name="FB10" type="FLASH" start="00020000" length="20000" />
       <memsegment name="FB11" type="FLASH" start="00040000" length="20000" />
       <memsegment name="FB12" type="FLASH" start="00060000" length="20000" />
       <memsegment name="FB13" type="FLASH" start="00080000" length="20000" />
       <memsegment name="FB14" type="FLASH" start="000A0000" length="20000" />
       <memsegment name="FB15" type="FLASH" start="000C0000" length="20000" />
       <memsegment name="FB16" type="FLASH" start="000E0000" length="20000" />
       <memsegment name="RAM"  type="RAM"   start="FFFF0000" length="C000" />
   </ecumemmodel>
</ecumemmodels>
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby qoncept » Fri Dec 23, 2005 11:09 am

cboles wrote:I definitely like the epifan's formula interpreter - I need to find an open source version of one of these.

Just google for "<insert language here> expression parser" 8)
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby qoncept » Tue Dec 27, 2005 10:12 am

Wow, Colby. I just started messing with XML parsing and it looks like your format is going to be pretty confusing for me. At first it seemed straight forward enough, but I'm having a hard time grasping the include. It makes sense and it's great, but I'm not sure how long implementing it is going to take me. I'm almost considering not supporting the include function.

Edit: Colby, what are the memmodel and ecuid tags?
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby cboles » Tue Dec 27, 2005 11:20 am

The include is handy, but definitely more difficult to implement. What "including" does is allow you overlay parameter from tables or other objects that have the same name. For example, most of the "Main Ignition Map" table info gets defined in the "wrxbase" ROM. In the "A4SGD10C" ROM, "wrxbase" is included, so all that really needs to be defined for the "Main Ignition Map" table are the storage addresses, everything else will be inherited from "wrxbase". If the storage addresses were not included in "A4SGD10C", these "wrxbase" objects would be considered incomplete and not show up in the UI. So in summary, "include" pros and cons are:

+ xml is more human readable as redundant stuff is removed
+ most table info only needs to be changed in one place for multiple ROM images
- more difficult to write parsing code
- saving modified table metadata difficult as it must be "factored"

--------------


memmodels are the way I model memory in the various CPUs. take a look at the ecumemmodel XML i also included in my post. ecuid is the id code returned over a diagnostic protocol like SSM. it is in hex. the value shown is obviously fake. this value allows you to identify the ROM while the car is running.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby qoncept » Tue Dec 27, 2005 11:59 am

The saving shouldn't be any more difficult, at least in Java, but the XML parsing definately will be. The main problem I'm seeing is ensuring all required fields will be populated. If we're picking some from wrxbase and some from a specific ROM, there's no way to guarantee in the XML format that all of the required fields are present.

Once that's done, though, all of the data will be in the table object and saving will be the same as if there were no includes.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby cboles » Tue Dec 27, 2005 12:21 pm

My objects have methods to insure that they are complete and valid. Saving *is* more difficult if you wish to continue supporting the include format in your saved XML. You need to "factor" out the things the object has in common with the included base object so that you only write XML for the parameters that are different.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby epifan » Tue Dec 27, 2005 12:30 pm

cboles wrote:The include is handy

Exactly, inherited definitions very useful :!: I don't think that it's hard to realize. I'll try :wink:

Colby, is this XML-describe format common or it's your development? Did you developing your own map view/edit soft? I asking you bc I must decide: support this format or continue developing my own...
epifan
 
Posts: 197
Joined: Sat Nov 26, 2005 1:23 am

Postby cboles » Tue Dec 27, 2005 1:01 pm

I am in the process of writing a reflashing + map editing tool. The XML format is something made up for my own use, although I have been discussing with other people on openecu for a while. The development has been a bit slower than usual because I'm trying to make the tools very general so that they work with RS/WRX/STi/EVO/Mini. I have been alternately work on finishing the relash tools for the various car models and finishing the map editor. I think it would be very useful if we all used the same format for the ROM metadata XML, memory models, etc. I'm open to suggestions as to what that common format should be. I know we have both written our parsers already, but I don't think the formats are that different aside from the include feature. I would like to change my scaling objects to be more like your formulas anyway, for example.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby qoncept » Tue Dec 27, 2005 5:06 pm

cboles wrote:I would like to change my scaling objects to be more like your formulas anyway, for example.

Colby, I actually prefer your method of an offset and scaling factor. At first I thought the formulas were going to be easier to work with, but your method provides all the flexibility we need. Now, there is of course always the possibility of another ECU version requiring a more complex formula..
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby qoncept » Tue Jan 24, 2006 10:37 am

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.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby qoncept » Tue Jan 24, 2006 10:38 am

Here's an example of what I'm talking about.

ecu_defs.xml
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ecurom>
<roms>
   <rom>
      <romid>
         <xmlid>A4SGD10C</xmlid>
         <internalidaddress>200</internalidaddress>
         <internalidstring>A4SGD10C</internalidstring>
         <caseid>AF423</caseid>
         <ecuid>1234567890</ecuid>
         <make>Subaru</make>
         <market>USDM</market>
         <model>Impreza</model>
         <submodel>WRX</submodel>
         <transmission>Manual</transmission>
         <year>2002</year>
         <flashmethod>wrx02</flashmethod>         
         <memmodel>68HC16Y5</memmodel>
      </romid>
      <table type="3D" name="Main Ignition Map" category="Timing" swapxy="false" flipx="false" flipy="false" storagetype="uint8" endian="little" sizex="16" sizey="16" storageaddress="0x283BA">
         <scaling units="degrees" type="linear" scalefactor="1" offset="0"/>
         <table type="X Axis" name="Engine Load in Air per Cylinder Charge" storagetype="uint8"
            endian="little" sizex="16" storageaddress="0x283A0">
            <scaling units="grams" type="linear" scalefactor="1" offset="0" />
         </table>
         <table type="Y Axis" name="Engine RPM" storagetype="uint8" endian="little" sizey="16" storageaddress="0x283B0">
            <scaling units="grams" type="linear" scalefactor="100" offset="0" />
         </table>
         <description>"This is a map of base ignition values."</description>
      </table>
      <table type="2D" name="Rev Limit" storagetype="uint8" endian="little" sizey="2" storageaddress="0x29AE7">
         <scaling units="RPM" type="linear" scalefactor="0.1953125" offset="0" />
         <description>"RPM at which limiter turns on and off."</description>
         <table type="Static Y Axis" name="Condition" units="" sizey="2" storageaddress="0x29AE7">
            <data>on</data>
            <data>off</data>
         </table>
      </table>
      <table type="1D" name="Injector Flow Scaling" category="Fuel" storagetype="uint16" endian="little">
         <scaling units="cc" type="inverse" scalefactor="2447960" offset="0" />
         <description>"Injector flow rating in cc/min"</description>
      </table>
   </rom>
</roms>


ecu_base.xml
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ecurom>
<roms>
   <rom>
      <romid>
         <xmlid>wrxbase</xmlid>
      </romid>
      <table type="3D" name="Main Ignition Map" category="Timing" swapxy="false" flipx="false" flipy="false" storagetype="uint8" endian="little" sizex="16" sizey="16">
         <scaling units="degrees" type="linear" scalefactor="1" offset="0"/>
         <table type="X Axis" name="Engine Load in Air per Cylinder Charge" storagetype="uint8"
            endian="little" sizex="16">
            <scaling units="grams" type="linear" scalefactor="1" offset="0" />
         </table>
         <table type="Y Axis" name="Engine RPM" storagetype="uint8" endian="little" sizey="16">
            <scaling units="grams" type="linear" scalefactor="100" offset="0" />
         </table>
         <description>"This is a map of base ignition values."</description>
      </table>
      <table type="2D" name="Rev Limit" storagetype="uint8" endian="little" sizey="2">
         <scaling units="RPM" type="linear" scalefactor="0.1953125" offset="0" />
         <description>"RPM at which limiter turns on and off."</description>
         <table type="Static Y Axis" name="Condition" units="" sizey="2">
            <data>on</data>
            <data>off</data>
         </table>
      </table>
      <table type="1D" name="Injector Flow Scaling" category="Fuel" storagetype="uint16" endian="little">
         <scaling units="cc" type="inverse" scalefactor="2447960" offset="0" />
         <description>"Injector flow rating in cc/min"</description>
      </table>
   </rom>
</roms>
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Next

Return to Tuning Software

Who is online

Users browsing this forum: No registered users and 6 guests

cron