ecuEdit v2.4 - ECU Tuning & Logging solution

[ray]

hey guys!

I thought I had a clue, but am finding out how much I don't know.
I hope that you don't mind a BMW guy lurking around , but the knowledge
here is incredible!
Is ECU edit subaru specific, or will I be able to cross over adapt?
(should I keep learning, or is it a lost cause?)
BTW, you scoobyroo guys kick butt!

-ray

[JRSCCivic98]

Right now the supported platforms are Subaru and Mitsu, but I think the intention is to branch off from that and cover other manufacturers as well. I think in the end it will boil down to which manufacturer ECUs have the ability to be flash capable. Those will be the ones that will get supported. It's just a matter of time vs demand I think.

[Freon]

Ray, ecuedit is pretty generalized, but the formatting options are built around a few specific Denso ROM files. It is possibly it could work as is for many other ECUs, if you already have the ability to pull your ROM down.

Also remember, someone needs to create the map definition/XML files which isn't straight forward.

[Freon]

Just to follow up with some of the new DBW/SH2 processor findings from the other thread.

The following feature is needed:
32bit IEEE 754 decoding of axis values.
Personally I suggest implementing a checkbox for axis and data values that just says "IEEE 754 32bit value" or the like, and it greys out the mult, sign, and hi/lo toggle since IEEE 754 defines all of these factors. It seems most if not all the Subaru SH2 DBW/ETC ECUs will use this format for the axis values and possibly some data values for maps. I assume the EVO SH2 ECUs will need this as well.

Even better:
Map to offset for SH2. It is pretty straightforward for 1D, 2D, and 3D maps. The gradient and offset (mult and add) values that need to be applied to the data values are also part of the map to offset area of the ROM.

More info on both:
http://forums.openecu.org/viewtopic.php?t=503

[epifan]

new ecuEdit v1.2.0.66beta
- new attribute [storagetype] for <rows>,<cols>,<data>. [storagetype] replaces attributes [power] and [signed] and adding new feature of float type (IEE 754)
storagetype="int8|uint8|int16|uint16|int32|uint32|float"
- all known bug fixes and improvements

Download ecuEdit v1.2.0.66beta

[Freon]

I manually modified my XML and it works, but in the GUI it doesn't seem like you can set this. The F9 screen needs to be modified to reflect the new format.

But the basics work!

Working examples:

http://freon.shackspace.com/car/ecu%20a ... ZJ500J.xml

And open using any number of 500J hex files from here:
http://freon.shackspace.com/car/ecu%20a ... g/openecu/

Working great!

[x99percent]

Not really a bug, but more of a inconvenience. If the path of the maps you're working with is long, then when you do a map compare you cannot see the end of the line that contains the filename. You can't even highlight the map you want from the pulldown and hit "End" to have the cursor go to the end of the line so you can see the filename, nor can you resize the window. I vote for you shortening the name in the dropdown fields. Just use the same map name designation you use on the map edit window titlebar instead of the entire filename path. This would make it shorter and you could read the name then.

Workaround:
from a command line...

subst r: "c:\documents and settings\[username]\desktop\Ecu Flashing\ROMs"

(obviously, use your own path )
...now you can use R: to access your ROM files.

[JRSCCivic98]

^^^ Thanks, thought about that, then decided against it... hate having substituted drive letters for paths. It's a workaround, but that's not the point I was trying to make. There's really no major need to know the path... just the filename in reality. The filename should be the only thing in the dropdown. I'm sure it'll get changed soon enough.

[x99percent]

^^^ Thanks, thought about that, then decided against it... hate having substituted drive letters for paths. It's a workaround, but that's not the point I was trying to make. There's really no major need to know the path... just the filename in reality. The filename should be the only thing in the dropdown. I'm sure it'll get changed soon enough.

Agreed. I just encountered this same problem so I wanted to make it work *NOW*, 'cause I'm so very patient.

[mad doc]

mirrored:
http://freon.shackspace.com/car/ecu%20a ... .0.65b.zip

Well that dont work either

[Freon]

Mad doc: I removed that as soon as 1.2.0.66beta was released. I try never to keep old software on my webspace. That post is pretty old. 1.2.0.66b has been out for over a week. Things move fast!

I try to keep all the latest software there, though, it's an open directory, you're free to browse around. Did you try the link that epifan posted on May 11th to the mytempdir thing for the new version? I literally just redownloaded it and it worked fine. If not, I remirrored it again.

http://freon.shackspace.com/car/ecu%20a ... ng/openecu

[x99percent]

Possible bug:

Does the latest version properly update the checksum on the 1MB DBW ROMs? I had an issue last night, and the fix was to open the file in ecuFlash's built-in editor and re-save the ROM.

[cboles]

1.27 only updates the checksum when you change (e.g. edit) the ROM within EcuFlash. If you load a ROM in EcuFlash, and just flash it right away, it won't change anything. I will probably add a feature where is corrects the checksum or at least prompts you before you flash. I didn't want the program to change your ROM if you load it and do no editing. That way you can flash / compare / look at ROMs exactly as they are read from the disk or ECU. Otherwise, you wouldn't even be able to know that a particular ROM had an incorrect checksum when it was stored in the ECU, because it would already by corrected by the time you read it out and viewed it.

Colby

[x99percent]

1.27 only updates the checksum when you change (e.g. edit) the ROM within EcuFlash. If you load a ROM in EcuFlash, and just flash it right away, it won't change anything.

Actually, what I did was edit a single value, change it back, and then re-save the ROM using your editor (just like you said). After that, everything was good. Once I realized what was going on (semi-educated guess), I *knew* that your program would fix it.

Also, no offense to you or your editing program, but at this time, I prefer to use ecuEdit for editing because of the graphing and being able to see all the numbers. Having to specify bloated max and min values to "make room" for the current values in a map is a little weird. It looks like ecuEdit calculates the max and min on the fly..?

[cboles]

Regarding min/max, consider it a difference in philosophy. Soon we should get to a point where we have decent metadata from the various ROMs were are looking at. At that point:

1) I don't like to see the cell sizes of my tables changing based on what is in them. It makes for ugly UI if they change while you are editing. They should just be the right size to start with.

2) The problem you are seeing really only comes up when you use XMLWrite, because it sets the min/max to 0, which is incorrect. I will add code to detect this case and size the cells with a different strategy.

3) Similarly to (1), I don't like to see my color scales autoscale to the data. The color scaling in EcuFlash uses the min/max values. An AFR of 12 always looks the same color when using the same colormap. If you autoscale, the color keeps changing, and you could even have ridiculous values in the map and not notice.

4) The min/max serves a purpose. It helps indicate what the functional range of values are beyond simply the maximum range of the datatype (the two can be radically different in some cases).

1.27 only updates the checksum when you change (e.g. edit) the ROM within EcuFlash. If you load a ROM in EcuFlash, and just flash it right away, it won't change anything.

Actually, what I did was edit a single value, change it back, and then re-save the ROM using your editor (just like you said). After that, everything was good. Once I realized what was going on (semi-educated guess), I *knew* that your program would fix it.

Also, no offense to you or your editing program, but at this time, I prefer to use ecuEdit for editing because of the graphing and being able to see all the numbers. Having to specify bloated max and min values to "make room" for the current values in a map is a little weird. It looks like ecuEdit calculates the max and min on the fly..?