RomRaider

(Updated 7/12/2006)

For anyone interested in helping out, I've put together a list of things that can be done somewhat independently of other modules of the code. They're in a hierarchy, because some tasks are dependent on others. If you're interested, start a thread on the task you'd like to work on and we can coordinate on the details.

Convert current Tables to JTables
Assigned to: Unassigned
Priority: Moderate
Projected Release: 0.4.x
Description:

Dumping/Flashing
Assigned to: Unassigned
Priority: High
Projected Release: 0.5.0
Description:

ECU XML Editor
Assigned to: qoncept
Priority: Moderate
Projected Release: 0.3.x
Description:

Hex Viewer/Analyzer
Assigned to: Unassigned
Priority: Low
Projected Release: 0.4.0
Description:

Data Logger
Assigned to: kascade
Priority: High
Projected Release: 0.4.0
Description:

3D Graphing
Assigned to: Tgui
Priority: Low
Projected Release: 0.3.4
Description:

In addition, I hope someone is working on disassembling/extending the ECU code. This'll give us the ability to write our own code for things like flat foot shifting, water injection, external sensor logging via SSM (ie, wideband o2 wired directly to unused pins on the ECU) and other goodies.

Also, all of the manufacturer-specific functions (flashing, logging) would be great to use on non-Subarus. Someone with another type of car step up!

okey dokey

Bump for updates

I just realized that you can Paste to EXCEL but you can't copy from EXCEL to RomRaider Any way we can get it to read clipboard data and allow placement into maps?

See http://www.romraider.com/forum/viewtopic.php?p=3914#3914 for instructions on how to copy from EXCEL to RomRaider.

Any updates on this? I thought you guys had flashing working, but maybe not? I can do this for you. I also personally asked Colby for the ECUflash code and offered to port it to linux for him.

We've got his code, the issue is doing the flashing portion within Java natively. Since not many of us here have experience writing code to reflash ecus, its been a bit slow.

Ahh I see. Why don't you just make a callable exe and use gcc to make the executable so it is still cross platform. That would mean more platform specific builds (for the flashing exe), but you could prolly call the build for each exe or library within the IZpack installer I would think (using autoconfig, etc). Otherwise I could write a perl install script to build and run the installer for the java stuff. If his code is written in C, that seems the easiest method. Unless you are trying to improve upon it. Java cannot do everything.

Also, it was mentioned to me colby used alot of MS stuff in ecuflash. I am an expert at porting over MFC crap to linux, so... I could do this pretty quick (get you guys a cross platform C library or exe to call for flashing). Let me know.

If you could get the flashing portion done in C++ that compiles under gcc for linux/mac/windows, that would be beyond awesome. I am not a MFC guy at all (ick)

We of course would like native support in Java, but your work to build a command line exe would allow us to learn the code well enough to eventually port.

Seriously, if you can convert his s*** to not use MFC and support gcc, that would be awesome.

Wait, let me post this I have something for you.

I have a unfinished mac os x port done by Donour. I'll post it when I get home as work seems to be blocking my upload.

I had a quick look at the EcuFlash code a while back and it made my head hurt and I haven't had time since...

Ideally we would port it to Java and that's definitely possible to do.

But as a stop-gap if you could build a library that we could then plug into using JNI (Java Native Interface) that would also work. The first step would be to define an interface into the native library that we can tie into.

-Dave

Edit: As tgui mentions a command line app that builds using open source tools would also be ok, but I think that using JNI would be better as it should give us more control and then be a simple drop-in when Java flashing code is done.

+1. If you're interested, just let us know what you need.

I can do this no problem. The MFC stuff under the hood is easy to replace with standard ANSI C++ code.

I can write the class and a command line interface to the class. I don't know how to write a dll that is callable by java (sorry). But I can get rid of the MFC code fer ya. Just send me the code that writes to the virtual comm port, or send me all of it, I can find what I need.

surely a JNI solution is the best solution? i don't think anyone here has the sort of experience or knowledge that colby has built up to maintain a java port, let alone add support for new ecus to it. and i don't believe anyone wants to be porting every new release that he puts out. surely a jni wrapper around his dll would be easier to maintain, and give us (almost) free support for the latest ecu versions each time he upgrades.

porting to java will be a world of pain for little gain. my 2cents anyway..