jcsbanks

I have a working test of Tephra V5 + DMA logging + DMA live mapping of the alternate fuel, timing, boost and injector scaling maps which are now stored in RAM which is automatically refreshed from ROM if the ECU is reflashed, reset or disconnected.

In the screenshot the left part of the screen is the logging baud rates/directory/start/stop/edit logged items etc. In the right part there are the addresses and size of the block in ROM and RAM that contains the alternate maps. Also the logging address is presently set to the base address of the MUT table, but this can be fully customised - you could upload a logging table to RAM if you like and edit it in Ecuflash with the engine running. The area to the lower right is where you choose the Ecuflash file we're working on.

Start logging... edit alternate maps in Ecuflash... hit ctrl-s to save... hit write in Evo Live Map to write and optionally verify. All with the engine running and without using up a reflash.

Questions?

JohnBradley

iTrader: (30)

This is really a nice development...Congratulations John

So are you using the alternate map to cache or you are live tuning both maps?

logic

iTrader: (2)

Whoa, wait...on top of the DMA logging, you've added a flashing tool as well? I was waiting to see how the DMA stuff panned out, but I didn't expect you'd be integrating flashing as well. Please tell me you're going to release the source for this.

(My agenda is getting an open-source flashing tool running on Linux (and optionally Windows), and the only GPL- or BSD-licensed source I have to go off of right now is a two or three year old DOS version of EcuFlash that Colby released a long time ago. I've been slowly reimplementing a few of the things that EcuFlash currently does in Python + wx, with the plan of leading up to a combined MUT logger/data analyzer (via libmut) and flashing tool (via Colby's old source). I was holding off on any of the serial stuff until I saw more of what you were up to on the DMA implementation, as it makes more sense to just jump to this if it looks like it'll bear fruit. Very cool stuff. )

Edit: Ah wait, I see what you're doing; you're pulling the updated maps from the ROM, and pushing them as a live map update, not a ROM reflash, yes? I apparently need to work on my reading comprehension skills. ;-)

codgi

iTrader: (22)

^^ beat me to the correction . Good work John.

What I am paticularly interested in (and will watch to see how testing of this goes) is how does the change affect the car if it changes the part of the tables in RAM that the car is in right now. For example if the car is idling and you change the tables for WOT no biggie. But if you adjust the idle tables live now?

l2r99gst

iTrader: (2)

Great work, John.

Codgi, if you update a table in RAM that the ECU is using, it will simply start using the new values that you changed. If you are familar with DSMLink, this is what DSMLink does. DSMLink is all RAM tuning...you never flash the ROM at all. This enables you to quickly make changes to your tune while the engine is running and without using up a flash to the ROM.


Eric

jcsbanks

As Eric says, it seems to just work smoothly as a standalone would. Tephra's patch has a load threshold above which it doesn't map switch. My setup allows the alt maps to be used to run the engine whilst editing them. My main use of this would be mapping a car from the passenger seat, and I would just get the driver to cruise whilst making adjustments rather than making them during a pull just yet. Depending on how good your instrumentation and graphing is, I find I cannot possibly take in all the data hitting me during a pull without some post-hoc analysis, so to adjust it all would be a tall order. However, if we become more confident with the safety of this, all it would need is changes to the PC application to say allow tweaking up and down during a dyno pull - say changing one variable at a time like ignition timing.

tephra

iTrader: (6)

yes this would be most useful on the Dyno - where you can sit at a specific RPM.

still useful on the street thou, do a quick analysis of the pull and make changes without flashing. Once your happy with the maps make them permanent!

Tuner@Swift

iTrader: (1)

I've been using a version of real time flashing for awhile. After a pull, I make the adjustments and hit flash while the car is cruising down. It's usually done in time for me to restart the car and go again.

Good job on this though, John!

MR Turco

iTrader: (16)

Wow, awesome john! I cant wait to play with it.

codgi

iTrader: (22)

Eric, I understand how the technology works, but thanks for explaining it to me anyway . There are some pitfalls with DMA, latency and caching. The particular case above is where if there are flaws in this implementation it will show up i.e its a very interesting test case and if I had to burn some time testing, and thats all I could test that's where I would concentrate my chips. But then again I'm only a little Software Test Engineer so I guess I'm not qualified to ask such questions .

jcsbanks

The SH2 DMA is run on cycle stealing when using the serial port, at 38400 baud the percentage of cycles stolen is miniscule . There is no cache or latency beyond one byte. Our maps are 1 byte, otherwise there is a possibility of an error if the ECU was accessing the map when the MSB had been written but the LSB was still to be written. I have tested the DMA running continuously at 62500 baud overwriting the active fuel and timing maps and can detect no issues. I think that is good enough to ask people to do initial testing at their own risk. It only makes sense to do editing first with the engine off, then at idle, then on cruise before thinking about doing full load editing.

Presently a communication failure during a write will leave the last complete byte written to the map and an error displayed in the box. This could still be the active map the ECU is using if alt maps are selected at the time. There is then a need for the user to re-establish comms and not assume anything about the map contents.

From my reading of the protocols used by the Apexi Power FC and Datalogit/FC commander I think this should be as robust.

cossie1

So for the moment this will only work to alter the alternative map, not the main 1 is that right ?

Also you say it alters the map in the ram, can this then be copied into the rom so that it doesn't get lost if there was a power loss ??

jcsbanks

Yes for now just editing alternate maps. To change the main set as well we would change the pointers to those and make a master copy in ROM with them all together in a block. Not too hard, but we'll run out of space if we go mad on the Evo 7/8. I do wonder if we should just have high octane maps in RAM.

To make the changes permanent you simply use Ecuflash to reflash the latest ROM you just saved and tested in RAM.

cossie1

Thanks for clearing that one up

Ok, just wondering could you put the pointers in, so that your prog can give us the option to edit standard maps in ram, OR alt maps in ram, but obviously not do both at the same time ???

And just wondering how much free space is there in an e7/8 ecu ?

jcsbanks

There is about 2K RAM spare in the 7/8 ECUs I've looked at, we need a bit of space for Tephra and JB variables as well as maps. We also need the space for the map headers as well as their contents... it will fill up fast with lots of 3d maps. We need the space in a block, present in all models, and not too close to the stack coming down from the roof to hit our RAM maps

Putting in the options raises further issues - program code will be more complex/need more space/risk bugs. As well as the options you'd also need space in ROM for all these backup maps, in some models it isn't there.

If you're cute you could handle your own pointers and customise it.