This page is about addressing variables
Primarily between tuningsoftware and firmware.
If firmware resets while megatune is in some page, like VE or ignadv
MegaTune can trash the config variables. This is a serious problem of the MegaTune protocol.
- In fact, the idea of 2-byte commands without complete address, and any checksum is bogus.
- Commands should have checksum for the whole command: with the whole variable address included in the command (the page address is currently in a previous command !).
- Different commands for different pages would be nicer (this was the approach earlier, before the pages was introduced)
Powering up in "last-page" mode is not possible. This suggest that the firmware should power up in a state where nothing is ruined. (much better, than when it points to config: the config is the worst thing that can be ruined by MegaTune).
There are
- several tables, currently max 256 elements/table. These should not change if possible. Tuningsoftware can assume that page4 remains VE (page5=lambda, page6=ignadv). The rpm and kpa array is (currently!) appended to pages 4..6 (for MegaTunix historical reasons), but also available on page2 and page3. Size can also change (8x8, 12x12)
- a configuration array, currently max 255 characters
There are human readable strings assigned to each variable as key and the firmware will (using the mcd command) spit out all the human readable strings in the order of their offsets within the settings table. This is useful to
- do backup
- determine variable offsets
Using binary offsets
We decided to use binary offsets for normal
- reads (ECU => tuningsoftware, see send_page()
- and writes (tuningsoftware => ECU, see store_page()
because the protocol is easier to implement via offsets (=fixed length keys).
This addressing is already implemented with 7 pages (page 0..6, see pages_ptr[]) and used for megatunix. It is efficient. The minor problem is that mtx uses a primitive checksum-less protocol, so some framing with GenBoard/BinaryProtocol is nice. But that does not effect addressing, only a transport issue.
Implementing firmware support to 'save variables based addressed via the human readable key would be simple, and would require 0 bytes of SRAM:
- the text based keys consume 0 SRAM since they are in FLASH. (there is place for the necessary pointers and state variables in menu_t)
- they are already there, so they consume no extra FLASH either. Some structures in flash to make the lookups faster would consume some little of the cheap FLASH-space.
Determining offsets
While the binary offsets are useful inside the read-store commands, they are very dangerous to maintain manually. We tried, and they broke earlier. Manual maintenance of key=>offset is OK temporarily, but is not a good long-term solution
- a tuningsoftware can determine the offsets reading config version from the firmware and doing a lookup of local database (or cache). It must be emphasized that this is NOT the same as
- board HW version
- board serial number
- firmware version
- protocol version
- if no key=>offset database is found, the tuningsoftware can find out (and cache at least in memory) offsets reading (something similar to) mcd output.
Objectives
- the firmware developers are free to move bytes around within the table
- the human readable keys make it very difficult to confuse which setting is being changed.
Issues
- as the mcd output is bigger than 255 bytes, it must be read in chunks, eg. 8..16 keys at a time
- the tuning software must keep a text key => offset hashtable. This is very common nowadays, because it provides O(c) complexity, while a parsed list would be O(nc): a bad idea.
Implementation
Marcell and Hackish agreed on the following on irc:
Tuningsoftware uses a define:\nÿ1ÿ
Tuningsoftware uses a
- lookup macro to get the offset
- another macro to get the actual value (that uses the above macro to get the offset first)
#define primep_temp_scaling "primep_temp_scaling"
and implementing the
- slightly more complex macro that uses the hash
- initializing the hash from mcd output (or local database)