RomRaider

No, don't need ram dumps at this point. Just focusing on the 16-bit ECU right now.

I should note that I already have tested version 2 with on-the-fly map switching as far as the ROM code is concerned. Just developing it for the RAM writing utility would take longer. Changing to version 2/3 later after already supporting version 1 would be a PITA as they are completely different and would be like starting from scratch.

Thinking about it more, the amount of time to add version 2 capability over version 1 to my utility (I'm going to give it a temporary name - RamWriter), is negligible. So, going with ver 2 will not push the RT tuning back. However, it doesn't have to be decided exactly right now. Almost all of the functionality of RamWriter is identical between both versions, so I can still get started on it without a decision.

The biggest factor in choosing between the two versions is do you want to trade the ability to real-time tune 1D tables (with the exception of injector flow scaling) for the ability to switch from RT RAM to corresponding ROM tables on-the-fly? Looking at my own ROM (02 USDM WRX), there are not a whole lot of 1D tables that would be useful for RT tuning (most are threshold values). 1D tables would be those that do not have an actual axis value. That is, some are marked as 2D table in RomRaider but just have descriptions for the axis. For example, "A/F Learning #1 Airflow Ranges" is a 1D table as the axis values are just descriptions (static text) that read "max range A / min range B", etc. There are very few 1D tables that would be useful for RT tuning. Besides injector scaling, which is already included, maybe only "Closed Loop Base Fueling Target" is the only other 1D table (to me) that would be useful to tune. thoughts?

Here's my $.02.

The way I see this being used would be to allow for someone to tune the car in realtime and then flash that map to the ECU. Set it and....FORGET IT!

In all seriousness, I don't know anyone who really uses map switching in realtime (or really ever switches maps for that matter). Maybe I just associate with a boring bunch of people or something but I would probably make this a lower priority since flashing a map only takes a few minutes.

I would keep the changes as compact as possible to allow space for more maps in RAM. Having some things like temp compensation maps would be nice to have in RAM since I find myself fiddling with them a lot and never really get them to the point where I'd like them. These are all 2d, though so I guess that doesn't really affect much.

Let me know if I can help out.

Thanks!
Mike

Well, now I'm leaning towards version 2. There's a way I can do the ROM code so that it is very easy to implement for different ROM revisions (less work = less chance of screwing up), where version 1 would be more of a PITA in defining potential RT tables. If I leave out the on-the-fly map switching for version 2, the ROM code for version 2 is similar in size to version 1. The on-the-fly map switching does not have to be integrated in the RT code, so it can be added later at any time. Even without this code, the user could still switch from RAM to ROM maps (and vice versa) with RamWriter.

I'll need to limit the total number of tables in the map assortment for consistency among ROMs (this will make it also easier to implement). This is due to the limited space in the high flash area with some ROMs (has to be placed there so RamWriter can read the LUT via SSM and determine your current map assortment). Some could handle only 13 tables, some up to 20, but you are still limited with your ram hole and if the user chooses to include the common 3d tables (fuel,timing,boost, etc.) they are going to be limited to 7-9 tables anyway. I'm thinking a limit of 10 tables for all ROMs which would leave some space in that area for other uses (in the high flash area). Note, I'm talking about a 10 table total limit - that is, you choose any assortment of tables from ALL 2d/3d tables that will fit in the ram hole but you can't choose more than 10 tables total regardless.

Also, another thing I can do is that if an error occurs and the ROM code or RamWriter disables the RAM maps (i.e. ECU switches to ROM maps), then I can disable boost control. This would be easy way for the user to know that something has happened.

That would work for people who use the "stock" boost control, but would not work with someone who uses a "stand-alone" boost controller... perhaps triggering a CEL would be better. No ??

Or maybe a significant IAM drop?

That's true. I could force a CEL, maybe one that is not very common.

So, is the map switching just looking at a RAM bit and pointing to the appropriate LUT? Sounds like the way to go, just an extra branch?

I don't see a need to use the 1D tables, but of curiousity, why wouldn't they work?

The table limit sounds good as well. A free space calculator could always be easily implemented into the software at a later date.

I like the CEL safety, but the boost disable or IAM would work fine for most people. If the CEL can have a new number, and not just trigger an existing CEL #, that would be ideal. Although, you could use the RAM malfunction code.

The main disadvantage to map switching is complexity from a user's standpoint and the additional code required for on-the-fly map switching (i.e. user map switching from inside car w/o laptop), although this could be omitted and still allow for map switching (from the RamWriter).

1D tables do not share a common function as 2d or 3d tables do.

The 10 table limit has nothing to do with the size of the tables. RamWriter will already have to calculate the total size of the user selected tables and disallow any assortment greater than the size of the memory hole specific to the ROM revision. The 10 table limit has to do with the LUT being read by RamWriter via SSM (so it can determine the assortment the user currently has flashed to the ECU). This could be written to RAM to allow for a greater table limit, but this would reduce the size of memory hole and require additional ROM code to write post-reset.

merchgod, could you show us what a full table entry from your LUT would look like, in terms of offset and description?

It would simply be the 16-bit ROM offset, followed by the corresponding 16-bit RAM offset (determined by RamWriter based on the user selected map assortment). So, 10 tables would be 40 bytes.

I think RamWriter map switching for 16-bit and the in-car button sequence map switching for 32-bit would be best.

You could also just get both of them up and running with RamWriter switching only first, and work from there. If we can find an input to use with a switch while this is being developed, it will make things much easier for the user, and the switching code.

On the table limit, I was thinking of a rom-space calculator to determine the max table limit. It would only be necessary if 10 tables weren't enough, so it shouldn't be an issue. Also, with the RAM hole limiting the RT tables as well, its pointless.

Will it be using a separate reference/definition for the offsets of the different roms?

It is already necessary. 2d/3d tables vary in size. You have a ~1kb RAM hole to work with. So, that might be 7 big 3D tables or 25 small 2d tables, or whatever. RamWriter would have to calculate to avoid patching an assortment that is over the limit (I'm thinking a list of tables that greys out tables that would put it over the limit as you approach it when selecting your assortment). The 10 table limit has to do with the lut "key" being visible to the app (via SSM) for which some ROMs have limited ROM space in the upper flash area (might as well come up with an arbitrary limit for all ROMs for consistency).


of course, for the RAM hole size/location, and normal ROM offsets (RAM offsets would be calculated by the patching function).

Sorry about the confusion, I was referring to the upper flash area in the rom, and calculating its free space to determine the maximum limit on the size of the lut. But now that I think more about it, it isn't necessary at all.

fwiw, i have had map switching w/o external hardware (ie laptop, access port, etc) in my car for nearly 5 years.

i can count on 1 hand the number of times i have used that capacity. i agree with mikie on that aspect.

fwiw
ken