Proposed Changes To Some Core Vars/Tables
Posted: Tue Oct 04, 2011 8:27 pm
Thinking about this change was motivated by moving the table axis to 8 bits from 16. This brings some benefits with it, such as being able to have a 31x15 or 30x16 table in either direction, good for high boost only or high rpm only engines. The current status quo is 27x17 which is still going to be an available option.
When 8 bit axis are used, you're stuck with 0-255 * 256 as your range of raw values. In RPM terms that mean that our raw values would suddenly be 128, 256, 384, 512 etc. Not exactly pleasing to the eye in a GUI. In kPa terms the situation was similar, 2.56 kPa steps. Not as bad, but still annoying.
The solution then is to reconcile these uglinesses with scaling changes to those two main vars.
kPa affects the fueling math calcs and mtx scalings and RPM affects scheduling calcs and mtx scalings.
For RPM we can reduce our overly heady 32767.5 max RPM back to a mere 25599.6094, still more than good enough for the craziest of bikes and now the steps in the GUI tables are suddenly 100 RPM, much better.
For kPa we can reduce our unreasonably high maximum boost level from 555 kPa/5.5 bar/80psi to a mere 412kPa/60psi/4bar of boost (512kPa total range).
To generate kPa we just scale from sensor config anyway, so there is no loss in performance as the internals of the code don't care about what scale it is on.
To generate RPM we do a calculation involving normal math anyway, so again, it's the same. The internal numbers are never visible anyway. In cutecom they come out as hex, and in OLV or MTX they come out as a pre-scaled number.
In other words, the only loss is a bit of range, which was excessive anyway, and a bit of time making the change and triple checking it. The gain is the prettiness of the GUI and using less memory and/or making more out of the memory available. There will be a slight loss of efficiency in the table lookups, however they aren't a critical code path, and it will be a very simple/quick left shift operation anyway.
Today I did the ground work on the tables and committed the spread sheet. The next 2 posts will contain my plans for timing tables and Lambda tables.
I will unlock this thread to allow comments with the final post in this series of proposed changes.
Fred.
When 8 bit axis are used, you're stuck with 0-255 * 256 as your range of raw values. In RPM terms that mean that our raw values would suddenly be 128, 256, 384, 512 etc. Not exactly pleasing to the eye in a GUI. In kPa terms the situation was similar, 2.56 kPa steps. Not as bad, but still annoying.
The solution then is to reconcile these uglinesses with scaling changes to those two main vars.
kPa affects the fueling math calcs and mtx scalings and RPM affects scheduling calcs and mtx scalings.
For RPM we can reduce our overly heady 32767.5 max RPM back to a mere 25599.6094, still more than good enough for the craziest of bikes and now the steps in the GUI tables are suddenly 100 RPM, much better.
For kPa we can reduce our unreasonably high maximum boost level from 555 kPa/5.5 bar/80psi to a mere 412kPa/60psi/4bar of boost (512kPa total range).
To generate kPa we just scale from sensor config anyway, so there is no loss in performance as the internals of the code don't care about what scale it is on.
To generate RPM we do a calculation involving normal math anyway, so again, it's the same. The internal numbers are never visible anyway. In cutecom they come out as hex, and in OLV or MTX they come out as a pre-scaled number.
In other words, the only loss is a bit of range, which was excessive anyway, and a bit of time making the change and triple checking it. The gain is the prettiness of the GUI and using less memory and/or making more out of the memory available. There will be a slight loss of efficiency in the table lookups, however they aren't a critical code path, and it will be a very simple/quick left shift operation anyway.
Today I did the ground work on the tables and committed the spread sheet. The next 2 posts will contain my plans for timing tables and Lambda tables.
I will unlock this thread to allow comments with the final post in this series of proposed changes.
Fred.