openecu.org

Has anyone had any luck finding the axis values in DBW ecu images?

I'm having the same trouble. Even looking at the raw data it just doesn't seem to make sense. I see a pattern 4 bytes long, usually the first byte is something like 63, 64, 68, the second byte starts at 0 and goes up every block. Every few blocks the 63 will increase to 64 or 68, 69, etc.

If it is the second byte of every block, there just isn't enough data. There are only like 12 total blocks between the copies of the fuel map which is something like 16x18, so you need at least 34 points of data.



I think if someone can point out how to get one I could figure the rest out. I've tried doing a byte mask in EcuEdit, (i.e. 00FF0000) to grab the second byte of each block, but as stated above, there just aren't enough points there for the size of the map.

I really think it is going to take someone who knows what they're doing with the decompiler to figure out how this works. I'm wondering if the axes are linear equations, like an intercept and gradient, rather than a full set of values. Unfortunately I don't have any of the tools needed to decompile, and I doubt even if I did I could figure this out never having worked in assembly. I'm an SQL jockey, with some limited experience with C, Matlab, various Basic's.

Yeah, the data before the tables definately looks like it'd be axiis. I've spent probably an hour here and there trying to make sense of it but I haven't come up with anything.

Yes, I'm certain that is the axis information. Every other ROM is setup with the axis information right before the table pretty much. I don't think DBW would be any different than the single CPU systems.

The problem is that the pattern is 4 bytes long, and with 4 byte long data, there are only a few blocks. Not nearly enough to enumerate 15 X-axis points and 18 Y-axis points.

I'm really stuck on this...

Yup. Same problem here. Can't figure out the table axiis. Anybody have any luck yet?

t

http://forums.openecu.org/viewtopic.php?t=503

That's 80% of what we need.

Freon wrote:http://forums.openecu.org/viewtopic.php?t=503

That's 80% of what we need.

Been there, done that. I posted there a couple times before you did

t

[after banging head against wall for days]
Damnit.
Google up IEEE-754

It's completely simple from there...

I haven't tried this yet but ...

http://babbage.cs.qc.edu/courses/cs341/IEEE-754.html
http://www.h-schmidt.net/FloatApplet/IEEE754.html

Description from wiki ...
http://en.wikipedia.org/wiki/IEEE_754

t

also known as a "float" in C

I was able to do a hardset for the axis in Ecuedit for the rows in the maps. I think the hardset is broken on columns, but I'm sure we can talk Epifan into just writing in 754 support.

I think everything needed to finish up DBW support for most Subarus is covered now, just need a few updates to the software.

Wolf, I know, I was just putting a link in so someone reading this thread or finding it in a search would end up in the right place. And this is all new within the past 3 days or so. But you're right, you were there first, sorry...

I'm getting a little stuck on this. I can't find anything in the Java API that'll take an array of bytes and convert (ie, not cast) it in to a float. Is there something in C++ that does this, colby, or is this the kind of thing thats left to the programmer?

In C/C++ this type of thing is easy. You can just cast through a void pointer to convert between any types. It's inherently unsafe though.

this is what i use

type
bint32 = array[1..4] of byte;

function w_bint32( a :bint32) :integer;
var
b :bint32;
i :byte;
begin
for i := 1 to 4 do
b[5-i] := a[i]; //endian swap
w_bint32 := integer( b);
end;

function w_bfloat( a :bint32) :single;
var
b :bint32;
i :byte;
begin
for i := 1 to 4 do
b[5-i] := a[i]; //endian swap
w_bfloat := single( b);
end;