Changes by last author:
Changed:
| I've had some discussion about the settings and their storage within the firmware with Marcell. I've included some of my ideas with this and I'd like to see any criticisms people can bring up. |
| This page is about addressing variables |
| There is a table stored within the ECU with all the settings. Currently it can be up to 255 characters in length. There are human readable strings assigned to each 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. |
| Primarily between tuningsoftware and firmware. |
|
There are a number of objectives behind this implementation:
* the firmware developers are free to move bytes around within the table and as long as the software uses the mcd command and parses the output to figure it out this shouldn't break anything in future versions. * the human readable keys make it very difficult to confuse which setting is being changed. |
|
----
If firmware resets while megatune is in some page, like VE or ignadv |
|
In my opinion there are also some downsides.
* The implementation requires the tuning software to read and parse a large amount of data in order to determine the values behind maybe 255 different stored settings. This is very difficult to deal with in a packetized protocol. * The current implementation does not allow saving settings based on their human readable text keys. This means the tuning software must use it's parsed list to build a lookup table and set the values by the table offset. This is a pain, especially when performing a firmware upgrade without losing any settings. * implementing a text based key option for saving settings would require a fair amount of memory within the firmware. Key lookups would also consume a quantity of processing in order to do a text search through the keys. |
| MegaTune could trash the config variables. This was solved with different commands for config and tables; so no unintentional crosstalk is possible any more. |
| Marcell pointed out that there was a paging mechanism dealing with the old MS protocol that can also read and write settings. I like this idea but it seems silly to have 2 competing mechanisms for doing the same. |
| Checksum protected comm-commands is a thing of the future. |
|
= Proposed Solution =
The ECU is a simple piece of hardware and it doesn't care if a key is specified as an offset rather than a string. Actually it prefers the former because of its limited resources and processing capacity. A text search for a key lookup will require O(nc) complexity. A lookup based on an offset will require O(c) and in this case the c is very very small. |
|
----
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 stored within the ECU EEPROM with all the configuration. It is likely that more configuration 2..3 pages will be necessary in the future |
| The programmers care about using text strings because it is easier to debug and write the software dealing with text strings rather than table offsets where numbers can be easily mixed up and mis-copied causing difficult to fix bugs. |
|
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 |
| The protocols are easier to implement via offsets. |
| Using binary offsets |
| The ability to change the stored offsets within the firmware works well with human readable text keys. |
|
We decided to use binary offsets for normal
* reads (ECU => tuningsoftware, see send_page() * and writes (tuningsoftware => ECU, see store_page() |
|
Applying the KISS principle I recommend the following.
Define within the source the same text keys everyone with familiar with but as defined constants. |
| because the protocol is easier to implement via offsets (=fixed length keys). |
| #define primep_temp_scaling 1 |
|
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. However this is not planned. It does not make sense for firmware to get this kind of job off of the tuningsoftware's shoulder. Determining offsets |
| So now we can say someconfigarray[primep_temp_scaling]=0x06; in the code and this actually compiles to someconfigarray[1]=0x06. The same header file can now be exported to the tuning software developers and in a simple protocol they can read and update the setting referring to it in their software as primep_temp_scaling. When the software is compiled it will of course be changed to 1! |
|
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 but exactly the config version, that is updated when there is a change in global.h config_t keys * 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. |
| But wait! If the firmware developers want to change where something is stored they can't anymore and we're tying their hands! Not so fast pilgrim! Since this part is important to firmware developers we can simply define a translation matrix of X bytes translating slot N to whatever slot it really belongs in. |
| While it seems that this is just shuffling the complication around it seems to be a stronger solution to me. Computers can deal far more efficiently with offsets than text strings. They are more memory and more computationally efficient. The protocol is more efficient. |
|
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. |
| It may also be possible using a lookup table for the offsets to store multiple maps containing only certain changed settings. Let's face it your number of cylinders won't change from map A to map B! |
| Implementation |
| What about its drawbacks? |
|
Marcell and Hackish agreed on the following on irc:
Tuningsoftware uses a define: <code> #define primep_temp_scaling 1 </code> |
|
I haven't really come up with any yet.
Deleting a setting may create fragmentation in the lookup table because the discontinued settings would still need to exist. Even the prospect of a lookup table involves at most O(2c) processing time. These two lookups are smaller than a single key comparison using text keys. |
|
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) so the implementation is dead-simple now (macro can also be inline function of course), and can be easily upgraded later simply by changing to <code> #define primep_temp_scaling "primep_temp_scaling" </code> and implementing the * slightly more complex macro that uses the hash * initializing the hash from mcd output (or local database) |
| Comments anyone? |