Its refers to readMemoryByAddress in ISO14230 / KWP2000 over ISO15765.

lol

basically it allows the diagnostic tool (laptop with evoscan) to query any memory address.

its not enabled by default in the ECU, so you need to patch the ECU with my Mode23 stuff to get it working...

 

This is cool, i havent done assembly for 3 years now, but i can see that its pretty awesome when its applied to a car ecu room. in the OBTR table is it possible to read gear number? trying to see if this could lead to psi boost base control based on gear .

 

OBTR isn't the mechanism to do that - it's just a timing tweak.

But gear-based boost control would certainly be useful to some, I'm sure!

Rich

 

That's a pretty neat idea. Me likey.

 

The stock ECU can do "low" and "high" gear range, so that's a good start...

I'm not using that stuff - high and low table sets are the same. But I'm on Ralliart IncyWincyTurbo, so I don't have a desperate need gear-based boost settings.

Rich

 

I've slowly added tables into my version of TephraXMODv1 (for 53610010), and it's looking very good indeed.

I haven't patched AltMap "Injector Scaling" or "IPW Adder Map" yet.

But I have added "Lean Spool AFR v FuelMap AFR" to the AltMap family, as I play with LS offsets now and then.


One other thing I did was to rework the map-addressing mechanism slightly - it's hard to resist putting your own spin on something! It works well enough, and means I can add as many new tables as I want without having to keep on changing the map-setting subroutines. Nothing fancy in my tweaks - it just takes the same mechanism the stock ECU code uses for indexed Fuel Maps, and extends it to all of the "switched" 2D/3D maps.


And the KnockCEL code is great - I wouldn't be without it now!

Ricj

 

My next experiment was to put 2-byte "Load" and "Boost" variables into 1-byte equivalents. This worked perfectly well... I now have rescaled versions of these variables able to be read as single bytes.

However, on testing it with standalone OP2.0 logging, it isn't any faster than using the previous 2-byte versions. That was kind of the point of trying it!

Guess I should have tested logging 1-byte variables first... before stampeding to the ROM assembly stuff!!!

Can anyone shed some light on why OP2.0 standalone logging seemingly doesn't go any faster logging 1-byte values instead of 2-byte?


Alternatively... plan B:

Is there any way to implement either of the following on OP2.0 Standalone:

1. MOD calculation... eg. scalingrpn=x,256,% ...percent being MOD
2. Bitwise AND calculation... eg. scalingrpn=x,255,&

I've actually tried "%" and "&", but it no likee.

If either of these can be used, I can grab two 1-byte variables in a single operation, then split them "for free" into the two separate items... sort of like how IDC is based on IPW/RPM.

I can do that for "Load, Timing" and "Load, Fuelling". Two for one.

I can also do that for "Boost" and "WGDC". Another two-for-one.


Any ideas?


Cheers,


Rich

 

yeh, downsizing wont have any affect.

stacking/packing is what I did for my livetuner... 20 log items in 3 packets...

5x speed improvement..

 

Pants.

Well, is there any way for OP2.0 standalone to extract high and low bytes from a 2-byte word?

I'm already logging 13-14 lines a second, which is adequate... but I've had to relegate a few items to being logged every other cycle. That includes stuff like WGDC and timing advance - and it hurts having those only updated 6-7 times a second.

If I can pair a few parameters up, I'll be pretty happy with the resulting logging rate.

Rich

 

yeah, low priority things like WGDC can be logged every second go

IAT/MAT/ECT/Speed can get put into another group and logged every 4th or 5th go..

knock/timing/load/boost/afr are high priority..

but yeh I have spent a LOT of time trying to speed up CAN/OBD process. This week I have probably spent about 50 hours alone on it... I am "close" but every time I think AHHH.. it turns out to be a dead end...

anyways it is "fun" to some extent, but after you have invested 200+ hours on ONE thing you expect to be rewarded...

 

Bwahahahahaha, I reckon I've found an icky, grotty, kludgey way of doing it in OP2.0 standalone!


Here's a logging entry for grabbing a 2-byte chunk...

Imagine this is a pair of one-byte variables you find together in RAM. "Well that certainly is convenient!"

Then, break it into two discrete bytes. Because OP2.0 doesn't give you a bitwise-and, we'll use a crowbar...


The high byte stuff is my icky way to perform a >> 8. It's a three-stage kludge...

1. Add 0x7fffff00 to the 16-bit value. Internally, it seems to be stored as "32-bit signed", so that makes the least significant 8 bits fall off.
2. Subtract the value again.
3. Divide by 256.

It now occurs to me this could be done in two steps instead of three, so I'll optimise it as:

...and see if that works too.



The low byte is then derived by subtracting our smashed-into-shape high byte from the original 16-bit number. Leaving just the bottom 8 bits.


If this actually holds together, there's no theoretical reason to limit it to 16-bit values. It could de-mangle 32-bit values too... so a block of four single-byte variables could surely be read as a single operation?

Assuming your ROM has patches to put them together in one neat 32-bit chunk...


Rich

 

I think Colby said he had a bit grabbing method already in the OP20..

I cant be bothered at the moment to go thought my emails...

but its only good for 4bytes anyways...

 

You mean the "offsetbits=" stuff? That only seems to apply when grabbing the actual data from the ECU... I couldn't get it to do what I wanted with the pure "calc" fields.

Its only advantage is probably a quicker implementation of the division.

On further reflection, I should swap any divisions to 1/n style constant multipliers.

I'll bash away anyway, and see if this actually works with real data. It would be nice for my ECU to build three or four 32-bit chunks-o-vars, which I could then read in just three ops. That would certainly be sufficient data-logging speed for me.

I'll get testing...

Rich

 

Nah, I couldn't fake bitwise operations reliably using the available operations. Got 99% of the way there, but not perfect.

I've posted up a query of the OpenECU forum "standalone logging beta" thread, but I don't recall seeing a constructive response there for ages... so I don't hold out much hope.

I might come back to this later - probably when my logging speeds next annoy me!

Rich

 

I wonder if it's worth poking at the BCS code, to see about holding 100% WGDC during spool-up? It just seems like another easy target, now I'm getting more comfortable with ROM-tweaking...

I remember seeing stuff about this in the Evo I-IX EcuFlash section, regarding the Tephra mod ROM versions. Has this been done on the X, or do people just move to 3-ports as soon as they can, thereby getting the job done "properly"?

Me, I'm happy enough with stock 2-port (and small TD04 turbo) on my RA, so I guess this could be worth trying.

I need a sensible plan - and have to make sure that plan does its job safely...

Rich