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 could trash the config variables. This was solved with different commands for config and tables; so no unintentional crosstalk is possible any more.
Checksum protected comm-commands is a thing of the future.
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)