There are much freedom at this stage, both megatunix and the firmware can be modified.

First we get mtx and firmware talk the easy way, before we go fancy (with checksum).

Important topics to decide:

* Complex protocol as used in the menu OnlineCourse/TextualCommands? - no, only ideal for keyboard and human issued commands.

* for runtime logging the way to go is GenBoard/BinaryProtocol The checksum and packet-handling implementation must be clean, and MegaTunix must remain compatible with the other ECMs of course.

* Simple binary protocol as used by megasquirt is good for configuration

** Error detection? YES. Finally for everything.

** Use paging to keep the number of commands down? Yes. It does not lower the addressable area, just splitting the address to lower and higher part. Let me note that our tables ('j', 'n', ... are already pages, these must not be reused)

** What do we do about the large config? See below.

Large config:

* paging is the trivial way to solve this

* DROPPED: Moving parts out to table would work (flash-saving but ugly except maybe for CLT-thingy)

With 256 pages, this scheme can be extended even more: The current config (with names) can be splitted into several smaller pages grouped by function, ex. a page for iac related variables etc. But why? Isn't it better to group variables in a way the firmware does not know about (besides the variable name, eg. "iac_..." ?

Page invariant commands

There must be some commands that work the same way no matter which page the ECU is at (so when mtx gets disconnected, than another mtx started and connected, it should work):

* Identification (see below)

* page-selection command (obviously)

Note that there is no requirement such as "all pages must be the same length" (eg. padded with FF).

Identification of the comm protocol

We have a command that enables identification of the firmware's communication protocol. This is quite different from

* mdV (firmware version)

* or mci (hardware serial number, that has HW version),

because the firmware can change even if the protocol is not changed (config unchanged), and a given board can host totally different firmwares.

Also, the "identify yourself" command should be 1-char for compatibility.

Suggestion:

:command: S (textual Signature)

:answer: VEMS Genboard v3, x.y.z where x.y.z comes from f_version[].

This identification should be enough to identify the firmware protocol version. Unfortunately because of some historical broken megasquirt firmwares, Dave had to develop a complex interrogation scheme, which is still needed for some outputs of the "S" command. But it should not be needed if

* "S" confirms the comm protocol version (firmare is not broken)

* or user specifies "forced firmware version" (in command line option or config file). This must not be default, of course, only if user explicitely and actively acts so (and that way takes responsibility for any resulting incompatibility).

Realtime variables:

* No need for raw sensor values, let the ecu take care of conversions with lookup tables etc. Then we don't need the strange scheme with ex. thermistor translation tables in both ecu and tuning software.

* The number of variables are not limited to 22 bytes, but maybe it would be nice to have several smaller realtime streams (instead of a 200 byte stream) depending on what you want to log? Is this possible?

* The paging method could be used for realtime variables too, eg. having upto 256 predefined streams of variables. A stream could be the one listed below, or for instance the benchstats variables.

* Command used for receiving realtime variables =?

Variables part of the realtime stream, please brainstorm (order not determined yet):

rtc.sec$FlgChr1$FlgChr> engine.status$FlgChr2$FlgChr> engine.status_ext$FlgChr3$FlgChr> engine.rpm_vhr$FlgChr4$FlgChr> inj_port[x].pwcalc$FlgChr5$FlgChr> engine.ignadv$FlgChr6$FlgChr> engine.dwell$FlgChr7$FlgChr> engine.kpa250$FlgChr8$FlgChr> engine.coolant$FlgChr9$FlgChr> engine.mat$FlgChr10$FlgChr> engine.tps$FlgChr11$FlgChr> engine.batt$FlgChr12$FlgChr> corr.ego$FlgChr13$FlgChr> corr.air$FlgChr14$FlgChr> corr.warm$FlgChr15$FlgChr> corr.baro$FlgChr16$FlgChr> corr.gammae_1k5$FlgChr17$FlgChr> corr.ve_hp$FlgChr18$FlgChr> corr.lambda$FlgChr19$FlgChr> corr.tpsaccel$FlgChr20$FlgChr> corr.tpsfuelcut$FlgChr21$FlgChr> corr.overrun$FlgChr22$FlgChr> corr.als$FlgChr23$FlgChr> iac.position$FlgChr24$FlgChr> wbo2.Ip_output$FlgChr25$FlgChr> knock.knock_adjust ("average" of all, or individual cylinders?)$FlgChr26$FlgChr> egt1, egt2, exhaust backpressure and fuelpressure(We have inputs for those..)

Note that we do not want to etch the set of runtime variables in stone. We must have a (frame_descriptor) structure that allows defining frames with arbitrary content. This is not as hard as it sounds, and provides flexibility to avoid the need for a future redesign. Of course a default frame_descriptor can be stored in flash to save SRAM for the common case. Look at GenBoard/BinaryProtocol.

Page selection command

The paging is achieved with the p<pagenum> command. Pagenum can be 0..255, in practice 0..7. Note that binary 0 is used, not '0' !!!

No support in MegaTunix for page name like 'l' (table name), so the firmware is made cleverer to map these.

* Page size was limited to 256 bytes, but

* since v0.6.3 the page size limit is 4096 bytes

* an exception to the new 4096 byte limit is a raw memory read (command 'F') which is still in 256 byte pages.

----

A perl model of the protocol, which allows the tuning software to communicate with a virtual GenBoard, is described in OnlineCourse/UartComm

I want to put this in use against MegaTunix, but I'm stuck: which commands are used nowadays besides the 'p' ?

(VE/constants) , (Rawmemory readback), and .

* Page_Cmd p mtx => ECM select page number - effects most commands below

* VE_Cmd w mtx => ECM store variable to address (page specific)

* v ECM => mtx : read data from page

* Rt_Cmd A ECM => mtx realtime variables

* Raw_Meme_Cmd ???? ECM => mtx read RAW memory (takes an argument of an integer which is like a page, the number determins what part of memory you're reading (F should return 256 bytes of data)

* Burn_Cmd

* Write_Cmd W currently hardcoded to W, while all others are configurable

The above is almost complete ?

What about the ones below ? Those shouldn't be needed, right ?

* L ECM => mtx VE/constants (goes hand in hand with page changing command to switch pages to read or write different data)

* V mtx => ECM : write table-data ?

* n mtx => ECM : write table-data ?

* T ECM => mtx : read config data

* W store all config from ECM RAM to ECM non-volatile memory (EEPROM)