RomRaider

I think Freon is doing this separately from RomRaider development with the idea of posting up patched roms and the necessary ecu defs for RomRaider, Ecuflash and Ecuedit. Once it is fully developed and with Freon's permission, we could integrate his code into RamTune to avoid any kind of conflict. Plus you would likely want the VE map to be real-time tunable so it would have to modified for that.

On another note, what are your impressions about the stock MAP sensor? I know that F-CON V Pro asks that users purchase their MAP sensor (~$800!!!!) to use in conjunction with the unit. Are there any strange fluctuations or any problems with accuracy thus far?

I can't imagine that the stock unit would have any problems because the ECU already relies on it for so much. Why does HKS think they can sell an $800 sensor when ours works adequately? Why doesn't TurboXS's Utec need an aftermarket sensor?

Can't figure this out. Any clues would be nice.

J

Based on what Bill has said, doing that on 32-bit ECUs would probably be fine but there is already next to no unused space in the 16-bit ECUs.

Once i re-code for the new simplified RamTune plan, I should be able to net about 150 bytes which will probably be enough. Worst case scenario, on-the-fly map switching could be removed for an SD RamTune version.

Being able to accurately measure boost beyond the dinky limitations of the oem MAP sensor is probably a big part of it. The cars that stay within OEM sensor's range are probably the least likely to need SD or a piggyback/standalone.

The UTEC doesn't *need* one, but it sure has the provisions to allow using one, and TurboXS sells one too

I don't see anything wrong with the stock MAP sensor so far. It works fine.

So now what??

If the OEM sensor is adequate, you aren't making enough boost

I'll be working on it for a while to make sure it really does work right. I am making tweaks here and there to the code. This is NOT easy work and it is very time consuming. It takes a great deal of care.

I think the factory sensor is plenty for pump gas. Either way, if you put a new one on you still just change the scalings and go from there. Obviously getting the scaling just right is going to be that much more important.

how's your project coming along, freon?

Until I have a way to recover bricked ECUs with shbootmode I'm effectively at a standstill. I've contacted Colby about it. I've got my custom made bootmode FTDI cable made and everything, but shbootmode doesn't work right now. Unfortunately the patch process is largely manual and can be screwed up pretty easily, bricking the ECU. I did in fact brick an ECU due to a small mistake and I won't be buying a $550 ECU every week to get this thing running. It's just too easy to misplace one character in the code. I successfully patched new code in about a dozen times before I fudged a paste by a dword offset and that was that. It corrupted the stack and the ECU won't boot.

I've got my car pretty well tuned as is, it runs great, I've done an autocross with it (SIA event) and will try drag racing tomorrow. It's probably good enough as is, but I'd rather it be perfect. I'm still tuning it, just not attempting any new code changes. I'm really in no rush. It may be months before I decide to release anything.

I did not intend for this to be an open source project or to be integrated directly with Enguinity only. I will most likely supply just a base patched binary and updated XML for users. If Enguinity releases an interface spec I can write my own realtime code in the ECU to work with the editor. I want it to work with any possible editor, not just Enguinity.

That's strange as I've made some mistakes and never had a problem with reflashing (both 16bit and 32bit ecus). The only time I've seen someone brick their ecu was when a tester of mine decided to modify the patched rom I gave him to test by modifying my custom code and he ended up inserting his changes rather than overwritting thereby shifting all code and data after that point. Apparently, the code/data related to flashing is at the end of the rom so he ended up bricking the ecu. As far as what I've seen, as long as you don't overwrite/move that portion, you can make as many mistakes as you want. In some of my early code, I had set up an infinite loop and was still able to flash (02 wrx). I thought I was screwed (no cranking/no fuel pump), but I was still able to flash which didn't seem to make sense but I don't know the details about how flashing is accomplished.

Can you elaborate a little on what kind of interface you're looking for?

J

Oh, as long as I know what/if you are sending special packets.

I dunno, I guess you're just going to write tables to memory based on XML? I guess if that's all you did then there really wouldn't be any "interface." There are sometimes constraints on what memory addresses you can write to with the SSM memory write commands. I really haven't looked into it much and have only glanced over some of your threads.

If nothing else, to start up realtime tuning after an ECU reset you have to write all the tables, perform a checksum, then pop a bit on so the embedded code knows to swap maps. If you were going to use and special commands or techniques sent from the PC side of the interface it would be nice to know what you're doing. I'm not that concerned with it, don't worry about it. Cross that bridge when I get there.

Defining new packet command bytes will probably become useful as time goes on. I.e. for baud rate changes, or possibly just telling the ECU to run code to copy the base map to RAM, map switching, etc. I guess the existing memory writes could handle some of this. Anyway, I'm digressing and this stuff is a while off.

merch: I literally pasted code 4 bytes too early, so the push to stack didn't make it, but the pop at the end was still there. FYI, if you do that to the MAF subroutine, the car won't start. My fuel pump came on and stayed on as long as the key was in the "on" position. Would not boot with ECUflash, tried dozens of times. I guess the ECU drops down these subroutines before it initializes SSM. It probably ended up causing a CPU fault, but I don't have a debugger interface to check for sure.

Interesting. I luckily haven't yet made a mistake that would impact the stack. Luckily my ecu is only $150 used, so in the remote chance something goes wrong I'm not too screwed. I've learned to triple check my custom patches in IDA before flashing but it is very easy to make a small mistake that could be missed so I hear where you are coming from.