openecu.org

I interpreted the turbo dynamics as:

<map name="Turbo Dynamics (Continuous)" type="2">
<rows count="9" offset="#2B4D9" power="2" format="%.2f" func_2val="([byte0]-128)+([byte1]/256/256)" func_val2="" caption="Boost Error" mul="#FFFF" desc="Boost Error %"/>
<data offset="#2B4ED" power="2" format="%.2f" func_2val="([byte0]-50)+([byte1]/256/256)" func_val2="" caption="Wastegate Correction Percentage" color_dir="0" mul="#FFFF" desc="WG Correction %"/>
</map>
<map name="Turbo Dynamics (Burst)" type="2">
<rows count="9" offset="#2B4FF" power="2" format="%.2f" func_2val="([byte0]-128)+([byte1]/256/256)" func_val2="" caption="Boost Error" mul="#FFFF" desc="Boost Error %"/>
<data offset="#2B513" power="2" format="%.2f" func_2val="([byte0]-50)+([byte1]/256/256)" func_val2="" caption="Wastegate Correction Percentage" color_dir="0" mul="#FFFF" desc="WG Correction %"/>
</map>

Jeramie wrote:this was fixed in the last realease of ecuEdit. Turbo dynamics now displays properly.

Which version? Using [value] for my above mappings with my 900C ECU resulted in bad endianness, with 1.1.0.25.

Thats the version of ecuedit I'm using with my 04 wrx image. No problems.

I also have some problems with 2 bytes data :s

IE: I have at 0x2A309 these 2 bytes : 4C CD (in this order), so this value should be 19661 in decimal.

If I use this formula (just to check all):
[byte1], value is : 52480 (0xCD00)
[byte0], value is : 76 (0x4C)

So in order to get decimal value of 0x4CCD I have to write : [byte1]/256 + [byte0]*256

Is this the normal behaviour ?

<map name="Turbo Dynamics (Continuous)" type="2">
<rows count="9" offset="#2B4D9" power="2" format="%.2f" func_2val="([byte0]-128)+([byte1]/256/256)" func_val2="" caption="Boost Error" mul="#FFFF" desc="Boost Error %"/>

I'm not the best at mathematics but isn't

([byte0]-128)+([byte1]/256/256)

the same as

([byte0]-128+([byte1]) because /256/256 =/1?

Does anyone have a conversion factor that has worked? HELP![/quote]

Order of operations

x/256/256 is not x/1 but rather it is x/65535.

/65536

My number system starts at zero equaling one!

... then /256/256 == /66048 ???

cdvma wrote:My number system starts at zero equaling one!

My number system only has zero's and ones....there are 256 kinds of people in this world, those who understand binary and those who don't.

Spiider wrote:

cdvma wrote:My number system starts at zero equaling one!

My number system only has zero's and ones....there are 256 kinds of people in this world, those who understand binary and those who don't.

There are only 10 kinds of people in this world: those that understand binary and those who don't.

I guess I'm just stuck in 8 bit.....thats what I get for playing around with PIC mcu's all the time.

MPLAB is open in the background for my latest project

"Cant find map description for A4SGA00C" is what I get when I attempt to open my ECU image. This is on a 2002 wrx, 5MT. What am I doing wrong? ecuExplorer says that my ecu is "AF422". Do I have some odd ECU or something?

Jeff

"Cant find map description for A4SGA00C" is what I get when I attempt to open my ECU image. This is on a 2002 wrx, 5MT. What am I doing wrong? ecuExplorer says that my ecu is "AF422". Do I have some odd ECU or something?"

I assume you are using ecuedit. I had the same problem. What I did was to copy the xml definition that comes with ecuedit and paste it under the heading that is created for your ecu when you first try to open it. Then once you get the maps open, you can use the hex viewer to look for the proper offsets assuming the maps open with funny values. Someone more experienced than me would have a better idea, I guess.

As for the 65536 vs 65535 vs 65025, thanks guys, better to have 3 possibilities than none at all.