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 a number of parameters. Here are a few features I thought up:
fan control
enable temp
enable added steps to the IAC
disable temp
disable subtracted steps from the IAC
Vtec control
enable rpm
enable temp
enable MAP
Disable RPM
Disable MAP
fuel pump (maybe pre-defined)
prime time
Tach signal (maybe pre-defined)
tach divider
PWM IAC
frequency
minimum duty
maximum duty
intercooler fan and/or intercooler water spray
enable IAT temp
enable added steps to the IAC
disable IAT temp
disable subtracted steps from the IAC
Nitrous enable
minimum RPM
maximum RPM
minimum TPS
minimum MAP
maximum MAP
shift light
minimum rpm
maximum rpm
misc output control
minimum RPM
maximum RPM
minimum TPS
maximum TPS
minimum MAP
maximum MAP
Another sort of output may need to be driven from a table. TGV/TVIS/AVCS/IAB control, electronic throttle and others come to mind.
For TGV/TVIS/AVCS/IAB and possibly iVTEC the computer may control offsetting one or more cams and/or adding to the lifts at different RPM and load combinations. Electronic throttle control will be the way of the future as more and more new cars are drive by wire. I suspect this will require a completely dedicated implementation. For the above the outputs are most likely to be PWM based. I can confirm that AVCS (on Subarus) is PWM controlled. I believe the same with the new i-VTEC found on hondas. Certain RPMs and MAP values require certain PWM outputs in order to aid in spooling the turbo or creating lower RPM torque.
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?
The current implementation is rather short sighted and wasteful. You pay the overhead even if you don't use a feature. Unfortunately this implementation is more difficult because of the dynamic memory space. Using static sizing is as wasteful or worse than the existing solution.
There is lots of space in eeprom to store these but eeprom is a bad solution because it lacks any quick access method. As a result we are forced to read the values into RAM. Removing these from the 'C' table would free up about 30b of memory if the table size were reduced accordingly.
Personally I would prefer to have them stuck in flash. This would provide quick reads where the parameters would not necessarily need to be stored in RAM. Unfortunately this brings about a challenge for updates. While technically possible each parameter would be limited to about 10,000 changes. We're probably okay with this. The other challenge is halting the processor long enough to perform an update without missing an ignition event or some other time sensitive event. While tuning I'm not sure if you really want to write your flash page 100 times as you adjust values.
All in all I suspect we would need about 20*8 bytes of memory, be it flash or SRAM.
---
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).