Reduce ramp table size

Bug #1803167 reported by Thomas Arthofer
6
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.

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

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.

Changed in flashlight-firmware:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Thomas Arthofer (arthofer-thomas) wrote :

Tried RLE and it looks a lot better, uploaded a build here:
https://zeroflow.at/flashlight/anduril_RLE_working.zip

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.