RomRaider

This has already been discussed in great detail in qoncept's thread too.
viewtopic.php?t=6886

The ECU ID is what the RR Logger uses to identify the ECU it is connected to. The ECU init string contains the ECU ID and the valid standard SSM parameters supported by that ECU. The ECU ID is cross referenced to the CAL ID in an editor def.

The CAL ID is what the manufacture uses to identify a vehicle calibration. It's the number used to verify what calibration is on the ECU and the value that is looked up upon to determine if an updated calibration is available. It's also reported by standard OBD readers.

Thanks for the link! I didn't read all of it, but the start was more or less on the right track. Great minds think alike? :-)

That's where IDA comes in. Using pattern searching and other techniques you can identify the proper logic branches for each table and mark them as such.

Say you find the branch for regeneration mode XYZ boost table. Name the lookup table address to "LUT_Target_Boost_Regen_Mode_XYZ". Dump MAP file from IDA and then ScoobyRom can be coded to parse through all "LUT" entries and add the name if it finds an existing table, else throw an error.



Please post them in ECU Analysis, along with the ida.cfg scripts which are a bit hard to find. Perhaps as a sticky for all IDA tools, I'd like to check them out.



That's kind of what I figured. What I'm getting at, is that if they are absolutely cross-reference-able and each ECUID and CALID is a unique set... it seems pointless to use different identifiers and only serves to complicate def writing. Anyhow, making a switch to combined ROM/RAM defs would eliminate this complexity and others.

I think you missed the point.
The Logger can only read the ECU ID upon connection time.

The Editor can only read the CAL ID upon opening the ROM, as the CAL ID is at a known ROM address (the ECU ID is not).

You will always need both and yes they will always form a unique set. Searching for either should get you to the same information.

I got your point, but I don't think it is relevant to my point.

It doesn't matter what is available upon init, because the rom is accessible by SSM read, AND they are cross reference-able in both style definitions.

My point is that it only serves to complicate definition writing by using two different terms that mean the same thing. Why complicate things on one of the human interfaces to save a few lines of code to xref the different identifiers or pull the CALID?

I suppose it's all moot if we move to an integrated ram/rom per-ecu def structure...

Yes once we get to that stage it is.

Looks good, just skimmed through there and have a couple thoughts.

I like the scaling/conversion xml setup, and not breaking ECUFlash definitions. It seems like the least amount of work would be to create scaling "groups" and have a dropdown select from available scalings pulled from the bases/rom-defs that are defined in the same group, then refresh the table. Having a list of conversions seems to add unnecessary complexity.

If ECUFlash doesn't throw a fit, you could also define these "groups" by adding attribute tags to every scaling you want in the group.

I will have to mess around and see if there is a way to add to the ECUflash definition without crashing it.. including a separate tree for RAM. Shame it isn't open source.

I spent the afternoon documenting this. viewtopic.php?t=8449

In one of the other threads I mentioned that the releases should ship with definitions.

Perhaps a git expert could fill us in on the possibility of using git protocol to check version info on the definition repo against the users definitions, and if necessary, auto download/update? If it isn't a major task, I assume it could also be done to notify users of a new version of the main program.

There is a jgit library which could possibly be integrated. I assume that you could give it a set of repos owned by the project and make it check them for HEAD hash and/or latest tag for those purposes, respectively.

Note from groking tonight:

ECU Defs are 'searched' by first reading 0x2000 for an identifier, then looping through available ecu_defs for a match.
-This would have to change in some way to make RR 'generic' compatible.

The first alternative that came to mind (assuming a switch to per-rom style defs) was to parse the romid sections at startup for internalID address and value.

To speed things up, the current 'definition manager' could be changed to select/deselect defs to be checked in a treenode based on directory structure. For example, most USDM Subaru owners will never need to parse EDM, JDM, Mitsu, etc.. Although, I'm not 100% on the compatibility with ECUFlash when messing with the directory structure..


Parsing:
It appears to my java-noob eyes that xml is parsed pseudo-line-by-line. I assume this is old code and there are new libraries that don't require this. Any recommendations? XPath? Does java have anything like LINQ?

Seems pretty universal to me, minor abstraction required :-)


File/path/line ref please. Help your fellow noobs out :-)


What are you trying to do? https://guidoschmutz.wordpress.com/2010 ... and-maven/


https://en.wikipedia.org/wiki/LINQ#Othe ... mentations

Fred.

That works, if you can query the device. In my experience, that only happens about 10% of the time on a rom-only tune. Granted, I currently use ECUFlash in this case.. but with features like RAM tuning, log replay, etc... that would surely change. So we still need the ability to open images only with no connection.

Even with a connection how do you account for different query types/params?

In the current code, it loops through every "romid" data section of the definition and pulls 10+ nodes until it finds a match on one of them. If it doesn't match, it just did a bunch of unnecessary work. Worst of all, that work will have to be re-done if you open that exact rom.

If you load the identifiers at startup and keep it in an array/map, it shouldn't take very long nor use up a ton of memory. You can then limit the unnecessary work by selecting/deselecting different sub directories in def manager.



Everything going on with unmarshalling in romraider. unMarshallRomID for instance.



Not have to write a bunch of switches and parse line by line just to pull the identification address/value from defs. I'll have to check that out. It seems well suited for constructing tables as classes, although it would require some special work for inheritance (merging base tables with actuals, etc).



I also found jinq2xml. Will have to look into it, just an alternative to Xpath I'm familiar with on C#.

Think more abstract. Query = read. device = rom. match = match. etc.


Interface/abstract class.


Agreed.


I grepped for that and didn't find it. Found some others, though...

com/romraider/xml/DOMRomUnmarshaller.java
com/romraider/xml/DOMSettingsUnmarshaller.java
com.romraider.logger.ecu.definition.xml LoggerDefinitionHandler

Yep, that's horrible. Several hundred lines of boilerplate code that must go away. I found these two lines particularly upsetting :-(


I guess if all you have is a hammer, everything looks like a nail :-)

Feel free to try to fix it :-)

Fred.