Is it possible to reduce the amount of code that is ran in the ECU and would reducing the amount of code allow the ECU to loop through quicker and potentially improve response characteristics?

Some things I could do without:
Boost control
All emissions controls
High/low octane scaling (still want ignition retard on knock, but don't want it to interpolate between maps)

 

CPU Loop Time:
88590015 -> FFFF6A04
96530006 -> FFFF889E

Needs to be set up as a 2 byte item.

Unsure of scaling for Evo8/9s, Evo5/6 and DSMs is x*4 = uSec.


You won't save much on Hi/Lo Octane.

Emissions is a significant amount of total code, so might speed things up a bit.

MUT logging slows things on the older H8 ecus.


But since DMA logging is possible with no performance issues I doubt extra cpu time is needed.

 

I was looking through what I believe to be the knock control section and it seems like if you disable the high octane, it kills knock control all together anyway?

FAA bit.12 might be fuel vapor purge solenoid? I haven't seen that defined and it seems like it may be related to it anyway.

Also, bit.1 is noted as being rear O2 related, but it looks like it may also have an effect on closed loop operation?

Seems like FAA is where all the important functional controls take place?

 

Interesting point!

 

Let us assume you are at 9000 RPM,
so there are 9000/60/4 ~ 38 firing events per second.
Ecu cycles ~ 100 times per second so all calculations are done
approximately 2-3 times for each firing event and that is at 9000 RPM.

I am sorry but I do not see your point here.

 

An interrupt is scheduled to occur so many uSec after the CAS interrupt. The CAS interrupt always occurs at -71*(not sure exact degree). I think the CAS's speed/resolution is the limiting factor for timing accuracy, not the cpu.


The map look ups, etc. are on a free running loop, that completes about 100 times a second. If there was a cpu performance issue, this would take longer to complete, and the previous look ups would be used, which isn't that big of a deal. The important interrupt driven stuff is always done first.

 

Shouldn't that be 9000 (revolutions per minute)/60 (seconds per minute)*2 (spark events per rotation) = 300 (spark events per second) making this a very valid point?

Also, I'm more interested in transient responses then steady state. You tip in on the throttle and it reacts quicker.

The whole point though is that I'm just curious if it's possible to kill some stuff that may not be needed in some cars. I am running a MBC and no emissions controls are in the car. No point in having the ECU run through the code, fault checks, etc. if the stuff isn't being used.

FWIW, the 71 degrees lead in on the CAS goes right along with what I physically measured the crank trigger and plate to.

 

It seems you want to do it, there are two routines that you can get rid of in the main subroutine.

94170015:

It is untested and consequences unknown. Do it on your own risk
@F08E -> DTC and readiness
4A0B -> 0009

@F0A4 -> Immo code
4A0B -> 0009

Then log what Ceddy wrote if there is some difference.

 

Disabling FAA bit.12 causes all kind of interesting things to happen, I'm sure. But I wasn't able to get the car above 1500 RPM to see. It cut IPW in half or so.

I did disable a bunch of stuff in FAA though and I think I may have come across something affecting the lean issue I have been whining about. I've got to retune the car to see if it fixed the problem or not, but it seems to have had a pretty dramatic impact on fuel at low engine speeds.

 

That math can't be right, if the ECU can only handle 100 events per second then your math would say the limit of the ECU is at mere 3000rpm.

3000/60 * 2 == 100;

It is true that wasted spark makes the firing event happen twice as fast but thats still only RPM/60/2 which is 75 events per second @9000 RPM. Assuming the ECU can handle its limit of 100 that puts the theoretical cap around 12000rpm or so .

Edit:

You know i take this back there may be two sparks happening per RPM but its being dictated by one device which is still only 1 call for the ECU making acamus's observation correct. At a mere 38-39 events a second the theoretical limit of the cpu is vastly higher than my estimate going up to 24k rpm.

 

The actual spark event is driven by interrupts. It has nothing to do with the main loop other then the main loop figures out the timing advance. At 9000 RPM, there are 300 sparks per second, my math is correct. You need to be multiplying by the number of spark events per revolution, not dividing.

Spark lookup on the other hand is done once every time the main loop happens. At 100 times a second, and at 9000 RPM, the timing advance is going to be updated every 3rd or 4th event (right on the borderline).

But again, I already said it's not the steady state stuff I'm interested in. It's the transient response characteristics. The stock ECU is not all that "crisp" and I'm mostly just curious if it has to do with how the main loop is running and if speeding it up may help out.

 

If you're looking for better transient response, then wouldn't the appropriate variable to analyze be the max rate of change of rpm or load that you're car sees? This would be where a faster main loop is going to make a difference. I think there can be substantial load transients.

I've fiddled a few times with trying to disable OBD tests to speed up the main loop, but each time I conclude that the OBD tests on the USDM cars are too interwined with the rest of the OBD code to effectively disable a large number of tests without causing drivability or CEL issues. The best solution might be to switch to a JDM ROM where there are much few OBD tests. Might be resonably straightforward for an Evo 8. The biggest issue is probably solenoid operation. The evap and EGR solenoids might be used for other things on JDM Evos, and so the solenoids in a USDM Evo might operate incorrectly.

Ceddy, nice info on the ECU loop time. I'm definitely going to start logging that parameter.