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

 _____ 
|  _  |
| | | |
| | | |
\ \_/ /
 \___/ 
       
       

 _______ 
(  ____ \
| (    \/
| |      
| | ____ 
| | \_  )
| (___) |
(_______)
         

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

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

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:
'''This page is about addressing variables''' Primarily between tuningsoftware and firmware. 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 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. 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''' 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. '''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: <code> #define primep_temp_scaling 1 </code> 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)
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.