Reduce ramp table size
Bug #1803167 reported by
Thomas Arthofer
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Flashlight Firmware Repository |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
Current flash use of ramping tables:
n-of-channels * 150 bytes
Idea:
Allow an expression that says: from x1 to x2, use the value Y, else refer to the table
The ramp-compression function takes ~50 bytes to implement, so if one mode removes at least 50 steps we make a net win.
Worst case is somewhere around 50 bytes saved while best case is the FW3A with 162 bytes saved
That is probably due to the extra FET level that just kicks in for turbo at lvl 130 which saves 129 bytes for itself alone.
Another 20 bytes could be saved by a 2nd expression (e.g. ch2 on FW3A has a row of 0s at the start and 255s near the end.)
But I don't think thats worth it.
Related branches
Revision history for this message
| Selene ToyKeeper (toykeeper) wrote | #1 |
| Changed in flashlight-firmware: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
Revision history for this message
| Thomas Arthofer (arthofer-thomas) wrote | #2 |
To post a comment you must log in.
This is an interesting idea. I wonder if it should use run-length encoding to decrease the size even more. It's pretty simple to implement, and can compress any number of runs within each table.
The basic idea there is to use a special marker, a counter, and a value. Optionally, the marker and counter can be combined into a single byte, like how the PCX image format works.
For example, with a marker value of 254, the following table...
0, 0, 0, 0, 0, 0, 50, 100, 150, 250, 255, 255, 255, 255, 255, 255
... could be compressed to this:
254, 6, 0, 50, 100, 150, 250, 254, 6, 255
Each repetitive string takes 3 bytes instead of its original length. Or, using the PCX method, values from 192 to 255 act as both a marker and a counter, with a maximum count of 64. This can work, but then actual ramp values in that range require two bytes -- 192, then the original number.
PWM2_LVL = RLE(pwm2_levels, level);
The downside is, while looking up values, it is necessary to iterate from the beginning of the table all the way to the requested index value. It could potentially turn a 10-instruction operation into ~450, in the worst case. But the code for this should be pretty small and simple, at least. And CPU cycles are not typically a bottleneck here.
Also, to keep the config files simple and straightforward, it might be nice to "compile" the config into a compressed form at compile time. I'm considering doing this in the build script.