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

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

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

______ 
| ___ \
| |_/ /
| ___ \
| |_/ /
\____/ 
       
       

__   __
\ \ / /
 \ V / 
 /   \ 
/ /^\ \
\/   \/
       
       

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:
'''With more and more firmware features, in the future we must be conscious about RAM usage''' '''How to be efficient with SRAM usage''' ? * avoid storage in SRAM where flash is better (constant strings!) * avoid global variables where local is possible * avoid features that are only for debugging, eg. BENCHMARK * keep table sizes reasonable: eg. 8x8 is more than enough for lambda (12x12 is unnecessary) * smart status and flagwords: use bits where possible (instead of whole bytes) * try to use tables from EEPROM / FLASH directly (instead of mirror in SRAM) and only cache data when necessary ** eg. during EEPROM-write ** dirty data (changed from tuningsw, not yet written) * pack bytes where necessary: ** internal high-resolution "learnt" VE: uint16_t ve_table[] (12 bit values would be enough instead of 16bits) The code must be reviewed so no SRAM is wasted by the first 3 ways. We must evaluate if the other SRAM-saving methods worths the effort or not. How can we tell the linker to place the struct benchstats to the end of SRAM ?
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.