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

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

  ____  
 |  _ \ 
 | |_) |
 |  _ < 
 |_| \_\
        

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

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

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:
'''Versatility and saving SRAM space''' * '''versatility''' means that '''things are possible that otherwise would not be possible''' - users often request different deviant (sometimes unreasonable) function * '''only those features consume space that are actually used''' ** Remember that this is certainly not our major tool to save space. Using tables directly from EEPROM/flash saves appr 1000 bytes, so that is the main space-saver ---- '''Important warning: tuningsoftware issues''' Unfortunately the worst part of this is the tuningsw side, to make it configurable that is. '''We will NOT DEPEND ON THIS UNTIL that is solved''' Might not be hard, as MegaTune vemsv3.ini can be generated from a particular dynamic configuration. But anyway, must be solved. '''Textually configurable''' yacc / lex / whatever can be used to generate the binary translation of the human-editable language '''Graphically''' The dynamic config will originally not be graphically editable. TuningSoftware support for revpol is not more complex than other competing schemes (at least when considering only the cases that less effective scheme ssupport). Full graphical editor for the reverse-polish language will not be available this week, unless it is already implemented somewhere on sourceforge, look for graph editors on LogAnalysis. '''After all, all it takes is connecting the (input/output) ports of building blocks''' (like "blend" is a building block in our exampe below). ---- '''Dynamic configuration - THE best approach''' Far the best way for dynamic configurability is * simple language can be used * stored in a compact way * efficient for the firmware to execute Eg. a stack-based reverse-polish language (in short, let's call "revpol"), like postscript. (and maybe Forth ?). But stored in binary form. This means a user-specified function like <code> blend( tablelookup( vetable, RPM, MAP ), tablelookup( vetable, RPM, TPS ), curvelookup( MAP_TPS_blend, RPM ) ) </code> can be stored in appr 15 bytes. with 4 function codes. The blend function code is the very last byte, it eats 3 variables from the stack, calculates the blend result that it pushes back to the stack. Another example: * A + B * C is represented as B, C, *, A, + But remember we mostly use it for complex functions like * tablelookup (2D table) * curvelookup (1D curve) * blend * interpolate * read input * store / actuate output (or variable that can be logged) * read flash (care is needed to avoid access to unauthorized area) * ... The implementation is very fast, takes little SRAM and flash, and very efficient. Some functions must allow to load/store data from SRAM (/ flash / EEPROM), not just stack (the tablelookup above is a clear example). When someone wants to blend between 2 tables according to a manually actuated switch, the other according to actual position of the variable valves, we really want to avoid the configuration (+documentation) blowup that happens with the traditional config method. There are offtheshelf languages on this concept. Eg. [http://www.latrobe.edu.au/philosophy/phimvt/joy/synops.html Joy] We most likely need 2 (not 1) stack and a heap (pointers to which can be passed on stack). '''Scheme''' language might be good to look at, maybe there is an "embedded scheme" implementation that could be used with little effort * http://www.miata.net/sport/Physics/08-Program.html * http://sourceforge.net/projects/escm/ * http://citeseer.ist.psu.edu/dube00bit.html '''FORTH''' is another language that might be worth investigating. Although many of us will know it from Apple and Sun Firmware or !CompSci classes, it was originally designed for embedded applications (telescope control, specifically) and has been used on spacecraft by NASA, and on Boeing 777 avionics. It is available for AVR and ARM, and can be pre-compiled rather than interpreted if required. ''"Hardware engineers love Forth. Traditional computer scientists hate it."'' -- John Catsoulis, Designing Embedded Hardware, O'Reilly, 2005. '''Links about FORTH''': * http://www.forth.org/whatis.html * http://www.forth.org/successes.html * http://thinking-forth.sourceforge.net/ (online book in PDF format) * http://www.mpeforth.com/arena/ProgramForth.pdf (a different book in PDF format) Implementations for the AVR: * http://claymore.engineer.gvsu.edu/~steriana/Software/pfavr/rationale.html * http://www.ram-tech.co.uk/avr.htm * http://www.forth.com/embedded/index.html Q) What would be a good (but small!) proof of concept application (on AVR, ARM, or PC) for this approach? ---- * GenBoard/UnderDevelopment/FirmWare/MiscOutputs - some ideas will be merged to this page * GenBoard/UnderDevelopment/FirmWare/ConfigRelated - config changes that remain within "old style" boundaries
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.