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.
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.
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.
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.
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.
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.
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.
The protocols are easier to implement via offsets.
The ability to change the stored offsets within the firmware works well with human readable text keys.
Applying the KISS principle I recommend the following.
Define within the source the same text keys everyone with familiar with but as defined constants.
- define primep_temp_scaling 1
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!
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.
What about its drawbacks?
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.
Comments anyone?