RomRaider

I apologize if this is a previously discussed topic, but I was unable to find an answer during my attempts at searching via google.

Is it possible within RomRaider ECU definitions to force the expression for one parameter to reference lookup data from another parameter? I mean, similar to how logger definitions use multiple parameters in some calculations, I would like to have one calibration word affect the interpretation of the units/expression of a calibration table axis.

To be more specific, my Lotus ECU calculates engine speed by using the crank position sensor measurement period (RPM = const#/(period)). This produces a word length value.

In many table lookup routines, one axis is indexed by a byte length version of the engine speed. Instead of taking the quotient of the word length RPM to create the byte, the ECU instead re-calculates the engine speed using two other calibration words: (byte length engine speed) = (calibration 1)/(period) + (calibration2).

I have created a rudimentary logger definition file, but had to make large compromises in how I display the byte-length engine speed axis because I did not know how to link calibration parameters. This results in very un-intuitive tables.

Can anyone help me out?

There is currently no communications between instances of tables or their axis (which is just another instance of a Table).
One option is to use Static Data, but you would need to define the same data series for each Table in the definition.

It sounds like you need a way for a scaling to refer to the value in a table, something like...



The notation for this doesn't exist today so I'm just guessing that [square brackets] would be a reasonable way to do it.

I haven't actually done any work on RomRaider code but this sounds like a pretty big change.

Thank you both for your replies.

I think that my best course of action for now is to remove the ability to tune these two calibrations in the definition and instead treat them like static/constant values.

I don't think that this is too big a compromise since the only reason someone would need to change these is in case they performed some kind of engine modification that dramatically changed the accessible RPM range such that the table axis needed to be re-scaled.

I think you're on the right track with that approach.

If it does need to be rescaled often, it might make sense to pick one or two alternate scalings and create definitions based on those. It would probably make sense to change the ECU ID at the same time you change the calibration value - then you could create new definitions that inherit from the 'real' definition and re-declare the tables that need different scalings. RomRaider/EcuFlash would then pick the right definition automatically.

Or you could get really fancy and create a script that spits out definition XML that has a custom scaling based on whatever value you specify.

My ECU also uses the XOR operator during conversion of a calibratable lookup table value to the engineering unit value used to control the engine. For instance, many byte lookup values for ignition timing control are immediately XOR'd before being summed (as a signed value) with other timing adjustments.

So far, I've been using a daft workaround which includes configuring the lookup as a 'uint' and then subtracting off half the value of the highest order bit. ex. (uint8 - 128).

Is there an XOR operator that can be used in the Romraider definition ' expression="" ' field? i.e. expression="x^128"

These bitwise operations are supported:
1 - bitwise AND &
2 - bitwise inclusive OR |
3 - bitwise exclusive OR ^
4 - signed left shift <<
5 - signed right shift >>
6 - unsigned right shift >>>
7 - unary bitwise complement ~

expr="BitWise(Decimal mask, Decimal variable, Operation Index#)"

Example:
Perform the AND operation on the variable 'x' using a mask of 0x18
Note: the values must be specified in decimal format since using hex format 0x18 will cause a parsing error

For XOR:


Reference: https://github.com/RomRaider/RomRaider/ ... tWise.java

Thank you very much for your reply. This is helpful.

Interestingly, when I changed from my original expression:
storagetype="uint8" ... expression="x/4 - 128/4"

to a more appropriate expression:
storagetype="int8" ... expression='BitWise(-128,x,3)/4"

the coloring of the table became quite different, in spite of producing the same numbers. This is not a problem, but I thought that I'd share it anyway.

I have another question about RomRaider ECU definition creation - is there a documentation library for allowable definition commands (i.e. is it a faux pas to continue coming to the forum for every one of my questions)?

If there is no documentation library, I wonder if it is possible to include multiple switches that act on different parts of the same calibration byte - for instance bits[0:2] are allowed to be a number from 0 to 4, and bits 4 and 6 are individual boolean switches.

Currently I have one switch setup with all of the relevant permutations (10 states, ignoring the ability to switch bit6), but what I would really like are 3 grouped switches (one for each of the 5 number choices and one for each boolean flag). Is this possible?

If I understand your question correctly, you should be able to use the BitWise function with the appropriate mask to act on multiple bits of the same byte.

One thing to need to keep in mind is that the Editor has a bug in that only the last "table" (in the table menu tree) that modifies a byte will overwrite any previous modification to the same byte by any other table. I think the easiest way to handle this is to define all cases for byte manipulation in a switch table with the various states. An example of this can be found in the Carberry definition. If this doesn't suit your needs I believe someone was working on a true bit manipulation table type for the Editor.

There really is no document that outlines the various tables and all the possible options. But if you care to start one, you can do so over there <<< in the left menu bar under Documentation.