GMECM Digest V2 #589

[Dig]

>>>>>>>>>>>>>>>
Date: Wed, 01 Nov 2000 12:59:39 -0800
From: Ludis Langens <ludis at cruzers.com>
Subject: Re: Call for standards: EPROM/cal editing
software

I've contemplated this subject in the past.  The only
solution that
doesn't have built in limits is to make the definition
file an actual
program.  What we need is the "Postscript" of chip
editors.
I envision the editor providing lots of standard
handlers for tables and
constants.  The definition file simply creates data
structures that
invoke these standard handlers.  If the chip has
nonstandard contents
(like a custom MAF table), the definition file itself
provides functions
to handle these.
To avoid reinventing the wheel, an existing
programming language should
be used.

>>>>>>>>>>>>>>>>

I agree with you here, except I don't really want
to involve any programming languages here- That's
best left to the person writing the editor.

I'm looking at the more generic set of table 
definitions, their formulas, and a group or category
that the table would fit into (eg, timing, fuel, ESC).
These categories in and of themselves would be extens-
ible, as would the number and dimensions of the
tables.

I had been thinking of this in terms of GM ECMs only
up until tonight, but I can't think of any good reason
why it wouldn't work with other manus, since they 
use tables and constants to define their data as well.

The solution is to be very generic, and very
extensible
. I think we're fairly close to that with some of the 
existing formats (.ECU, etc.), and with some of the
new format offerings that have come to light recently.


An example, to show you where I'm coming from...
This is an .ini format that's similar to other formats
already out there.

Comments preceded by a ;

[ClassCount]
NumClasses=3   ;Number of table classes, or Categories


;Names of the Categories, the Editor will parse these
;and create menu options based on them. You can have
;as many class names as you want.
[ClassNames]
Class1=Fuel
Class2=Timing
Class3=Other

;Number of Tables, a table can be a single value
;(ie, a 1x1 table)
[TableCount]
NumTables=70

; These are the actual names of the table, that would
;appear in the Category menus. You can define as many
;or as few of these as you like... if you only know
; one table in a particular cal, you can set that one
; up, and the editor will only show one table. In this
;way, the editor "grows" with the TDF author's knowl-
;edge of the tables and constants in the cal.
;These are all single lines, my mailer might be 
;cutting them off.
 
[TableNames]
Table1=F69_TYPE;Offset Terms To Get MAP Default Value
(KKB) As F(RPM);B;1;


Table2=F78_TYPE;NTPSLD Terms To Get TPS Default Value
As F(RPM);B;1;

Table3=F42_TYPE;(3rd Gear, Upper) Load Limit vs
MPH;B;1;

;This defines the actual offset of the table into
;the EPROM, as well as the size of the X and Y axis
;and the conversion formulas for the raw hex data.
;we may need to support 3-axis tables, although I'm
;not aware of any apps that use them currently.
[TableLocs]
Table1=0x0080;5;1;None;None;
Table2=0x0085;6;1;None;None;
Table3=0x00DC;11;1;None;None;
Table13=0x0192;17;14;((x * 90) / 256);((x * 256) /
90);

;The graduations on the X table axis
[XAxis]
Table1=0;1600;3200;4800;6400;
Table2=1000;1800;2600;3400;4200;5000;
Table3=20;25;30;35;40;45;50;55;60;65;70;
Table4=20;25;30;35;40;45;50;55;60;65;70;

;The graduations/labels on the Y table axis
[YAxis]
Table1=Counts;
Table2=%;
Table3=%;
Table4=%;
Table5=Deg.;
Table6=1200;2400;3600;4800;

This is only a sample, but it shows kind of the
concept
that's needed- a way to define what the tables and 
labels look like, a way to categorize them, and the 
ability to add additional tables (and point them to 
any location) and add additional categories.

If an editor is set up to parse this file and only 
display what it reads in from this file, you'll be
able to set up anybody's editor (anybody that supports
the standard, that is :) to include only the tables
you commonly need, and leave out the ones you don't.
You'll also be able to add the custom tables that 
folks are adding that aren't in the factory cals.

I don't want to tie this to any particular editor,
programming language, OS platform, etc... it should
be able to work everywhere. However, I'm not entirely
against using parts of existing formats (or even 
formats in their entirety) if they can meet the 
requirements above. No sense re-inventing the wheel.

I've gotten quite a bit of interest in this, so it
looks like it's something many others have thought
about as well. That's encouraging to see; maybe it 
means that this is an idea thats time has some.

Thanks for the comments, Ludis.

Later,

Dig
turbodig at yahoo.com 


__________________________________________________
Do You Yahoo!?
>From homework help to love advice, Yahoo! Experts has your answer.
http://experts.yahoo.com/
----------------------------------------------------------------------------
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org