Update: I have the ECU patches for DMA read/write/log working and tested on my ROM (including abuse testing such as pulling cables during comms, repeated loops of writes/reads etc). I have them tidied up so that they should be quite portable to other ROMs with as little work as possible.

Tephra is working on v5 for my ECU, when I get it I will apply my patch to that. Meantime I'll write the PC software to write the blocks of the ECUflash ROM file to the RAM of the ECU.

I anticipate that after that a tweak to the Tephra patch will be required to move the pointers to the maps he switches to RAM so they become editable. To go with that a routine will be required to copy the maps from ROM to RAM (they'll all be in a block) when the ECU is powered up after a reflash or battery disconnect.

The DMA stuff should be a flexible setup that will allow all sorts of logging and realtime innovations because they give a framework for fast block memory access to the ECU. Having extra tables in RAM will be a case of:
Defining your tables in Ecuflash to allow editing of them
Putting the table headers in the allocated space in the ROM
Changing the ECU's pointer to these tables

The last part is trickiest, comparable to finding 2 byte load/RPM etc, but well within the capabilities of many now.

It is worth deciding now whether you have just Tephra's "alt" maps in RAM and the original in the original place in ROM, or whether we have two sets in RAM that we switch betweem, making both editable. My stuff would accommodate either arrangement.

 

Could you not ask tephra to put that option into his rom, so that it's user selectable ?

i.e, select original map in rom, or in ram, alternate in rom or in ram ???

So you can select both or 1 or the other as and when required ???

 

It is certainly possible.

 

Further update: PC software now reading block from Ecuflash ROM file, writing it to RAM, reading it back to verify. All works nice except a timeout when we get up towards 2k blocks. I'll fix it

 

 

Timeout is exactly 0.5 seconds, and so far the timer that is cutting it is a little elusive.

Hence at 38400 baud it occurs at 1920 bytes. I can get 3k through it at 62500 baud before the timeout, but I would like it to have the ability to do 4k blocks at 15625 baud if necessary.

There will be a programmable way around it, which I'd prefer rather than splitting the transfer into chunks (even though the user wouldn't notice it would not feel elegant to me).

 

I have a small end user suggestion to ease usage and further allow a real-time tune to be possible.

Option 1:
Instead of having to manually clicking an upload button in your program after hitting ctrl+s, can you not have the program have a macro detection setup so that when it sees ctrl+s hit that it would automatically upload the changed blocks?

Option 2:
Another suggestion that eliminates even another user interaction is if your program could constantly scan blocks and upload them when they are different. This would be similar to an auto-save after changing a value and means that the end user just changes something and the value is immediately uploaded.

Option 1 should definitely be implemented. I can see where Option 2 can quickly get you in trouble as well as cause unnecessary writes if one block keeps being changed before the end user finds it satisfactory. So perhaps it can be an option in your program to toggle an "auto-upload" feature.

 

I think option 2 isn't a good idea.

If the program auto writes to the ecu when something is changed, and you accidently hit a button when being driven about (notice I didn't say when driving) then you could get into trouble very quickly imo.

But option 1 sounds like a nice idea

 

Option 2 would be death.

For Option 1, I believe the ctrl + S is still coming from ECUFlash so your not going to be able to get rid of that step unless JCS is going to hook another process which is the cheapest way to get that done. But that was when last he posted here...maybe has has something new now.

One way to do it i suppose would be to create a filewatcher on the rom directory and when a rom is updated then it just assumes its the right one and goes with a write. This could go bad if for example an Anti-Virus went and edited another rom and instead that gets shot off into the ECU

 

I was wondering about a macro that hits Ctrl-s in Ecuflash and then hits write in my app. Should be easiest of all?

I've been a bit busy looking for another house to rent (our bubble is about a year behind the US I reckon - I have already sold up) and building a new PC (overclocked 45nm rocks ) so not yet worked around this timeout. I tried to rewrite the serial receive interrupt and pickup from there, but it didn't work. This appears to be the last issue to sort and I hope to do some more on it tonight.

 

You could actually write something that looks for the ID on the save button in ECUFlash and then clicks on it then do the same for your app. You would need UI Spy to figure out the internal MSAA information for the buttons and then use it in the code.

Haven't done UI automation in flat .Net in about 4 years now so I'm going to be pretty rusty there .

 

Now I've managed to stop overclocking my new PC (4GHz on air Orthos stable), put Crysis down for a while and found another house to rent for very little (Victorian farmhouse down a tree covered private drive with views for miles over beautiful coast but maybe a bit chilly in winter ), I've worked out that it wasn't the ECU putting in a 0.5sec timeout, it was me! I had the FTDI timeouts set to this to give a prompt reset LOL.

So now we have 4k blocks being written and verified with the engine running at 15625, 19200, 38400 or 62500 baud. 19200 and 38400 are Pocket PC compatible.

Given we have 1 start, 8 data, 1 stop bits then the number of bytes per second is the baud rate divided by 10. So 4096 bytes to be written and verified takes 5.2 secs at 15625, but 1024 bytes to be written and not verified takes 0.16 secs at 62500.

On my travels I also found two different ways to tap in my routines - either through rewriting the serial receive interrupt or through a hook in the MUT processing routine. MUT (at your specified baud rate) and OBD Scantech work as usual of course with either method.

 

Quick enough baud rates me thinks Real time tuning to come shortly I'm sure.

 

Sounds promising now

 

Congrats on the house John! I cant wait to see the real time tuning in action