JTune is a Java application (under development) wrapped around a serial IO framework, and targeted towards ECU tuning.
The main target is the PDA and cellphone devices. This is from the old PalmOS devices up to the newest PocketPCs. See OtherTuningSoftware/JTune/HardWare
Design must be solid
Even though we finally need a C based software to support OtherTuningSoftware/NintendoGameBoy, it seems that writing a well-designed tuningsoftware is the best way to go. The design is easiest to get right in Java, and porting to C shouldn't be particularly hard (maybe laborsome - but much less than getting it right in C first).
I think it's time for some design before processing with tuningsoftware coding.
Code is on SourceForge megasquirtavr in CVS module JTune. It's easiest to work with in Eclipse, but if you want to go old school, you can download it and build manually with Ant: ant -buildfile build_superwaba.xml all-exegen You'll need to check and modify the a couple of the build paths first.
I hunted the libraries together, it even compiled, but:..........\nÿ1ÿ
That'll be the RXTX libraries, I think. Make sure that the native libraries are installed in the JRE's lib/i386 directory. I think messed up rxtx versions caused this problem.
Here's what's used:
- [SuperWaba 4.21b] VM and SDK for Palm, PocketPC, and probably other mobile devices. We need to use the serial hardware, and this is the most portable way to do it on older devices. It's also LGPL which is nice. Sun's MIDP 2.0 offers serial support on a range of devices, but only the latest ones unfortunately. This is a subset of Sun Java, but shouldn't be too hard to work with. most of the non-GUI functionality is there, so if you know how to hack Java you'll be OK hacking this. See OtherTuningSoftware/JTune/Hardware
- The [PalmOS Emulator] (POSE) and ROMs for testing PDA usage on the desktop. SuperWaba is supposed to work as far down to PalmOS 2, so this application should too. I couldn't get SuperWaba VM working with POSE with v2 ROMs... not sure where the bug is, but let's say v3 is the minimum for now.
- [J2SE V1.2.2] for PDA target compilation. This produces usefully faster code than the newer compilers on mobile devices. The desktops can use Sun's current SDK release if they want. As it turns out, the SuperWaba PDA apps can run as an Applet on a desktop too. Aside from usability issues, it means we can run one application for a while... then develop a prettier desktop interface once we've got something useful working.
- [Eclipse 2.1.3] as the development environment.
- [SuperWaba-IDE 0.3.0] to assist Eclipse with SuperWaba specific features. Don't use it to actually build the app though. Just cd into the JTune project directory and run ant -f build_superwaba exegen instead.
- [Apache Ant 1.6.1] for building the applications.
- [RXTX 2.0-pre7] for communication port handling. Requires the use of Sun's CommAPI. This is currently used for testing on the desktop with JUnit. You might need to recompile it from sources if it barfs.
- junit - pretty standard framework for testing, but my eclipse showed it's missing (should it be in 1.4.2_04 j2sdk?)
These bits are on hold at the moment...
- [Thinlets 2004-03-07] for non-Swing GUI components and layout. Swing is much nicer to use, but it is heavier and some platforms don't have it.
- Sun Java [Web Start] for mainstream installation and update management.
TODO
- Screen designs. You don't even need to know how to code for this part. We need some PDA usable screen layouts sketched up. It's about making things as simple as possible, but as workable as possible within the confines of the small screen. Eg, how should fuel settings be handled? What should the O2 setup look like?
- Make TCPIP comm as a replacement for RS232 wire, see GenBoard/AdvancedComm. I was a bit surprised that RXTX couldn't handle it off the shelf (it can do RS485 and parallel), but we can probably extend it - or make our wrapper.
- Put the application online (from cvs?) as an Applet interfaced to the TCPIP link - not gonna happen unless it's running on Marcell's webserver, due to Java's applet security features.
- When I tried on 1.4.02 j2sdk, I had out of memory error, probably something minor (maybe rxtx issue?) - obsolete error now
- Document the Genboard IO data model, in terms of what gets sent/received and for what function. This will be used to create the data model classes for the application. UML would be nice...
- Create file structure and ant tasks for building the apps.
- Set up automated CVS build and class testing
- Style guide for application. seems like overkill, but we probably need some rules to ensure contributions will work on PDAs
- Add more TODO-s (priorities?)
GUI Layout
MembersPage/PatrickB wrote: I'm thinking that JTune could do with a loosely coupled GUI confined to 160 x 160 pixels per page as the information would lend itself well to this type of visualisation. These same UI components could then be used as Portlets in a Web Browser/Portal type UI and against a JVM running on a PDA.
I'm not sure what that means, but as I understand it's for making independent widgets that can be pack according to configuration. (? Marcell)
160x160 is traditional Palm screen size, I think. Anything pixel based is nasty as we have to be able to scale for multiple screen sizes anyways, but it's worth considering this as a "worst case scenario" - in 1 bit colour. As appealing as the JGoodies stuff is, Thinlets offer a sane way to provide an interface on some PDA screens (WinCE / Linux devices) as well as laptops.
After some sleep and thinking, I propose the following:
- One source tree for both would be nice. (strongly agree)
- MVC architecture (separate data from GUI from function).
- Both Thinlets and SuperWaba supported - if you add a feature in one GUI, you are responsible for adding it to the other.
- All classes are to have a test suit. JUnit I guess...?
- Ant based build process.
- WebStart package online for desktop application
- Downloadable ZIP for desktop application.
- Downloadable PRC package for mobile application.
- Demo Applet(s) online for both interfaces.
sounds well based
Some notes by Jörgen:
I think that we need a scrolling table view.
We need a gauge section where we show a bar for TARGET AFR, Actual AFR as horizontal sliders.
Something like this? Monitoring could happen in it's own thread, so if a different screen is shown and parameter like AFR gets out of bounds, it could give an audible warning. -- Richard
More like this:
--Jörgen
Load and RPM can be shown in numbers if we have a flying dot in the table. Flying dot is very important.
We need RPM, MAP, TPS, IAT, CLT, Injector duty, Injector Pulsewidth, ignition timing, knock retard,acc enrich and a few others on the main screen.
This is emulating an older Palm, and the WinCE style GUI. It might be easier to look at, but the PalmOS style fits more on the screen... --Richard
Starts too look nice! No need to have the unit after the number though, MAP(kPa) ### is more effective and makes for a cleaner display. BTW, the LOAD and RPM parameters is the most important. Load is normally expressed in kPa (except for Alpha-N applications where it's TPS%). Ignoring the units altogheter where possible is even better. --Jörgen
One good feature is to have a dialog pop up when you start writing a number in a cell. A PDA would have two of the physical buttons assigned as up down buttons and when those are pressed a dialog for the current cell pops up.
The font size is increased on the pop up, and is adjustable from the PDA buttons. --Richard
Really nice! --Jörgen
Did you look at [ Megajolt Lite Junior] ? Webpage says Gnu General Public License, source files doesn't contain any licensing information.
I would assume it to be GPL'd unless a specific file says otherwise. I've not looked much at it to be honest, but it looks quite nice. Just appears to be in a moving in a slightly different direction to where we are heading. - Richard
Just another update:
The basic comms work ok over the net on the PDA, and over serial in the POSE emulator. I bought the cheapest new Palm to try with, a Zire 21, but it's USB only - unlike most other Palms, which have RS232 available via the feature connector. I've been unable to find a suitable adapter, so I'm not sure where to go with it now. Ideally we'd be adding a USB OTG controller to the Genboard.
I've got a Java/SuperWaba app running on PalmOS through POSE on my Linux box. It's talking to Marcell's Genboard via Telnet. Doesn't do anything useful, but if nothing else it proves the packaging and TCP/IP comms can work.
