I've taken the sample code posted here and re-written it as a platform independent Java application (although this has yet to be entirely tested).
So far this is complete:
- Communication with the ECU using SSP with dynamic queries. (the byte addresses for parameters are not hard-coded into the code).
- ECU Parameters are completely declarative. You give them a name, declare a class for handling the conversion, and specifiy a byte address. This will allow anyone to re-configure the application for any ECU which understands SSP or add parameters I have left out.
I plan to have a simple console and log renderer done by this weekend. At that point I'll probably post my source here and offer some rudamentary installation/usage instructions.
Here's my short-term To-Do list. If you want to tackle any of this send me a PM. I'd be willing to send you my current code if you're itching to get started, but we'd probably have some merge issues as we don't have any kind of source control.
-Build a generic, declarative interface for "renderers" (console, dashbord, log, graphical charting, ect). I will have this done for the first "release".
-Come up with some simple command line arguments for run time configuration. Might look something like this for linux:
- Code: Select all
./openECU.sh -render console, csvlog -param RPM MAP EGT KNK -file ~/logs/myLog.csv
-Build a configurable "dashboard" UI in swing. This will probably be digital at first but I plan to make it all pretty with analogue gauges and skins eventually.
I'm more of an enthusiast than a turner so my need is to verify my car is operating within reasonable parameters while I'm driving it. That's where my work will take me initially. I'm not very interested in logging tons of data and pouring over it for hours.
As a group we need to do a few things in order to make this a successful collaborative effort. Generally in this order:
1. Decide on a platform (I'm Java biased, of course, but I think QT/C++ would be a viable alternative). We need platform independence for sure.
2. Set up the underpinnings of a successful open source project.
A. Make somebody the "leader" and come up with a process.
B. Assign roles and build a development roadmap.
C. Set up a website for hosting releases and bug-tracking, cvs/svn ect. Sourceforge would be an excellent solution for this at least initially.
I don't have time to be this "leader" guy right now. I'm involved in another project and I'm getting married in two weeks, but I'm sure there's somebody smart here who'd love to step up to the plate. You'll get to put "Organized an open source development project" on your resume at the very least.
cheers, ll