this is not an executable pc app then john?
just extracted it and no installer/run ?
so does it hash in with ecuflash somehow?

 

I can't imagine needing every table in the app - i think you mentioned that before. I think what you have so far along with Inj Latency and basline wgdc would be beneficial. I also think having the map tracer on all the tables would be clutch.

If someone who really knows what they are doing could make the app have a "Table adder" feature that could be even better. The user could create the table size, enter the addresses needed and it will auto populate a tab page with the table. Obviously i have no idea how difficult that is but it might be something to consider.

For logging the DMA has incredible resolution. I would say the logging could use the current reading displayed. It would also be really nice if the csv file was saved in Evoscan format so it could be easily opened and evoscan features could be utilized.

These are all suggestions. I have no idea of the scope of complexity nor am i trying to come off as complaining of the current version. I would/will continue to use this version if it was never changed. I just need to make the harness or wait for the button that allows me to switch maps

 

leecavturbo, this is the source, but you can run the exe from the debug folder. The exe and xmls are bundled with each ROM.

MR Turco, yes the logs could be written in Evoscan format if we sorted out the time columns.

Also we should make a smaller MUT table with all the stuff to log in one block.

 

had a little while to test it yesterday. tested the basics and it seems to be working fine using the release from the other thread. i tried using the source code i noticed that the knock trace is not working properly on the source code. i will try again later in debug mode to see what is going on.

 

xmls are different for each ROM, the one in this thread is 88570008, so the logging address on the front page is different. The source is the same.

 

Ok. thanks. ill get the xml from the other thread and do some testings later. simple read & write on the alt maps work fine. are u planning on just using the alt maps or will u include the base maps as well?

 

Thanks for the testing.

So far it has been only the alt maps. When the ECU is powered up for the first time or after reflashing, it copies all the alt maps in a block from ROM to RAM. Tephra had (by convenient accident I think) put all the alt maps in a block except for the injector size which he moved on request.

We could move pointers and headers/maps from all over the place into RAM, not just the alt maps, but I didn't want to confuse at this stage.

 

Will look into it once I get a chance to look at the code. But it shouldn't be too bad, just a matter of seeing where/how you've hardcoded it and figuring out how to make that code more generic.

Work + new house has me busy so if there any CS/SE/SD college kids with nothing to do in their dorms and want to use those courses they have been taking <hint><hint> .

 

John, would it be beneficial or possible to have a button that resets LTFTs?

 

You IX guys can easily reset fuel trims just by reflashing; us VIII guys have to pull power from the ECU to do it.

I wonder how difficult it would be to reset the fuel trims on a map switch? It would seem like a good time to do it, given that you're indicating that you're making a major fuel change.

 

One worry I have about the VIII with it not resetting fuel trims is that a reflash leaves junk in the RAM. Tephra's code checks for 0xDEAD and if not found he resets his variables, I'm piggybacking onto this as my signal to copy ROM to RAM. I just hope that this method is reliable, otherwise 0xDEAD might still be there in one RAM area but the maps have been trashed, this would need a cold reset after flashing or another method. We'll find out when we test - I've done 8 MR JDM and will test tomorrow hopefully.

 

Yeah but does it reset the trims when you flash live? If i make a change to injector size i would want to get the trims back to 0 instead of waiting for them to cycle

 

noticed its the blockaddress.xml that contains the addresses and is the difference between ecu ids. btw i noticed that your baud rate on the vid is 38400 and the default 15625. i tried changing the baud rate to the same value as yours but i had an error. i'll debug later and see where it was breaking.

 

I use 38400 on my personal car as this is faster and also is a nice rate for my Pocket PC to log at on its native serial port (I change the ECU's baud rate to match, but it means a dealer MUT would not connect to my ECU). Apart from the source, all releases should have 15625.

 

I've started a new thread about the Evo 8 RAM clear problem since it is related more to ECU code rather than the PC application.