MegaTunix/Protocol (2005-03-07 14:09:33)

The purpose of this page is to document the communication protocol used by MegaTunix and GenBoard.

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:

Large config:

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):

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

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

Realtime variables:

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

rtc.sec
engine.status
engine.status_ext
engine.rpm_vhr
inj_port[x].pwcalc
engine.ignadv
engine.dwell
engine.kpa250
engine.coolant
engine.mat
engine.tps
engine.batt
corr.ego
corr.air
corr.warm
corr.baro
corr.gammae_1k5
corr.ve_hp
corr.lambda
corr.tpsaccel
corr.tpsfuelcut
corr.overrun
corr.als
iac.position
wbo2.Ip_output
knock.knock_adjust ("average" of all, or individual cylinders?)
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.


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 .

The above is almost complete ?

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