RomRaider

Have you guys worked out how to detect a restart of the ECU after a power down or ECU reset so that you can ensure you have the maps copied to RAM?

Like your real time tuning I want to make sure there is data in RAM before the engine tries to start and simply change the map vectors to point to RAM rather than worry about testing status variables every time the maps are accessed to see whether to read from RAM or ROM.

Since I have SH7054 and you have SH7055 I'm sure it will be the same. Do you know what happens to the ECU when the engine is turned off and which vector it jumps through when the ignition key is turned on?

We haven't messed with real-time tuning for the SH series yet, but for the Freescale HC16 (02-05 usdm wrx), I have a bit designated in ram that determines whether RT tuning is active or not. If clear, maps are read from rom. Obviously a hard reset, say disconnecting the battery, would clear the active bit and maps would automatically default to the rom. This is the first bit check in the sequence of code. When the functionality is added RomRaider, when the user loads an RT map, the active bit would be set.

OK. We should talk more because on the Evo we have no routine to read/write memory, just logging. So step 1 to realtime tuning was to write a routine to read/write any memory location which I've done for bytes, but am improving to send up to 16 byte packets at 62500 baud

Step 2 is to copy maps to RAM.

Step 3 is to use the maps from RAM with safeguards to make sure it is populated.

There is some debate at present as to whether to use DSMLink/AFC style sliders for each 500 RPM zone to adjust timing and fuelling up or down as this works really well for live tuning as you don't have to worry what load zone you're in, and you just make a final modification to fuel and timing after all the maps have been looked up. Then you can test a variety of boost levels and the flash changes to the ECU proper. This saves memory certainly. Simple is sometimes more elegant?

I always find it difficult to live map a 3d map neatly on the fly and usually end up changing cells in blocks at one RPM level anyway. For example my timing is only 1 degree resolution and I find that 220-240-260-280load (approx 220-280kPa absolute - 18 to 27 PSI approx) needs about 2 degrees dropped per 20 kPa increase in boost. I leave the desired AFR flat in the boost areas with increasing load otherwise I get the higher gears much richer than lower gears even though I use gear judge AVC-R boost control.

If someone else is driving or you're on a rolling road then clicking up or down the timing during a pull is workable with sliders but not with an actual 3d map I find.

Thoughts?

Larger versions of above:

http://www.dsmlink.com/images/screenshots/fuel.gif

http://www.dsmlink.com/images/screenshots/timing.gif

Our logger also has live tracing, which I think is the best solution to live tuning. Sliders might be ok for the professional tuner, but aren't exactly noob-proof and would probably cause more problems that they are worth. Certainly the user could highlight a row or column and increment or decrement all the values in that row or column at once (or select any number of cells by highlighting them and then inc/dec all at once). Plus I think with sliders, users would try to live tune their cars at the same time they are driving - not the best idea, whereas modifying using live map tracing might encourage them to use a co-pilot.

The functionality for RT tuning hasn't been added (or started) for RomRaider yet, although the rom code is done and I've been running it on my 02 wrx for about a month now. As far as safeguards, I can't think of an efficient way to verify if ram is populated with table values or not, so the use of the "active" bit ensures that if ram is cleared, rom tables will be used. The ram address is also checked to make sure it is in a valid range. If not, the active bit is cleared and an error bit is set (which could be read by RomRaider).

All good points.

Are there comms speed implications if for example the user is incrementing a block repeatedly by 0.3 degrees or whatever the Subaru increment is? Using a PowerFC and FCdatalogit, it was a bit slow to inc/dec blocks, although that could've been my slow laptop.

At the standard Evo MUT 15625 baud we can cram up to about 180 byte request byte replies per second through our logger. I wonder if when I reply with packets whether I'll get the packets out at that same rate since there appears to be some slack in the comms rate compared with the amount of info transferred so it isn't talking all the time. I suspect the ECU only deals with the comms every now and again. I think I'm only adding a microsecond or two of processing so far.

We haven't got that far yet. I'm thinking that the user will hit an upload button, rather than the changes being made actively everytime the user modifies the map. This would prevent accidental changes - say you mistakenly enter 40 degrees of timing at peak torque.

The PowerFC had the option for either, that would be nice.

A professional Subaru ECU mapping solution I used to use would corrupt the ROM image when you did live tracing over it and then stopped in a certain way. I managed to save a ROM with a 0 in the fuel map at 4000 RPM. It behaved just like a fuel cut and the colour didn't stand out. Took me some time to find the bug as I couldn't read out the ECU image. The potential for problems with realtime mapping is greater still.

Interesting. But not much you can do about it as far as rom code is concerned. You couldn't do a checksum of each ram table every time it is accessed - it would cost you way too many cycles.

Would it really use too many cycles? The comms are the slow part, you can get an SH2 to absolutely romp through a checksum of a block of memory. Use long indirect addressing with postincrement and a block of say 16 repeat instructions rather than loop for every single one.

eg.

loop:
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1
add.l (r0)+,r1

counter and loop...

Should take about half as many cycles as cells in the map you've changed if as I recall the above are all single cycle. 200 cycles at 40 MIPS? 5 microsecs?

Well, I'm no expert when it comes to embedded systems, but I would imagine you would want the code to be as minimal and efficient as possible, especially a custom function that is executed every time a RT capable map is accessed. Not sure what the cumulative impact would be. Also, in your example, since the processor executes 5 instructions at the same time, there might be performance penalties when using the same register in consecutive instructions.

Perhaps the writing application can perform the checksum after writing, although depending on the table, there would be a slight pause - perhaps grey out the upload button until the data just written has been verified.

I wouldn't get too hung up on these very quick (in CPU terms) processing packets even if it isn't pipeline optimised. Some of the Renesas division examples use a series of 16 identical instructions for speed, so it doesn't seem unreasonable.

As far as I can tell on most ECUs the time sensitive stuff like turning on and off the injectors and coils as well as reading sensors at the right time is all done through the timers and interrupt driven.

You can run a nice ECU on something a tenth of the speed of an SH2.

You'd soon know if it was misfiring. My old Atmel AVR MAF simulator did this because I did the comms in a quick and dirty way.

Sounds good to me!

What is your timeline for coding, testing and release of the RT tuning for the Evos?

I'm trying to work with the logger writers to output packets first to develop in some other directions.

I suppose the ECU side can be done quickly but the PC side is the problem? It makes sense to do it in the same way as you guys so that RomRaider might be able to work with it too? I don't know how RomRaider works under the hood, but presumably if there is an Evo logger written for it there would be xml files that could be edited to specify the protocol to realtime map?

I'm also an amateur with no IT training - I'm a GP/Family Doctor.