VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
GenBoard/MenuSystem

We need to instruct GenBoard for several reasons:

Most important is altering configuration. Configuration data is saved into the EEPROM for persistency, since it must survive powerdowns (data in SRAM is lost when power goes away). Configuration settings severely affect the ECM's behaviour.

We want to do this in the car, without taking GenBoard out. Traditionally MegaTune is used for this, and it can still be used for setting config variables.

Many people have problems with

A PS2 KeyBoard together with the LCD can be very helpful.

The only remaining service that a notebook is essential for is data-logging. To set the VE-values manually (without WBO2-learning) the 3D-visualization plotting feature of MegaTune is still very useful.

For backuping the tables and config structure - see "mcd" below - is also nice, although setting them from keyboard once per assembled GenBoard is possible: just have the data (varstr.h, magicstr.h for the variable offsets and your config values) on paper and it becomes easy. You need to _understand_ and _specify_ the variables anyway ( MegaTune does the unit conversion and hexadecimal conversion so it's definitely easier ).

Erasing the chip does not clear the EEPROM contents with hfuse==c4 that is normally GenBoard factory-default (erase would clear eeprom with hfuse==cc, see DocsAndFAQ/AvrFirmwareUpload for further info).

You cannot expect to have reasonable config or table values after firmware upgrade ! Before upgrade make sure you have your config saved, and upload your config after upgrade and reboot the controller.

We define TextualCommands that are easy to remember and print on a reference-card.

This way the same commands would are usable from

- rs232 terminal

- directly attached keyboard and LCD (recommended)

- maybe FranksLcd (not implemented)

The menu structure is the same for RS232 and ps2keyboard, only the starting state is different. RS232 starts in MENU_ZERO, in MegaTune compatible state, where the one-character commands apply (like 'B' saves the settings to EEPROM like the "mcs" menucommand).

PS2KEYBOARD menu starts in MENU_mmm, (menu-main-main) the top level node of the multichar commands menu.

These are the same for both ps2keyboard and RS232, remember, that only the starting state is different.

The multichar mode provides some robustness itself (the valid subset of the codespace is smaller than for the single-char commands), and the "Mau" mode will provide the desired level of protection in the future. From keyboard ("Man" mode) it is not possible to define a 100% transmit-error-proof and still convenient protocol.

Note that most parts of the menu structure is intended to be used as the new megatunix commands (which has been on the table for some time), there is really no point in inventing another set of commands for the same things.

There are a few types of simple commands (case sensitive characters) like:

"mcs" menu config save(store) all config and tuning values

"mcS#" save tuning config in location #. Saves the fuel, ignition, lambda, boost and ve tables.

"mcL#" load tuning config from location #. Loads the fuel, ignition, lambda, boost and ve tables.

"mcd" menu config dump: The output is textual, with advantages:

"mct" menu tables dump: The output is textual, with advantages:

"mcBXX" changes the current baudrate. XX is the hex value of the divisor.

See GenBoard/InitialConfig for some sample config and tables...

Common things about the textual configuration, that makes it flexible:

Much simpler, than in case of a GUI, where you actually cannot do all these steps. The nightmare of having several incompatible megatune versions - where you are never sure enough if it really matches your firmware - is over. Adding new variables or deleting old is handled properly without silent, frightening overwriting unintended ones.

Designing a GUI (OtherTuningSoftware) is possible while leaving the rock solid OnlineCourse/TextualCommands there.

It would be nice if there was markers before and after the 'dump'. It'd make the parsing of the output both safer and simpler. Markers wouldn't have to be anything fancy, either just '# config dump start' and '# config dump end' or even just '{' and '}'.

"mmm" menu main main. Note: not the same as <esc>.

"mtt" m<char for menu><char for submenu> Go to a specific submenu, actually menu tuning tables

the "m.." commands are available from any submenu (more precisely 'm' goes back to mmm and

"tt" goes to mtt, but it is easier to .

mtt is probably the most important submenu:

Right after mtt (before an explicite goto) the cursor (pos) should be at the actual operating position determined by MAP, RPM, CLT, whatever the table uses for index. (currently only the table dimensions are enforced at table-switching, and originally pos=00).

Note, that these commands are only valid in tuning tables menu (after "mtt"), might

mean something else at other places.

"g3f" g<hex line><hex column> goes to a specific table position pos=0x3f;

"c8a" config[pos] = 0x8a; the magicstr for the given config element is displayed in the lcd_cache:

pos=3d/2 val=48 explana

tion of variable.......

.........

Those come from comments of config_t in global.h (feel free to review them for making them more clear). This is a nice reminder, but does not substitue a printed reference card with longer explanations. The config is handled like a whatever x 16 byte table. Also position 3f might be a subposition inside a multibyte array like 3d/2.

"j3a" j<2 char hex value> sets value in table called "j" (injection) injtable[pos] = 0x3a;

"n9f" n<2 char hex value> sets value in table called "n" (ignition) igntable[pos] = 0x9f;

They step the position so that you do not need additional goto commands if setting consequtive values. But they do NOT step to the next line in the table, but remain at the end. The meaning of the position is table dependent. For 8x8 table g37 goes to line3,col7, and g3f is actually meaningless, it actually goes to g37, it's closest meaningful neighbor.

"q"/"z" modifies the j table in +/- direction, while

"w"/"x" modifies the n table. At 0xff/0x00 it stays there, does not overflow.

"n<esc>" switches to the n table, but bails out to mtt menu before writing anything to the table. <esc> can be escape, or any silly (non-hexa in this case) character.

ARROW-KEYS (LEFT, RIGHT, UP, DOWN): ps2keyboard only. They move around in the current table, sometimes more convenient then a g.. explicite goto. The marker is updated in lcd_cache. Config is a little special, as you see above.

Note: at least 4 characters should be carefully picked that work in "mtt" mode and step inj/ign up/down. Otherwise j+0 and n+0 would be needed all the time if both inj and ign are tuned at the same time to switch to inj and ign table, respectively.

list of tables and dimensions (the above commands beginning with n or j apply to these, just change the n or j to this char):

d: dwell [1*2] (TODO: put to config_t)

j: injection,ve [8*8]

k: kparange [1*8]

r: rpmrange [1*8]

l: lambda target table[8*8]

n: ignition advance [8*8]

<esc> cancels the current command, but stays in the submenu ("mtt" in this case)

Since mtt is the most important submenu, it is easily noticable on the LCD:

In the top-left corner of lcd_cache you see "tc" for mtt menu, 'c' table,

"tn" for the ignition table. (for 20 column display you see "ttn").

"md" takes us to the debug menu.

"mdv" displays the build date for the installed firmware image

"mdV" displays the version number for the installed firmware.

"bye" leave manual mode (not very usefule for keyboard, but works) Note: active in the "mmm" main menu only.

"Man" goto manual mode from initial state of RS232. This is very important, since otherwise RS232 is in megatune compatible menu_zero after powerup, where you cannot easily communicate (binary data) The same applies if you went to menu_zero from menu_mmm with typing "bye" (this means you do not need to restart MS-AVR to use megatune after tinkering in the menusystem, just type "bye".) . This reserves the 'M' command from the old 1-char commands.) Note: strictly speaking "Man" is not a command in the menusystem, but it is used to put rs232 interpreter to the manual menusystem mode. In the future "Mau" will most likely be defined for a slightly modified automatic menu mode - used from megatun.. -, where msavr expects a protecting checksum at the end of the commands for robustness (people cannot calculate that checksum fast).

There are separate menu_t structures for rs232 and ps2. This is a very nice feature. You can be in one menu with one, and another menu with the other. The output is not strictly associated with the input.

LCD-specific commands:

Not that after these you find yourself in MENU_ml, so it is enough to type the last character to get the effect (but from MENNU_mmm you need to type the full 3-char command - of course!).

Debug submenu:

Output Testing Commands:

"mxo" - This command gives a fake rpm signal to the AVR. It can be used in conjunction with the following "mxp" command to test the Injector driver circuits.

"mxp" - This command gives a fake pulse width to the AVR. It is calculated as (value) * 64usec.

Each command must be give twice as directed in menu.c. An example of the test would be "mxofemxofemxp05mxp05".

After you are finished testing, issue "mxo00mxo00mxp00mxp00" to set the values back to their original state.

It is important not to get lost in the state-machine: simply go back to a known state with <esc>mtt or <esc>m.. for whatever submenu you want to be in in any case when you have doubts.

You should check menu.c ,which not hard to understand.

There is only one difference (that I can think of) between a GUI program (like MegaTunix) and me when it comes to this protocol: megatunix can calculate a checksum to protect communication, while I cannot. Later a flag can be added so that megatunix table-upload only takes effect after correct checksum, which is not needed from-keyboard. (the other difference is that I type 2 chars for an 8bit hexa number, while megatunix could do it in 1, but that is no issue when doing configuration - for realtime logging binary is often a better choice).

A shared .h file would make it easy to travel the (very shallow) menu. Recompiling megatunix is not as easy for an end-user as a config file, but still better than studying several megatune versions, and later a parser can be added. Currently the behavior is wired in menu.c and full megatunix interoperability is not very high on the todo list, since msavr is now perfectly tuneable without it.

VT100 support through rs232 will be somewhat laborsome (anyone?), but it could provide an amazing level of view detail in a very portable way. Even videos can be played via VT-terminal, think of aalib (a little awkward, I agree). Rumors have that someone is working on a pacman game for msavr :-)

A small printable reference card is now available, thanx to Mik. It is generated from cvs firmware module under doc/refcard directory using make, LaTeX, and dvips (urpmi tetex-latex tetex-dvips on Mandrake, YMMV). Run "make pdf" to generate.

Before the printable refcard was available, people printed this page, and also menu.c and global.h, and the compile-time generated varstr.h, magicstr.h.