Can't wait for this on the 7 roms

 

Sounds like this would be done on the ECU side the way you are thinking. A lot more painful would be to pull that down and do the check on the PC side (which is where I was angling). The tradeoff being pulling it down takes some time, but it does keeps time spent flashing on the ECU to the minimum.

I would keep that window open as little as possible since thats the most likely place to brick the ECU .

 

This sounds great! On the fly map switching? Are you talking about switching between two maps on the ECU already, or flashing a new rom to the ecu on the fly? If switching between two on the ecu (no pc needed, except to trigger the event) would it be possible to use an external input to trigger ths event, such as a switch or something?

That is the only thing keeping me on my UTEC, if I could switch without it, oh man it would be stock ECU time.

Thanks, reguardless, great work!

 

codgi, might it be as easy to simply do a write and then read it back to verify? Or just do a really simply addition checksum?

Jameson, we're talking two map sets in RAM that you can freely switch between or edit with the engine running. The switching can be done with the intercooler spray switch or with another switch.

 

^^ Thanks, I got what you were talking about, just wasnt sure if it just allowed a new map to be flashed with the engine running or it allowed map switching without a pc connected, wiring a switch would be no issue. This sounds very promising, with the loss of support for the UTEC, any affordable on the fly map-switching has been eliminated really.

I for one and very very excited to hear this news and will do anything I can to help/test/wire/whatever. I even considered running 2 ECU's at one point! Look forward to the progress, if I can help let me know!

 

Write where/what though? . I was thinking about this a bit more and the cleanest way I can see to do this would be to have your program open first.

Then you could see the current state of the rom (assuming the copy on the HDD is the lastest one). Thats your base. The change happens. Thats the diff, and thats what you flash.

You know the only areas that are important are where your maps are so you concentrate the diff there.

The flaw with this is the italics above. But unless you pull back down the rom live from the ECU i don't see an easy way around this.

This is of course all semi moot since your biggest challenge is actually going to be hooking ECUFlash to get that button click. There are several ways to get into the messaging stream (where the click information is being passed around and what you would have to intercept) for another program (dll injection et al.) none of which are terribly reliable and some of which probably will not work properly in Vista (because of security changes).

You could of course have your program actually launch ECUFlash, make the change and have the user close ECUFlash. That you could detect simply by having your program block until the child process is terminated. At that point it then goes off and does what you want it do. Bit icky since the user has to change the style of using the program but less work to do and the easiest way to do it if you ask me.

The read at the end would be good for final verification to ensure you've written back what you were supposed to. ECUFlash also does that final check at the end which is peace of mind from my POV.

 

Why not just open ECUflash with the ROM your editing. It is the user's responsibility to ensure what they have is the same as what is on the car. We can recommend a compare to be sure. I don't have time to hand-hold, as it is Ecuflash makes no check to force you to write a compatible ROM to your ECU or not lose your immobiliser code. You can also presently update the wrong ROM and say advance the ignition on a version that is more advanced than what is in the ECU. The user must take responsibility. After all it wasn't long ago this stuff was done on a hex editor

At the same time have my app open, find the same ROM file you're dealing with in Ecuflash. Connect it to the ECU where it runs a keep alive or a logging file.

Edit the live maps in Ecuflash, hit ctrl-s to save to the disk (Ecuflash saves our interesting maps in a "ROM" area that is a shadow of the RAM area we will be using). Hit write A or write B in my app which reads in the blocks to write from the file Ecuflash just saved, writes them to RAM, then reads back to confirm.

No hooks, no rewriting, just the need to have my app open also, and responsibility on the user to ensure they have the correct ROM file open in Ecuflash and my app.

 

With this approach there would be no advantage to having your program open at the same time. The user could just save the rom in ECUFlash then select it from your program and write it when its finished. This is simple even though I liked launching ECUFlash personally but oh well .

You can do it however you like. I'm just here to find the flaws with whatever approach you take and to hopefully help find the approach with the least amount of flaws

 

Thanks, I need a flaw finder

If my program isn't open then there is a big delay in writing as the ECU has a 2 second init.

 

But if I am just editing the local map in ECUFlash you would still have this delay no? I can buy this if you d/led the map in ECUFlash or did any communication with the ECU before hand.

Its possible that it does do that once the cable is connected and I don't know about it, since most of my ECUFlash time is on the couch away from the car .

 

The whole point was to be as near instantaneous to make changes as possible with the engine running and keeping MUT/OBD-II compatibility. Two keystrokes and your latest map is in the ECU - all the time with the engine running smoothly.

If the user has my app opened and connected the ECU and then makes changes in Ecuflash, they simply hit ctrl-s in Ecuflash and then click write in my app. Then you could make lots of sequential changes and test them almost as fast as your fingers can move

The present system for example for setting up boost is lacking. If you are reflashing to change the wastegate duty cycles and then restarting the engine, testing max boost again, you take a lot longer than sitting with the table open in Ecuflash clicking up and down as the ECU is running and then pressing another button to write it to the ECU live. You also heatsoak the car, use up one of your flashes, wear your starter motor, possibly cook some turbo oil, and if doing it on the road you have to find suitable places to pull off the road to reflash etc.

I cannot see an advantage in introducing delays, extra steps for the user, opening /closing apps/files, waiting for 5 baud slow init etc?

 

jcs will this still utilize an input switch, say in place of the intercooler sprayer we dont have (well some of us), to switch maps? Or are you only focusing on switching maps with a laptop connected for tuning purposes? I was thinking it would be more like a race-gas/93oct map switcher??

 

If I just take the cable and connect to the ECU and turn on the car does that save the 2 seconds or not. Thats what I am trying to get to the bottom off. If it does then you have a case point, if you only save that 2 secs after you have already done some other action in ECUFlash (write/read etc.) then you are going to end up burning that 2 secs no matter what.

Basically define connected above .

 

The latter. This is more for making changes on the fly with the engine running.

For map switching with the switch you want this thread:

https://www.evolutionm.net/forums/sh...d.php?t=313893

 

No you don't save the 2 seconds in that instance. By connected I mean having the ECU powered up (engine running or not), cable connected to laptop or PocketPC and the 5 baud init done and a keep alive being sent at least every few seconds if not actual full blown logs being written to disk.

For some applications where you are making repeated changes in a short space of time then the extra 2 seconds may matter. With my solution you can actually adjust something during a WOT pull through a gear if your fingers move fast enough... a 1K block at 62500 baud should move in under 0.2 seconds.
If you were to do an init and use MUT at 15625 baud it would take 10 seconds. With a graph or numeric display of appropriate logging items you can see the result immediately it has been written. It is maybe more than people need, but is there an advantage to forcing a 5 baud init and fresh connect for every change? We put it in RAM and make fast comms to make it slick for the user? There is no real "expense" I can think of by making it snappy, so why not?