History of GenBoard/UnderDevelopment/FirmWare/MenuRelated
Older Newer
2005-05-11 15:26:21 . . . . MembersPage/MarcellGal [development requirements]
2005-04-26 15:12:18 . . . . MembersPage/MarcellGal [split from firmware devl. page]


Changes by last author:

Added:
Menu related Subpage of GenBoard/UnderDevelopment/FirmWare

* Any new menu related developments must be planned/documented first, eg. in doc/refcard/refcard.ltx or the manual.xml .

* Preferrably implemented in a different file than menu.c so it is easy to use either new or old for some time (some people got used to old menu).

menu.c:

* 'mdh': m->tab is not used for a pointer (not dereferenced), but a simple 0..255 value (special purpose) in this case, see usage in menu_num_x. TODO: check if it is reset (eg. to j table) before any other menu (mtt !!) could act on it

menu.c:

* mcs: eeprom save variables runs asyncronously, thus lcd_init() will not show that the storing has completed. It can be just a visual feedback.

* Second serial connection - SV1: it would be nice to make AVR wake up so there is a menu listening on second UART. That will make 3 simultaneous accesses possible (currently 2 - without dispatching on the PC) and more importantly give people another chance to sort out comm problems (should the first channel have suspicion because of TX-TX abuse or whatever reason). We need to decide on default speed. I suggest 19200 or 38400. Should BootLoader also listen finally? (no free space in the upper 2kbyte at this moment). Find out how to notice a connected GPS module (so the GPS data can also be logged to MMC flash together with runtime data). GPS modules usually send out standard NMEA messages ($GPxxx) at least once/sec with 4800bps.

* Connection authentication - security - A configurable password, to protect RS-232 communication interface against "unwanted" tuners. Before using megatunXX-like programs you must run a small password sender application. But a well-trained hacker can download the contents of the eeprom, so a realtime table encryptor/decryptor built-in into firmware would be nice. :) Randomization of table/config positions before compilation should be enough.

** changing the Man sequence (compile-time) seems very simple.

** that should be completely enough after we make the AVR not wake up in the MegaTune mode if password is configured. There is a fuse-flag in AVR that determines if EEPROM is erased at erase operation (or just the flash). IIRC value bit3=8 (0x81 .. 0x89) in ...fuse. With that fuse, and without menu, you only need to make the PS2 default to pre-password-entered-mode to prevent access. You can waste any amount of time, but don't worry, they will just hook up a GenBoard (available in WebShop :-) to the outputs (of any ECM), log while the engine is running, and recover the tables. We do the same (see MembersPage/MichaelKristensen/MeasuringIgnitionAdvance)

** also want protection for BootLoader ? Shouldn't be needed, since BootLoader is not obligatory, and there is little room in the 2kbyte space anyway.