RomRaider

For people adding new code to early (2005-ish) 32-bit Subaru ROMs... has anyone ever added code that consumes enough clock cycles to negatively affect how the car runs?

What are the side effects from using too much CPU?

It would be nice to know what to watch out for.

The reason I ask is that I'm working on code to do rev matching on downshifts, and I have two implementations to choose from. The actual rev-matching seems trivial, but the logic around arming/disarming (so it doesn't freak out my wife) and entering/exiting the actual rev match mode (including a timeout), and implementing a calibration mode (to fine-tune the throttle mapping table) is kind of complicated.

The first version I wrote uses a complex tangle of if/else stuff, that probably doesn't cost more than one or two lookups in the fueling or timing tables. I figure this is probably safe to execute, but it's hard to maintain. So I rewrite the mode-switching logic using a lovely state-machine... and that probably costs about five times as many clock cycles as the first version. Not sure if good idea. I think I can get that down to just twice as expensive, but it's still going to be more expensive.

So I'm wondering if I should optimize for clock cycles (the first option) or for readability and maintainability (the second option).

If someone has already found out how much spare CPU capacity we have available, then that would help me decide.

Thanks in advance!

Know next to nothing how much room for CPU load is available. Nevertheless logging is stopping if CPU is overloaded..

C "case" statement maybe implemented as bias table ( which is fast ) and as if\then statement by your compiler.
Hope this helps.

Thanks for the tip about logging, I'll watch that closely to see if there are interruptions or if the data rate changes. That seems like a great way to make sure the new code doesn't add too much load.

Both versions of the code have a switch statement with cases for each state. The differences are in how the conditions for each state transition are expressed in the code - the old version had combinations of 'if' statements for each transition, and the new version uses data structures and a single series of 'if' statements that works for all transitions, depending on the flags and values in the data structures.

Half of the overhead is in setting up the structures that represent each transition - I was putting in RAM and updating everything in them for each transition (after erasing them, so everything get written twice!), but it occurred to me last night that I could just put them in ROM and just update a pointer to the relevant transition info instead. I'll have a couple of other ideas to try too, and I think I might be able to find a solution that is both fast and understandable. I'll work on this weekend.

There's a counter in my code that increments every time it gets invoked, and there's logic to enable the new feature after the driver holds the cruise-cancel switch for 1 second. So of course I had to figure out how many times per second my code gets called...

The code to compute the throttle plate angle (which is where I inserted my code) gets called 125 times per second. So now I have one more thing to watch - if the counter increases at a lower rate then I've got a problem.

I'm not worried anymore though, after rewriting the state-machine stuff I think the CPU load is really pretty small.