RomRaider

Thought I would briefly share some of what I've been working on for the 32bit DBW Subaru. I've been kinda biting my tongue discussing some of the other S/D threads going on because I do in fact know precisely how to successfully get this working.

This is a fairly full-featured speed density fueling system using assumptions of basic physics, written in pure SuperH assembly, manually pipeline optimized and everything. My car's VE map still needs tweaking, as does throttle tip-in, but it does work across all load and RPM effectively. My car has been running this for a while now with great success.

These are videos of the second time I've ever ever run the code on my car with an early VE map.

http://freon.shackspace.com/car/ecu%20a ... nsity1.avi
http://freon.shackspace.com/car/ecu%20a ... nsity2.avi
http://freon.shackspace.com/car/ecu%20a ... nsity3.avi
http://freon.shackspace.com/car/ecu%20a ... nsity4.avi

Nothing is released for general consumption yet (please do not PM me asking for me to send it to you). I'm working on creating patched ROMs (and associated defs) with several features including SD, and they'll be available at some time in the near future.

This is essentially the system I described a month or so ago when there was another s/d thread.

sounds terrific, freon! nice job...

-ken

Why would you be "biting your tongue" and not discussing it? Are you going to try to sell this or something?

I wanted to post it first in my own thread.

Ah, ok. Your post just sounded like an advertisement especially where you said "written in pure SuperH assembly, manually pipeline optimized".

Sounds like you're more patient than most developers... Awesome stuff.

No kidding. Wow.

Along with RamTune, this is what I would consider the last major piece missing from the stock ECU. Very impressive.

J

Holy crap, dude. Bravo!

Haha, well actually the pipeline optimization sounds like more than it is. Once the code is written there is just a bit of fidgeting with instruction order and register use to minimize contention. It's probably not 100% optimal, but I think I saved at least a dozen clocks from the first revision.

It should be of negligible difficulty to port the code to each different ECU revision. Just need to change the relevant memory addresses and find a small memory hole. I use only 12 bytes of memory and could potentially use zero. Total code is about 32 instructions, plus one "Pull 3D map" subroutine call. I left all the MAF scaling table code in so you can still read your MAF via a new memory address for comparison.

Yeah, I guess you've read the pipeline optimization chapter in the programming manual. Probably doesn't matter much, but might as well do it where possible.

How are you handling the IAT compensation? I assume the single 3d map is a VE map?

Bueller?

Yes, 3D VE. 2D won't cut it.

There is an existing 3D IAT vs. airflow compensation applied to load (and thus fueling) in the ECU. This is plenty sufficient for what is needed of it. There is no hard requirement to retune it how the stock map is built. In fact it can probably be flattened if it isn't already.

I still have some tweaking to do with VE and throttle tip-in to clean up the off-idle throttle response, but other than that the car drives wonderfully. I'll post some more videos later.

Yeah, that was what I was talking about in the other thread. Did you have to tune the MAF IAT compensation table with SD or are you saying that you've haven't needed to? That is, what kind of variance are you seeing at different IATs with SD as compared to the airflow determined by the MAF sensor (since you've left the logic in for comparision).

Excellent work, btw.

Even if IAT and the actual air temperature are not similar, as long as they are positively correlated it will just skew your VE table, no big deal. In situations where IAT and actual air temp going into the manifold are not correlated, like IC heat soak, or hot air intakes with big front mounts, you might need to use some extra compensations

I have a cold air intake (see http://freon.shackspace.com/car/perring ... ntake2.jpg) and a front mount so these aren't a problem for me at all. I completely flattened out the IAT/Airflow load comp table and haven't seen any need to fudge with it so far.

Considering how solid my fuel trims actually are (better than with the BigMAF for sure), I think the ECU will take care of many of these issues itself. The IC doesn't heat soak instantly, so you just might see your idle fuel trims lower as you sit in traffic, for instance. This is why it is designed the way it is, I'm not removing any other functions of the ECU.

Worst case is a front mount with a hot air intake that is going to see lots of ambient temperature changes. But in that circumstance I'd just tell the person to pull the IAT out (or whole MAF) and tie it up, say, next the intercooler, or in the fender, etc. This will put the IAT in a position where it will more closely correlate with airtemp in the intake manifold, or again, only translate poorly across fields which are compensated by the way the VE table or IAT/airflow comp tables are built.

I'm currently working on the deployment of RomRaider "Feature"s. The RamTune feature is deployed/installed using the definitions, which provide offsets and code. This works great for installing and uninstalling one feature, but if the tendency for feature installations to occupy the same addresses in ROM is more than occansionally, then there may be an issue with this approach. Do you think this is an issue? Does any of the S/D ROM code occupy the same areas as the RamTune?

Also, can you point me to the place in source control where this code is located?

Thanks,
J

P.S. Still in awe about this feature. I may be using it when we get to that point.