openecu.org

v5

* started support for 32bit ecus, XML output not yet implemented
* added ecuflash XML format
* fixed maps with stepping axis definitions. Previously weird 2D and 3D maps make more sense now. All static data come from the ROM itself
* better formatting in conversion expression (parenthesis,trailing zeroes etc)
* better handling of format decimals (e.g. RPM values do not need any decimals)
* CALID input is case insensitive
* better output for supported models list
* ROM size check, valid sizes are 192k 512k 1024k
* Exit option at CALID prompt

is this useful? I've been working on the posted 05 sti image A2ZJB10J, and generating a table of map data, ie
Pri Wastegate Duty AIT Comp. 000786F8 16 4 000c05f8 000c0638 3c000000 00000000
those are in order map name, address, row count, databits, row offset, data offset, mult, and adder. Have all the 2d maps done, working on the 3d maps. Was about to ask for help going from this data->ecuflash map data

xswrex - Let me know by email if you have any trouble with the EcuFlash XML format, particularly the inheritance issues...

Colby

xswrex wrote:v5

* started support for 32bit ecus, XML output not yet implemented
* added ecuflash XML format
* fixed maps with stepping axis definitions. Previously weird 2D and 3D maps make more sense now. All static data come from the ROM itself
* better formatting in conversion expression (parenthesis,trailing zeroes etc)
* better handling of format decimals (e.g. RPM values do not need any decimals)
* CALID input is case insensitive
* better output for supported models list
* ROM size check, valid sizes are 192k 512k 1024k
* Exit option at CALID prompt

Great job! I was wondering, how exactly did you come up with all these tables? I know the values can be found fairly easy with the offsets, but a lot of these tables I've never even heard of and are quite obscure. Are the labels for these tables in the logic at the beginning of the ROM (after disassembly) or do you use some super-secret Subaru engineering and design guidebook?

Ok, having issues on the 1d maps, largely just in the description. Have offset, items, item bits. Offset I get, items I think is number of entrys in the table. What I don't get is the itembits entry-especially as it seems to be 0, 1,or 2. does 0->32bit number, 1->16bit, and 2->8bit, or...?
thanks

(0=8,1=16,2=32)

xswrex, I'm adding new attribute [storagetype] in XML-definitions of <rows>,<cols>,<data> tags. Please support it in new XMLWrite
http://forums.openecu.org/viewtopic.php?p=4396#4396
thx

Perhaps this is by design but I thought I'd mention it anyway

I've noticed after using an XMLWRITE V5 definition file (ECUEDIT single offset) my data values have been rounded up to the nearest decimal point.
e.g When I use the ECU Comparison option in ECUEdit, it (rightly) reports differences for the Injector Flow scaling values between my ECU hex file and another stock ECU hex file.
with a V5 def, when I check both values in ECUEDIT they are both displayed as "380"
With an XMLWRITE V4 def file however it reports my value as 380.30 and the stock ECU value as 380.00

Thought I'd bring it to your attention XSWREX as it can be a little confusing when you run a compare - it reports differences - then when you go to actually examine the differences - you cant see any

Thanks for the inclusion of ECUFLASH DEFS in V5

xswrex-

Any chance you can add 160k file reading support to XMLWRITE? All of my EcuFlash HC16 files are 160k. I can convert them all, but lots of other people using EcuFlash will only have 160k files as well...

Also, XMLWRITE reports that a .hex file is not found if it has the read-only attribute set. I keep all of my stock ROMs marked as read-only. Can you just open these as read-only instead?

Colby

New2Scoobs wrote:Perhaps this is by design but I thought I'd mention it anyway

I've noticed after using an XMLWRITE V5 definition file (ECUEDIT single offset) my data values have been rounded up to the nearest decimal point.
e.g When I use the ECU Comparison option in ECUEdit, it (rightly) reports differences for the Injector Flow scaling values between my ECU hex file and another stock ECU hex file.
with a V5 def, when I check both values in ECUEDIT they are both displayed as "380"
With an XMLWRITE V4 def file however it reports my value as 380.30 and the stock ECU value as 380.00

Thought I'd bring it to your attention XSWREX as it can be a little confusing when you run a compare - it reports differences - then when you go to actually examine the differences - you cant see any

thanks for the inclusion of ECUFLASH DEFS in V5

that is because the decimals formating became a bit more clever
* better handling of format decimals (e.g. RPM values do not need any decimals)

cboles wrote:xswrex-

Any chance you can add 160k file reading support to XMLWRITE? All of my EcuFlash HC16 files are 160k. I can convert them all, but lots of other people using EcuFlash will only have 160k files as well...

Also, XMLWRITE reports that a .hex file is not found if it has the read-only attribute set. I keep all of my stock ROMs marked as read-only. Can you just open these as read-only instead?

Colby

no problem Colby, i will check these out. V6 is almost ready with 32bit support

i think V6 is ready....here goes

v6
-----
* added ecuedit XML format (32bit)
* added ecuflash XML format (32bit)
* complete rewrite of conversion expressions parser to support 16 & 32 bit ecus
* fixed: access of .HEX files with read-only attribute set (default open mode set to read-only)
* extract available information from ROM image (copyright, region, etc), dislayed and also used to fill XML tags (market,year etc)
* added support for 160k ROM images
* ROM size check, valid sizes are 160k 192k 512k 1024

I think the min & max scaling values may need looking at for the ECUFLASH def (A4SE900D).
For the the most part my XML values read min="0" max="0" resulting in the map windows being too small to view the data.

See my screen dump from the bottom of this page
http://forums.openecu.org/viewtopic.php?p=4516#4516

Generated a file for A2ZJB10J, 05 sti, and at least one scaling is, imo, wrong;
<scaling name="DATA-11-CCs" units="CCs" toexpr="2450000/x" frexpr="2450000/x" storagetype="float" endian="little" format="%.0f" inc="256" />

Aren't floats in the 32bit dbw thought to generally be in straight units? For sure, the corresponding map value is ~540, right inline with what i think the sti injectors are.

New2Scoobs wrote:I think the min & max scaling values may need looking at for the ECUFLASH def (A4SE900D).
For the the most part my XML values read min="0" max="0" resulting in the map windows being too small to view the data.

min & max attributes are not included in the output XML, i thought this would be done automatically when you opened up a map like the other editors.
There is really no way of doing this properly unless XMLWRITE reads and evaluates every map's min/max values....