_____  
 |  __ \ 
 | |__) |
 |  ___/ 
 | |     
 |_|     
         
         

         
         
  ####   
 ##      
 ##      
 ##      
  ####   
         

  _    _ 
 | |  | |
 | |  | |
 | |  | |
 | |__| |
  \____/ 
         
         

   ##    
    #    
    #    
    #    
    #    
    #    
   ###   
         

 _   _ 
( ) ( )
| `\| |
| , ` |
| |`\ |
(_) (_)
       
       

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
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. 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. 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. 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! 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. 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. Comments anyone?
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.