This page discusses the advantages and disadvantages of using human readable and issuable commands (protocol) vs. binary
For a very limited design the binary commands (protocol) seem to be a good choice (then you need a powerful additional computer HW and software just to communicate with your hardware), but for a powerful design it is better having human readable and typeable commands.
This allows you to type your commands on a
Advanced industrial equipments (routers, aeronautical computers, industrial process controllers, unix machines) mostly use the powerful and convenient textual way.
"g34j67" instead of 3 humanly unreadable and untypeable characters, but for human this is the only sane way. (if you happen to worry about bandwidth: actually when setting several consequtive values - utilizing the autostep feature - it is 3 characters either way, just those 3 are unreadable with the binary protocol).
Even if you plan to make an eye-catching GUI (OtherTuningSoftware), the possibility of simply testing the commands (thus decoupling GUI and firmware development!) is a very nice feature.
The above command works from mtt, therefore if you want to issue from an unknown place, prepend with "mtt".
where is it implemented?
menu.c (and kb.* for ps2 keyboard "driver" and lcd_display.* for formatting the output inside lcd_cache and lcd.* for displaying lcd_cache on real LCD) was initially written by MembersPage/MarcellGal, MembersPage/MichaelKristensen made nice improvements and MembersPage/DaveBrul helped in testing. Note that they are quite general to be useful in applications other than engine management - anywhere where you want to input tables and parameters, and store them in eeprom persistantly (show me an application which does not benefit from it).
See the MenuSystem? for details on the commands.