RomRaider

JDM ones do. Primary fueling doesn't make much sense to me, but maybe it's just the way I tune. I set my fueling where I want it and then scale my injector and MAF scalings to get me to my desired AFR. Perhaps in the future having different ROMs might be the way to go if we can't fit everything into 1, but you're right, for simplicity 1 would be best.

If that's the more common way to tune than that makes sense to me.. I've said it before, I'm no tuner and I'm not the best to make that kind of decision. Better yet if we could fit both. But if not, then maf scaling is a much smaller table.

Sounds like changing 2d tables to verticle instead of horizontal is going to be a pretty big deal...

I would love you forever if you could do that. I absolutely HATE the way RR displays MAF scaling

I like the idea of adding code to initialize the RAM tables with the contents of the ROM tables after an ECU reset. Then you can just tweak the ECU code to run from the RAM table 100% of the time, which means that the changes to existing ECU code would be tiny - just insert a call to the new code, and change the table addresses to point into RAM rather than ROM.

The drawback to this approach is that you wouldn't be able to put a different set of tables into RAM without reflashing. But I'd rather have some live tuning than none at all, so I still think that getting this working would be a big step in the right direction.

@eleven, yeah, evidence that I have no real world experience. I had no idea horizontal was going to be a problem when I implemented it.

@NSFW, I must have missed the idea to copy tables to ram and just use that. Great idea. My guess is that would be a tougher change to make in the ROM, but I'll leave that to the guys that know.

If we don't do that, though, adding an extra byte to tell the ECU WHICH table is to be read from ram WOULD allow you to choose without reflashing, as you alluded to. Definitely a decision for the guys who know more than I do about the ECU.

IF we have enough free ram to store all the tables we want, we could have the best of both worlds and the only time you'll ever need to reflash is when you're happy with your tune. Or when you want to change another table, of course. In which case it would be easy to lose any RamTune changes, so we'll want to make a provision for saving that easily.

We could just set a bit with the defogger switch or something to tell it to read from RAM instead of ROM. By default, or on reset, it will read from ROM. Does that make sense?

I actually think it would be easier to do the copy once, and then read from RAM the whole time.

For the ECU code to check a value before deciding which to use, we'd have to hook the ECU code in each place where it reads from a table that we want to put in RAM. That's not terribly complex, but it's not as trivial as simply changing the pointer to the table data structure so that it points into RAM instead of ROM. Adding a hook that copies tables from ROM to RAM at boot time would be easier, since you'd only have to insert that one hook. For 32-bit ECUs, where we apparently have lots of RAM to play with, I like this approach.

Ultimately, I think it really only depends who's gonna write the ECU code. I'm not ready to commit to doing it, but I am thinking about it.

I'll second that

There is another approach for realtime tuning.
This one does not require memory for table storage. Just some variables are to be allocated.

Live tests show that it is possible to read out a couple of parameters ( EngineLoad and EngineSpeed for example), calculate an appropriate correction ( TargetAirFuelRatio or IgnitionTiming) and return those corrections back to the ecu.

8 bit processor did this routinely within 50-70 ms. This time period is determined by SSM protocol data transfer solely.

I think that PC may be as fast as well. Ignition advance has such an additive (0-5 deg) "as Subaru native". Other corrections will need evident ROM patching and RAM allocation for tuning variables one per table or less. Formarly one adder for all ignition tables ( is already allocated ), one for all fuel tables and correction and so on.

Such a way allows realtime calibrations. RR may be a tool that holds current ROM table copies and desired tables and calculates\returns corrections on the fly.

ECU patch should also checks for timeouts for tuning values data exchange in order to cancel corrections and go back to stock in case a laptop\tuning program\SSM communication failure.

Alternatively an appropriate "hardware parser" may store paired tables (ROM and corrected tables) or just corrections required, calculate differencies (or get precalculated corrections) and return those to ecu while PC itself just sends user table updates to the parser in realtime. The parser continues to work and provides corrections according to the last table updates after PC is disconnected or PC program is stopped\failed.

There is no magic at all. Such an approach (a hardware parser) is proved for IgnitionAdvance. The only restriction for an unmodified ecu ROM was the 0-5 degree ignition retard limits set within the stock ROM.

JECS\Hitachi ecu's have embedded ability for real time tuning for fuel and ignition vs Load\RPM.
32 bit Denso ones have the same for MAF vs Load and ignition vs Load\RPM.

You just need to correct\update learning values realtime. This can be routinely done via dedicated debugger processor port ( RTD for Mitsubishi M32R, AUD for SuperH Renesas) or SSM WriteMemory command ( that should be enabled in the code for required memory location ). The first approach allows data to be updated with 10-20 ms period the second one do this with 100-200 ms period.

In case the computer is disconnected ecu software forgets applied corrections smoothly.
I just use dual powered adapter that constantly rewrites corrections downloaded from PC

Another question is the user interface - currently I have to run homebrew toolchain ecuFlash\Renesas FDT on the fly. Nevertheless an integrated tool is more applicable for realtime road tuning.

Any update on this ?

You seen the way the EVO definitions are for ECUFlash?
2 MAF groupings:
1 long horizontal
3 short vertical (MAF 1 covering low volts, 2 covering middle volts, 3 covering high volts)

2 references to the same information. the 1/2/3 method means you can get it all on the screen at once easily.

I hope this isn't dead. I would love to have real time tuning and map switching (if possible on a 512kb ecu) I would donate for this.

updates?