RomRaider

Also, for orthogonality purposes, and if it's not a big deal for you, let's keep the old on/off convention instead of a special "FactoryOff" type of switchgroup. Again, easier from a Java coding perspective:



For a given patch upgrade plan, the "off"s will be patched first as you designed.

J

Patch_def.xml


RamTune_def.xml


I think we're closing in on this. Once we get this hammered out, I should be able to start coding aggressively on it. I really like keeping these things separate. Besides not allowing the user to shoot themselves in the foot, it means that their modular nature will ensure easy future expansion.

J

As discussed before, however, then you HAVE to support every single version of RamTune that has every come out. So, let's say we release 0.1b with static maps and 4 map assortments. Then we come out with version 0.2b with some improvements. Then 0.3b with SD. Then 0.4b with dynamic map switching. So, all those version's on/off values would have to be fully defined in the definitions and all future definitions as well. Why? Because undoubtedly there would be something that was patched in a previous version that is no longer patched in the new version so the factory values would have to patched in order for everything to work properly as the user upgrades. Of course, a lot of this would overlap, so you are really just defining a bunch of duplicate off values. So, by having a factory default off value group that covers all previous changes you don't have to define anything from previous versions - just the current version (as long as you only allow support of the current version in RomRaider).

Doh, ok, you're right. Wasn't thinking for a minute there. I'll change it to reflect that. Sorry, I've got work sharing the same brain cells

How about a "<patch>" that has a "isStock" attribute that defines what it takes to return an ECU to stock? Basically, an easier-to-code-for "FactoryOff" type switch-group.

J

There will be more than just the lut for each map assortment as shown in my example for patching. From your proposal I don't see a way to group multiple switch tables for each map assortment patch.

Yeah, like I said, whatever works for you. As long as the basic elements are covered.

Updated "Patch_def.xml" (rev. 6):




It's subtle, but I included a "reference" attribute that basically defines the inheritance mechanism in version 5 of the "Patch_def.xml":

The reference points to the patch who's id is "base". All of base's switch-tables are linked using this definition. But it's entirely up to you if you want more:

The XML above defines that the "RamTune (Basic Scaling)" patch should have switches from the "base" map, a switch at "0x01FF34", and one last switch at "0x00340A".

You should also be able to chain them or provide multiple inheritance, but collisions in the address space should _not_ happen. In other words, if one part of a switch would over-write another, then there should be an exception (but that's actually kinda difficult to code for, so you may just get a silent run-time error).

Does this answer your question? Does it sound like it would be a good fit?

J

looks good.

Oh, I don't know if it's obvious or not, but don't start on the definitions just yet (I don't know what your process is for that project). We'll want to work all of the kinks out of this schema using one ECU definition first and then apply that to the rest of them.

J

Just to throw a wrench into the works...I came up with some new code for the 16-bit RamTune with map switching that is much more compact (Ramtune -> 70 bytes new v. ~200+ bytes old, Map switching -> same 44 bytes).

To clarify, these were the three options we always had for RamTune:

Option #1 - what we have decided on recently. The simplest of real-time tuning setups. Static maps with NO map switching. After a reset, RT maps are copied from rom to ram. ECU always runs RT tables from ram regardless.

Pros - easiest to implement on the RomRaider side / smallest rom code size / concept is similar to current commercially available solution so it has already been proven by a larger user base

Cons - no map switching / no way for RomRaider to turn off RamTune if it encounters an error (say a write error) / more individual patches at a different addresses


Option #2 - RamTune with map switching and static maps. Allows user to switch between RamTune maps and rom maps on-the-fly with combination of defogger button and other condition (like rpm/veh. speed).

Pros - map switching allows user to run essentially two different maps and switch on-the-fly or switchable through RomRaider (say fuel economy and performance, valet and normal, etc.) / Less individual hacks to existing rom code makes it a little easier to create patch definitions especially for different map assortments / Would be unique as this feature is not available in any reflash solution for Subarus / RomRaider, when live tuning, would be able to disable RamTune if it encounters an error

Cons - Slightly more complicated to set up on the RomRaider side - A. UI has to be setup for determining/changing RamTune active and map switching status B. rom lut would not support copy data so RomRaider defs would have to define this (to copy from rom to real-time file as a starting point for user tuning) / Unproven, untested concept / more rom code necessary with on-the-fly map switching


Option #3 - RamTune with map switching and dynamic user map selection

Pros - on-the-fly selection of RT map assortment by user could be very useful by the advanced or pro tuner / Same Pros as option #2

Cons - Same cons as option #2 PLUS less tables at any given time due to the lut being stored in ram and taking up space / Excessively complicated to set up the UI in RomRaider for this option / May be too confusing to use for many users.

So, the new code I've come up with covers option #2 and can easily be changed for option #3. For option #2, it is only 50 bytes more code than option #1. If we remove the on-the-fly map switching through defogger switch, then it is only 10 bytes more - user would still be able to switch from ram to rom maps but only through RomRaider when live-tuning with a tactrix cable and laptop.

If we decide to go with option #2 with the new code, it would require these additional elements for RomRaider:
1. Would have to define in the xml the start address and number of bytes for copying RamTune maps from the rom to a RamTune file. Previously, this is would be done in option #1 by the data contained in the lut. The new lut won't have this info, so it must be defined so that a starting RamTune File can be created from a user's rom when the user starts tuning in RomRaider.
2. Would need to define the RamTune Active bit, Map Switching bit, and Error bit in the xml.
3. Would need to add functionality to the RomRaider UI to determine ramtune active/map switching/error status and allow user to change active(yes - no)/map switching(rom - ram) status as well. Also to set error bit if there is an error in the writing process (checksum) and to prevent users from tuning or enabling RamTune when the error bit is set.

Anyway, I haven't tested this new code, but this might be something that would be beneficial to do now that the biggest downside (large code size) has been solved for option #2. If anything, we can leave out the map switching on-the-fly option for now and the code size is basically a wash between option #1 and #2. The user will still be able to switch between rom and ram maps with RomRaider and their laptop when live-tuning.

Because the code is now compact adding other possiblities with option #2 would be trivial. Such as automatic rom/ram map switching based on any input such as load, throttle position, etc (or any combination thereof). That is, you could have basically a WOT map and a non-WOT map that would switch automatically. Or a WI system that uses an available ecu input and would switch between rom and ram maps automatically based on the input. Of course, these would be features we would add down the road, probably not in the initial release, but they are options you couldn't do at all with option #1.

I don't have a problem doing all of that, but let's make it happen in iterations.
It doesn't sound like the future functionality will be impacted negatively by what we're doing right now. I'd vote we stay the course and release when we get what we've currently signed up for working and tested.

BTW, good job on freeing that space in the code. Judging from what you've told me about the room, that's a lot of space.

J

Well, I think it will be hard to shift from one to the other later on as the patches, lut key and some of the definitions are completely different. I guess you can continue working on it as planned as most of the basic functionality will be the same. In the meantime, I'll whip up a prototype of the new version for testing on my car. The code is already written and the logic hashed out - so it is more than a rough draft at this point. I think it will also be a better fit for the 32-bit ecus when that capability is added later on. Overall, the new code is easier to implement among different rom revisions that the current proposal.

The new code also would not absolutely require the master off patch (although it would still be useful). This is because we are not modifying the rom map offsets (as option #1 does), so changing between map assortments only requires changing the lut for 2d/3d tables (making creating definitions for the different map assortments a lot easier). 1d tables require more but the only really useful 1d tables for RamTune are probably going to be injector flow scaling and rev limit.

The new code with option #2 is a much more elegant solution requiring a lot less hacks of the existing factory code, less effort to create definitions (and less chance of an error), and the ability to disable RamTune if RomRaider encounters a write error.

Basically, each option simply represents a super-set of coding as far as the application is concerned, but I understand that each release of RomRaider ROM patches is a lot of work. Plus I don't want us to be behind Cobb in terms of functionality so, let's go for option #3.


Aren't we using the "off" patch for upgrading RomRaider ROMs?

Does map-switching in option #3 rely on the application to perform the copy from ROM to RAM and vice-versa? How do you see that copy operation happening?

J

I was suggesting option #2 (map switching with static maps). While option #3 would require one small change to the rom code (from #2), development for the RomRaider UI would be a HUGE leap in complexity and the end result may even be too confusing for users. It is always something we could do later on, if need be. Trust me, that going with option #3 over #2 would probably quadruple (if not more) your development time. Option #2 would not add any significant development time over #1. And option #2 still blows the commercial Subaru solutions out of the water.


With option #1, you really need the master off patch which we were discussing. Not as much with option #2, although it would still be useful so we don't have to support all the old versions. This is because option #2's patches are more condensed into specific areas instead of a bunch of small patches all over the rom as in option #1.


Option #2 and #3 do not need any copy to occur at any time. If ram is cleared due to a reset, RamTune and map switching are disabled and the ecu switches automatically to the rom tables. RamTune/MS would continue to be disabled until the user uploaded a new RT map to the ecu by live-tuning with RomRaider. The copy I was talking about was in RomRaider where the user wanted to create a new RamTune file to tune from offline. The user would want to start a RamTune file with table values based on their current tune. So, RomRaider would need to know where to copy and the size of each RamTune table in the rom. User opens their rom in RomRaider and selects 'Create new RamTune file'.