Really cool ideas.
I like your thinking and don't intend to rain on your parade, but...
Just "riffing", here are a few pitfalls I think you might run into in practice:
1) When the PPROG register is not cleared i.e. during erase / programming, the datasheet seems to indicate the eeprom cannot be read just like ROM. What will happen? Test it and find out?
2) Bad things could happen if during an erase + write procedure the PCM needs to read something from a cell of a relocated table for instance like spark advance, and does so immediately after an erase, but before the subsequent program (eeprom contains #$FF). Switching off the table relocation temporarily would remedy this and pitfall #1.
3) I know almost nothing about how the two $EE programs work, but to draw a parallel to my diy-ltcc firmware I'm almost certain bad things would happen if you blocked the main loop for 10 ms (a write or erase cycle) while the engine was running. You'd need access to a timer / counter here to prevent holding up time-sensitive processing (aka starvation).
All in all though, still not a bad idea in theory. I don't know what tables could functionally be relocated to eeprom, but tuning tables like VE and spark this way would certainly reduce the need for slower and slightly more hazardous flash erase + programming cycles. I use the qualifier "slightly" because it seems flashhack is nearly bullet and idiot proof.
Edit: After some more tuning oriented thought, there are probably a half to nearly a dozen different constants that would be incredibly useful to have control over and would likely be extremely benign if fed transiently anomalous data. Injector flow constant, cylinder volume, prime pulsewidth multiplier, probably four or five I haven't thought about in two years. If easily relocated, those would be very useful for injector swaps and extreme VE / displacement changes.
Bookmarks