ecuEdit v2.4 - ECU Tuning & Logging solution

[JRSCCivic98]

[Edited for the sake of editing] The nessacery people already read it and it got a response. Sorry I had to vent like that, but sometimes I get that way. It just seemed to me like there's no direction when it comes to the definition files. So far every single xml file I've tested has had mistakes in it. Mistakes that could cause issues when people actually try to use them and edit the files. In all actuality the only app that has a correct definition file for the 04-05 WRX has been TunerPro RT (which is not even a primary application of this forum). That's my main gripe. And while you're right qoncept that I could dig through the endless code just like everyone else to find these offsets my main goal with the Tari stuff was testing of the application as new revisions came out and helping Calvin with informing users of that forum how to use that tool. It seems that with the change of focus on Calvin's part to stop development of ecuExplorer maybe it's time now for me to change my focus as well.... we'll see.

[qoncept]

Alright, here's how I look at it. NO ONE is going to get a comprehensive ECU definition complete alone. That's why we have XML ECU definitions. Between here and the Tari forums, there have to be at least a couple dozen people who are capable of helpin with them in some capacity. But ev8siv3 has done 90% of the work on Enginuity's definitions, using Calvin and Spiider's offsets and finding the rest himself. He's got almost ALL non-DBW USDM WRX ECUs done. That leaves about 50 non-USDM WRXs, which Cobb hasn't touched, and no one is giving them a hard time about the number of cars they can't tune.

You seem like you're intelligent and knowledgable enough to look at a hex file and type in some memory addresses. A lot of people do, but they aren't. This is supposed to be an OPEN community with volunteers, and you're pointing your finger at the people who ARE working. I read a post on pgmfi where a guy was threatening to withhold what he'd learned about K-series ECUs because no one else was pulling their weight. Where the hell would we be if Colby had done that?

[xswrex]

JR if feel sorry for you man. You cant go lower than that, but then there is always room for improvement.

[intrawrx]

jesus, getting a little heated or what?

I think the reason why people have not released any standard XML files is because :

a) People might not rest assured that what they have mapped is correct
b) People feel an attachment to their own hardwork and want others to put in the same hard yard to learn things along the way.
c) Some people just dont have maps for their particular roms

I for one wont be releasing my XML just yet because i'm not 100% sure that its all correct. I am however happy to help someone along the way if they need to know something (i surely dont have all the answers).

[Freon]

JR, if you think there are a lot of bad definitions out there, fix them and repost them, or at least post replies to the XML posts and point out specifically what is wrong so the author can fix them. Just complaining about how bad things are is not the least bit productive.

[x99percent]

Can you explain the info you stated a little bit more epifan?

Subaru ECU have "map type" byte for each 2d or 3d map. Each "map type" describe data size (8bit, 16bit, etc) and dimensions. All offsets in Calvin's ECU archive specify this "map type" byte.

3d map struct is:
<y-axis values><y-axis length - 1><x-axis values><x-axis length - 1><type><z-axis values>

So, example for 3d map with map type 0x05:

<map_struct id="#05" type="3"> //map_type=0x05, type="3" - 3d maps
<element attr="cols_power" value="2"/> //assign cols power to 16bit
<element attr="rows_power" value="2"/> //assign rows power to 16bit
<element attr="data_power" value="1"/> //assign data power to 8bit
<element attr="data_offset" value="[offset]+1"/> //assign data offset to entered offset+1 byte
<element offset="-1" attr="cols" value="[byte]+1"/> //seek offset to -1 from current pos and assgin count of cols
<element offset="-([cols]*[cols_power])" attr="cols_offset" value="[offset]"/> //seek offset to start of cools and assign cols_offset
<element offset="-1" attr="rows" value="[byte]+1"/> //seek offset to -1 and assgin number of rows
<element offset="-([rows]*[rows_power])" attr="rows_offset" value="[offset]"/> //seek offset to start rows and assign rows_offset
</map_struct>

OK, but how do you use this when defining a <map> now? Can anyone please post an example?

I'm missing something obvious or I'm just not getting it...

bump.

[WOTboy]

I'm a programmer, a web develeoper, a motorhead, and I have a EE degree. I'd love to get into helping out with some of this stuff but I don't really know where to begin. If anyone knows of any specific problems I could help out with, let me know.

I just re-flashed my '04 WRX yesterday. It has more sane A/F ratios now and drives so much nicer Now I just need to find some downpipe money.

Also, you guys CAN just ignore whiny people who complain about the quality of open-source work. Don't get too worked up about bungwipes that complain 'cause no one else is spending enough time figuring out all this stuff for them.

[calvinc]

It seems that with the change of focus on Calvin's part to stop development of ecuExplorer

ecuExplorer is not dead and buried. development will resume shortly. i like the inhertance introduced in colby's xml files. ecuExplorer will be using that. FTD2XX support coming soon. i'd like to possibly change the com read/write methodology. in future - source code releases along with each new release.

calvin.

[Jeramie]

It seems that with the change of focus on Calvin's part to stop development of ecuExplorer

ecuExplorer is not dead and buried. development will resume shortly. i like the inhertance introduced in colby's xml files. ecuExplorer will be using that. FTD2XX support coming soon. i'd like to possibly change the com read/write methodology. in future - source code releases along with each new release.

calvin.

Does this mean your not still working on realtime tuning?

[xswrex]

Here is a small app which will try and write the XML files for you.
It currently knows more than 100 ecu versions.
How to use:
1. unzip it in a directory
2. in order to compile the map offsets, the ecu hex file is required. Place it in the same directory with the app files. The filename must be [CALID].HEX where [CALID] is the id found in the ECU hex file at offset 0x200
3. Run the app and it will prompt you for a CALID, type it, press enter and ......the XML will be ready!

[calvinc]

Does this mean your not still working on realtime tuning?

yes i am. NeverLies is making some good progress in rom development.

calvin.

[Jeramie]

Does this mean your not still working on realtime tuning?

yes i am. NeverLies is making some good progress in rom development.

calvin.

Excelent. There is alot of us axiously awaitting. As always, if theres anything I can do to help. Let me know!

[Jeramie]

Here is a small app which will try and write the XML files for you.
It currently knows more than 100 ecu versions.
How to use:
1. unzip it in a directory
2. in order to compile the map offsets, the ecu hex file is required. Place it in the same directory with the app files. The filename must be [CALID].HEX where [CALID] is the id found in the ECU hex file at offset 0x200
3. Run the app and it will prompt you for a CALID, type it, press enter and ......the XML will be ready!

Wow. This thing works pretty good! thanks for taking the time to create it! You should add a readme in the zip!

[ev8siv3]

Holy crap thats a lot of Maps that thing generates!

[New2Scoobs]

Epifan, what is this screen actually asking me for when it prompts for "Type"?


Thanks