This is a developer-page about an experiment that is currently stalled
Users want to try MegaTune, that has improved the most lately.
Why start another tuningsoftware when there is OtherTuningSoftware/JTune ?
We want to use the ideas on OtherTuningSoftware/CommonInfrastructure.
Useability features
- The ability to handle 2 configurations at the same time makes life easier. Most of the time a tuner takes with configuration is manually comparing other's config and remembering what is set already and what needs to be reviewed. A norton commander -like facility for synchronizing subtrees of firmware variables (or just navigating among them, and make some displayed) would help a lot.
architecture
We want to make maintenance simple, mostly automatic when new variables are added.
- We want a heavy reuse of classes for similar engine variables. * This means we don't write a class that has variables and arrays of the same primitive types as the ECU. We plan to manufacture (with builder pattern) these from simple Variable class using global.h. Matching GUI elements (widgets) will be used to display these (also heavy reuse).
Libraries
I found that what we started to code is very similar to
- http://www.cosylab.com/abeans/cosybeans/apidocs/index.html
- [Java3D at sun] and [Java3D learning material links]
We need to decide (ASAP) if it worths to use com.cosy or not.
TODO:
draw what we had in paper (it's possible from looking at the code and checking how classes refer to each other)
- class diagram drawings
- collaboration diagrams
- usecases
what next
note that it is in the architecture stage, far from useful.
- we expect others to join in the development. eclipse.org is fun to work with, even if you have never programmed in Java before, it's time to start. Code is in JTune CVS: org.vemsgroup.gentune package.
- The software will be easy to port to C if it's justified. It worths to make it work in JAVA first, since that has far the best development models and tools that work for everyone (C has solvable but ugly porting issues with GUI, TCPIP and serial handling)
- One open question if we should use classes instead of interfaces (since C++ has no notation of interface) even in the JAVA code. Not much difference, an empty (absolutely abstract) class is effectively an interface.
Here's a relevant quote from _Programming Embedded Systems in C and C++ by Michael Barr_:
"The features of C++ that are too expensive for my taste are templates, exceptions, and runtime type identification. All three of these negatively impact code size, and exceptions and runtime type identification also increase execution time"
I agree 100%. The rest was (in his opinion) pretty much OK.
For the code to be easily portable to C
- we must use static methods or objects with known class that equals a leaf class (so dynamic dispatch can be optimized away). This trades execution speed for project overhead.
Gentune CVS difficulties, questions
- I can not see through the CVS repository. There are the following directories:
- JTune/org/vemgroup, JTune/org/vemsgroup (don't understand why wasn't enough only one of these folders)
- JTune/src/org/vemsgroup (I think this is the gentune's directory but I don't understand why we didn't put it to JTune/org/vemgroup, so why was "src" needed)
this is an accident, we'll clean up sometime.
- My next problem that I can't run Treedemo in Eclipse 3.0. I get the following message: Error occurred during initialization of VM; java/lang/NoClassDefFoundError: java/lang/Object I installed a j2sdk1.4.2_05. I experimented with Environmental Variables (ie. CLASSPATH=%CLASSPATH%), but it did not succeed.
The problem is probably that eclipse does not consider the source folder as a java source folder. (is the project a "java project"?)
Delete the project, make a new java project
- either make the new project (by naming it right) over the existing working directory (eclipse will find the "src" as source folder: actually this was the problem with having org dir directly in JTune root folder, but there are other cure:)
- or import the cvs checkout directory
Now succeed to run Treedemo. I checked out last JTune. I moved JTune/src/org folder to JTune/org folder and now eclipse finds that the JTune folder is the source folder. Elseways I couldn't get eclipse to consider src folder as source folder, no matter I set it in Project properties -> Java build path -> Source -> JTune -> included -> src/. Moving folders from a cvs checkout is not too elegant. Any better solution to force eclipse that src directory is the source directory?
You can import just the directories you need. Also, add libraries to the build path (external library means it is not located under the given project, I keep those under /eclipse/lib/ Eg. I added all downloaded abeans jars so I could start to run them before all compiled well. recently I added the comm.jar from [javax.comm.zip]
use jar tvf command (possibly from script) and google extensively to find classes.
Not that the tab does not point to source here (but build classpath settings).
If you have the CVS plugin for eclipse.org ... that's nice, very good diff-ing (synchronization).
If I modify a file i.e.: Simplewrite.java and I would like to get back to the original CVS version, I do right-click -> Team -> Update... with no effect. So how to update a modified file from cvs repository?
From eclipse (if CVS plugin is there): Team=>Override-update.
From command line delete the file, and run "cvs update -d", it will bring any missing files and directories. Don't forget to say "refresh" in eclipse if you do that (or modify anything under eclipse), otherwise you'll get all kinds of suprising behavior (eg. error when running cvs update).
We expect to merge with OtherTuningSoftware/JTune some time in the future.