_     
| |    
| |    
| |    
| |____
\_____/
       
       

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

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

 _     
( )    
| |    
| |  _ 
| |_( )
(____/'
       
       

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

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:
'''Misc output related subpage of GenBoard/UnderDevelopment/FirmWare''' Also some general method (see interpretere below) to define functions for misc output actuation * WOT_OUTPUT_TPS_THRESHOLD should be specified in config_t or dropped (misc outputs there) * wot_output needs hysteresis * miscX_activity needs hysteresis ---- '''Interpreter''' There are more and more stuff that needs flexible configuration, without firmware recompile, eg. misc outputs. Currently condition is wired for most common function, RPM,MAP,TPS ranges I think we cannot avoid a simple language/interpreter. Maybe a postscipt-like (but binary) code: words of 16 bits that are * either push variable "..." to stack * or operation "..." that takes N variables from stack, operates on them and places result on stack --- Michael's Ideas... There are a few parts to this challenge. First of all it's necessary to cater to a potentially long list of functions. Adding canbus enabled switches allows for an impressive range of features. VSS encoders, clutch switches, ALS enable switches, boost knobs are all potential inputs. On the output side one can have as many outputs as there are spare channels. Potentially extra drivers could be available via CANbus. First the outputs... I assume at this point we're dealing with a finite number - limited by the number of spares you have. This could still number 8 or more. Outputs may potentially be switched based on CLT, TPS, MAP, RPM, IAT to name a few off the top of my head. Another sort of output may need to be driven from a table. TGV/TVIS/IAB control (can you elaborate ?), electronic throttle and others come to mind. The output may need to be on/off or PWM. ---- '''Storage''' The code for doing these checks is fairly trivial. Efficient storage of the parameters is somewhat less trivial. A dynamic size for these functions would require a lot of work. First you would need a means of specifying the size of each record and secondly you would need a means of properly shuffling things around should changes be made. Anyone remember Norton Defrag? If a '''block contains 8 instructions''' (16 bytes), that can be do more than the current misc1 misc2 implementation, basically enough for any function that comes to mind. The '''fixed size block makes the defragmentation issue go away''' (the same way they allocate fixed size pages in OS-es). Besides range checks and alike, there will be some complex functions as well. We can add a * "jump" instruction that makes it possible to use more than one 8-instruction blocks (even jump into the middle) * "conditional jump" makes it very powerful ---- '''Shiftlight''' We need to change shiftlight code a bit so the configured RPM treshold is compared againds RPM + dRPM/dt*0.5sec (not just RPM). This means the light (beeper, whatever connected) is activated somewhat earlier in gear1 and gear2 (but gearbox switches not needed).
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.