openecu.org

This post is more directed at the editor developers (qconcept and epifan), but everyone's opinion is welcome.

Coming from the Honda community, one subject worth addressing is ROM file standardization. I posted this here rather than the model-specific forums because this is a cross-cutting issue. One of the most effective ideas from the Honda camp was to standardize on a "base" ROM image. For example, all B-series motors started with the JDM b16a ROM image. It was chosen for it's excellent transient response, flexibility, and good numbers on the dyno. Even larger displacement motors started with this image, and wrote in appropriate values in the fuel and ignition tables (keeping the executable code the same). Once this was chosen, only one set of map locations needed to be known. After that, users starting writing their own code and adding it to the unused sections of the ROM space, which allowed everyone to pick up new features.

This is a great idea IMHO. The subie community would benefit greatly if we started planning now which ROM images we like best. The best criteria are:

1) Portability of the ROM to as many versions of ECU as possible. Obviously the SH2 ROMs will have to be separate from the HC16 versions.
2) Newness of the ROM revision. Presumably, Subaru has fixed bugs in early versions of the ROMs.
3) Tunability. More tables gives us more things to configure.
4) Performance. I don't know this applies to subie ROMs, but if there are performance implications between versions that would be good to know.

I am already running into this subject when playing around with ECUedit. There are several ROMs available for USDM 02-03 ECUs, and some are more well-understood than others. It would make things easier for the map editors if only a fewer number of ROMs were supported, so the user community can focus on making tunable maps, and not re-inventing the wheel trying to map out every little variation on the same basic ROM image.

Anyone else care to comment on this?

My knowledge here is pretty limited, but I'll share my thoughts on what I know.

I'm having a little trouble understanding how this will help. If you're talking about ability to add functionality to the ECU, like the scripts my buddy is always telling me about in Chrome, I understand. If you're just talking about the map locations and ability to adapt to different ECU versions, I think it's pretty unnecessary.

I just don't see the advantage in only supporting as few ecu revisions as possible. Say you've got Car A with ECU version X, an early MY 2003 WRX, tuned with a VF22. A guy with Car B with ECU version Y wants to copy his map as a base to start tuning. I haven't written the functionality yet, but the guy with Car B will be able to just copy the appropriate maps from Car A in Enginuity.

This way, there will never be any concern with what ECU revisions are compatible with which ECUs. If you want to try a newer revision, there's nothing keeping you from trying. I could totally be missing the point here, though.

Edit: I just reread your post and saw that you were in fact talking about the added code. If base ECU versions are chosen, that could be a big help. Tuning wise, though, everything else I said will still hold true, and no changes will even need to be made to ecuEdit or Enginuity to support it. we could eventually add a popup when someone opens these ECU versions telling them it's recommended they use such and such revision, available at x, instead.

For anyone interested in finding the ideal ECU revisions to use as a base, I'd suggest looking closely at the versions Cobb uses on the AccessPort first. Maybe they chose them randomly, or maybe they had a reason.

qoncept wrote:Edit: I just reread your post and saw that you were in fact talking about the added code. If base ECU versions are chosen, that could be a big help. Tuning wise, though, everything else I said will still hold true, and no changes will even need to be made to ecuEdit or Enginuity to support it. we could eventually add a popup when someone opens these ECU versions telling them it's recommended they use such and such revision, available at x, instead.

Yeah I am interested in adding code. I know that I want to start getting familiar with HC16 code, because I would like to use some of the outputs to control a water injection solenoid.

Coolest part about that is that I can cut/paste the WG solenoid code, and change the output port to the one I want to use. Presto, configurable duty cycle.

I can think of at least 2 outputs that aren't useful (and can be remapped) on the stock WRX. One is the TGVs, which most people are glad to remove anyways, and the other is the AT communication line, which MT people don't use. The TGVs also use an input to the ECU (for error detection, hence the CEL), so that would be valuable to reclaim for something else.

Finding these outputs and putting them to better use will be an huge advantage of the OpenECU community. Most other major car groups do this too once the basic fuel/ignition stuff gets stable. DSMs, Hondas, and Nissan guys have all been doing this for awhile now with good success.

Anyone given any more thought to this? Sounds like a great idea and a way to make everything just a bit less confusing. And the sooner I can use the extra pins in my ECU to receive input from a wideband, the better.