[cgrey8]

One of the things sailorbob and I have always wondered is just how beaten up the processor gets at higher RPMs and at what RPM do the background loop functions dangerously starve. Well, sailorbob came up with a patch to test just that. What it does is maintain a count of how many times the background loop has executed while in OL.

For those of you that aren't familiar with what I'm even talking about let me explain that a little bit. The architecture of the EEC's code is such that lower priority tasks are calculated and done in a background execution loop. The background loop gets processor attention when the processor has nothing else to do. Background loop tasks are things like EGR calculations, Smog Pump calcs, OL/CL fuel calculations, idle control, TwEECer datalogging, etc. The EEC also has "Foreground" tasks that only run when needed. In the computer science world, Foreground tasks are actually Interrupt Service Routines (ISRs). ISRs are high priority chunklets of code triggered by some event such as a PIP from the distributor, a timer expiring, or some other event of importance. When ISRs are triggered, they "interrupt" the background loop to execute until they complete. Once the ISR completes, the processor returns to executing the background loop assuming no other ISRs were triggered while the previous ISR was executing. Processors can have multiple defined events, each that trigger different ISRs. Because some may be higher priority than others, it's possible a higher priority interrupt event can trigger an ISR that interrupts a lower priority ISR currently executing. Once all ISRs have completed, the processor returns to executing the background loop. Thus the frequency at which ISRs get triggered affect how fast the background loop executes. For example at high RPMs, the PIP count is extremely high as compared to idle. So there are far more interrupts triggering the ISR associated to the PIP event and thus there's less time for the processor to spend executing the background loop. Even though the background loop isn't critical with heavy deadlines like ISRs, it is important that it be executed on some reliable frequency to update things like OL LAMBSEs based on changes in RPM, Load, ACT, ECT, etc. If the RPMs get so high that the background loop begins to starve for processor attention, then some of the non-critical values that the background loop calculates could become stale and thus any ISRs that use background-calculated values will be operating on old/inaccurate info for the current condition. If RPMs get too high, it's quite possible that there would no longer be time for the background loop to execute at all. At that point, if the RPMs continue to increase, there'll no longer be enough processor time to complete the ISRs in the time period required, to say nothing of background loop time. At that point, you've reached the RPM limit of the EEC which I've heard is in the high 6000s somewhere for GUFx EECs.

So, what this experimental patch will do is keep a dataloggable count of how many times the background loop executes during OL so we can get ideas as to how badly the background loop suffers when at high RPMs. As well, it'll give us the ability to determine if things we are doing in the EEC's tune affect the high RPM performance of the background loop. The highest I can get my engine is mid 5000s before it starts floating the valves. However I know there are plenty of people here running a GUFx processor with true performance engines that can get 6000+RPMs no problem. If any of you would like to volunteer to do this test, it might shed some light on some "track" best practices for those that push deep into the 6000s.

For example, one test a person might do is compare the background loop performance with as many dataloggable points as possible, then do another run where only the background loop point is being datalogged. Theoretically this should speed up the background loop some, but I don't have a feel for how long it takes the EEC to datalog 15-17 points as compared to all the other stuff that's being calculated during WOT background loop conditions.

Another test that might prove useful is to compare background loop execution rates with the WOT functions enabled and disabled. One of the things we've been recommending is for people to disable the WOT functions. But it is quite possible that the processor executes the WOT functions faster than it does table-lookups. If so, this test might indicate whether the difference is significant or not.

As we continue to research the BIN, there may be other things that can selectively disabled during high RPM WOTs in an effort to improve background loop performance, but nobody's been able to datalog this type thing so nobody has ever looked into anything like this.

So what's required of you to test this?

• You'd need to setup a payload to datalog a specific memory location. If you have a GUFB processor, I think the datalog options are already in the GUFB Rev 43y version of BE. I don't believe I put those options in GUF1 or GUFA, but they can easily be put in or added manually by you.
• Patch your BIN to support this new datalogging code. I'll give further instructions on doing this for those interested in the experiment.
• Setup BE to datalog every 50ms if it isn't already.
• Download that custom BIN and Payload to your TwEECer RT, and run a high RPM WOT. The longer you can hold higher RPMs, the better so high-gear WOTs will give far better info than 1st or 2nd gear WOTs will.

While there are multiple tune configs that can be tested, I'm mostly just looking for baseline info right now. But indicating whether you use WOT functions or Fuel Tables at WOT might be useful to determine "where" the baseline is.

Just for those interested, I'm finding my background loop at idle is in the 30 executions/sec range which is somewhere between 25-50ms intervals. In the 5000RPM range, I'm seeing it slow down to 7-9 executions/sec which is in the 100-150ms interval range. I can see 6000RPMs getting that down to 2-3 execution rate/sec range in which case doing things like decreasing the number of datalogging points might be enough to make a difference.

[Cougar5.0]

I'd like to do this, but I may not be able to drive the car for a couple of months - doh! It seems to snow about once a week this winter so far :(

My first thoughts while reading this related to the lack of updates seen in the logs at higher RPM's. I've frequently hit the rev-limiter without seeing a point above redline, or I see a delayed point above the limiter on the way down (how high did I rev it? I regularly rev to 6200 and the background loop must be drying up pretty good based on the lack of updated points. I always wondered if the TwEECer used background loop processing or if it simply looked at available data on the bus.

I then wondered if the WOT functions used less overhead and whether using table interpolation was more processor intensive. Looking at the latter ECU's, the clock speed was indeed faster and may have provided a needed boost for tabular WOT look-ups.

Finally, I wondered if overhead could be improved by not only perhaps completely bypassing or eliminating certain code that has been turned off or is not needed (though this may already be the case as EGR, Thermactor, canister etc are inactive at WOT I think?), but also by increasing processor speed. I know I've mentioned this and sailorbob has stated that there are certain hidden constants that would need to be changed based on the new processor speed. I bought some 18MHz crystals based on a few racers who stated that they had upgraded their crystals to allow revving above 7000 RPM. I don't want to rev to 7000 RPM, but I would like to reliably datalog up to redline (where the engine usually blows up and when I blew mine, I couldn't see what happened - even though I was logging when it blew!!!) Perhaps reducing overhead could gain needed CPU cycles, or maybe a combination of a higher processor speed along with streamlined software would achieve better performance?