RomRaider

Thats my goal. I need about 40-80 hours just coding, then some testing to do it. I just don't have the time right now to devote to it. I will in ~4 weeks. So for right now, I'm just merchgod's test monkey.

I would be interested in doing that (making a portable standalone CLI version that is free of QT). I usually code in C/C++ at work so that wouldn't be new stuff for me but ecu flashing sotware would be new. I've also worked on a java project that used JNI 2 years ago. You mentioned that Qt was used for xml parsing and other non-gui puposes. What are the license restrictions for a replacement xml library (BSD, LGPL, GPL) ? I am shure that maximum portability is required. I could probably put 4-6 hours a week on this.

I know the priority on this is low, but this might be something I could try to do. I haven't written any java code in a while but I am familiar with SWT, Eclipse, GUI design, etc.

Can we get into more specifics with this peice? What do you want to give it and what do you expect to see? PS I don't have a tactrix cable. Would love to find out more about what you all are looking for before I commit to such a job.

BTW this overhaul that is mentioned in the RamTune thread - is that talking about the flashing code that Gabedude is working out? If so that's pretty sweet.

Along with the actual HC16 assembly and what I've been calling other data-layer code, the Java side of things needs to expose this functionality.

We need a few things that, when time presents itself, I'll try to help gather:
Augment the definition ("ecu_defs.xml") to describe where on the ECU we can create the LUT (Look-Up Table) and free space or whatever
Create some new UI around enabling RamTune, toggling RamTune on map collections
Mediate the communication of this UI with the "IO" package using the definition

Someone correct me if I'm missing anything.

There are a few things that make this task a little less straightforward. Some of the developers are in the middle of a UI overhaul which defines a new UI from a programming perspective. The ECU definition stuff should be approved by the guy that provides the definitions.

If it weren't for the day-job, this stuff would be done by now

J

I've updated the RamTune development outline here to include the more simplified version that has been discussed:
http://www.romraider.com/forum/viewtopic.php?t=1136 - I'm not a software developer, so I don't know what kind of format an outline like this should take, but that is basically how I would envision RamTune being developed.

While giving the user the ability to dynamically choose their RT map assortment from a collection of 20 maps is possible with the rom code that I've developed and have tested on my car, it would be very difficult to integrate into RomRaider and might be confusing to users. I recently suggested that we stick with a static set of pre-defined map assortments (as described in the updated link above). This takes a lot of the complexity out of it, but you don't lose too much functionality. On-the-fly map switching would still work. And we could offer more than one RT map assortment (only 1 initially though for simplicity) - the user would simply have to update their rom and flash it in order to switch between map assortments. Other advantages are that I can recode for this new version and save some rom space since we will only have to setup the rom for the RT tables each version supports and not all 20.

I also can remove the simple error checking which checked for valid ram offsets. Since this lut will be stored in the flash area and would be static, that error checking is unnecessary. However, I don't know if it would be a good idea or not to have a checksum for each table. I guess it would depend on how reliable RomRaider's writes to ram are.

Update on flashing support:

I have had communication with Colby about integration of ECUFlash into RomRaider. Currently, Colby is working on getting CAN Bus working with the tactrix and ECUFlash. ECUFlash currently supports one command line argument which loads the ROM into ECUFlash. I want to add more, so Colby has just offered to do them for us. Here is an excerpt form the email:



So what do we want to be able to do from the command line? Right now we could launch ECUFlash and have it load the current ROM. That is it. What else do we want to add? I see the following as usefull:

Read
Write
Compare
Passing in flashmethod
Output flashing status (need ideas here from the Java guys on how you would want to capture the messages that ECUFlash currently displays).
Return values.
Hide the ECUFlash Dialog (unless an error is encountered).

I think this is the best way to go and integrates the two projects instead of diverging. I will write a wishlist spec with ranking for Colby.

After this, I can start doing some dissasembly with IDAPro as we need help there.

Gabe

Sounds good.


Actually, what we need help with is java development.

I'll learn Java then.

It is the only language I have refused to learn, but I have 2 books on it. Seems easy enough. I know C# and I have heard it is similar. I can read and understand Java code, so... I may not be the best, but I can help. I will learn java and integrate launching ECUFlash with the current ROM first. Time for me to go get the SDK.

Gabe

How close is Colby to adding support for can bus?

I did not ask. I know he is working on it though. I'll ping him and see if I can't help him out there.

Gabe

If you'd like to examine a Windows program which can reflash CAN Subarus, go here.

Thanks John. I will look at it. It looks like Colby just needs access to a car that the Subaru J2534 CD supports so he can get a snapshot of the flash process. I can probably find a volunteer in Austin and get the data he needs to complete the support for the cable.

Gabe

There is only one SOA reflash, so far, for a Subaru with CAN. The cars involved have automatic transmission and are the 2007 Legacy GT Ltd with Navi and the 2007 Outback 2.5 XT LTD (Navi doesn't matter). In other words Legacy/Outback with 2.5L turbo, automatic transmission, and VDC. Their Calibration ID (CID) should be A2UG000C, which can be checked beforehand with any scan tool that supports CAN. The CID after the reflash will be A2UI001C. The fix is for the VDC light being illuminated erroneously.

The Seattle area is thick with Subarus while they're relatively rare in Austin, TX. Maybe you can persuade a dealer to let you and your wife take one for a 1 hour test drive without the salesman on board.

I may be able to get my hands on Subaru PAK files as well. The 07 Forrester XT is CAN and I have a guy wanting to use RomRaider / openecu. He currently is running a UTEC. Failing that, I can probably get my hands on an auto Legacy or Outback Turbo run the test on.

Colby has offered to add more command line arguments to enable flashing with ECUFlash integrated with RomRaider. I need a wishlist.

So far I am going to request this:

Switch to load a particular file (This is already present)
Write
Read
Compare
Flashing status return codes
Hide ECUFlash GUI
Some kind of flashing output to a file or a memory mapped file that we can render in our own window.

This keeps the openecu projects combined and development effort to a minimum. Another reason I wanted to go this way was because ECUFlash can run as a seperate process and I would like to keep it that way. Also, this enables both Colby and I to work on the CAN Bus flashing in ECUFlash.

I will do the integration in Java (I have been forced to learn Java at my job).

Any additional features you guys can think of?

Gabe