Reduce PROGMEM usage for sendstring LUT

[kitlaan]

Description

Bit-pack the keycode bool array to gain back a small amount of flash space.
The trade-off is an increase in runtime instructions when running macros.

It does make the code a bit harder to read, as well as maintain.

For configs that use send_string() et al, it saves ~100 bytes.

I'm really unsure if this is even worth it given the annoyance...
I did NOT test this, other than compiling a few random user keyboard configs to see for size differences. For example, kyria:drashna moved from a failed build to just back under the line.

Also note: When I run clang-format on quantum.c, it decides to do some weird reformatting. So I didn't run it here.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

Could we perhaps leverage something like the following, to simplify the conversion?

#define LUT_BYTE(a, b, c, d, e, f, g, h) \
  ( ((a) ? 1 : 0) << 7 \
  | ((b) ? 1 : 0) << 6 \
  | ((c) ? 1 : 0) << 5 \
  | ((d) ? 1 : 0) << 4 \
  | ((e) ? 1 : 0) << 3 \
  | ((f) ? 1 : 0) << 2 \
  | ((g) ? 1 : 0) << 1 \
  | ((h) ? 1 : 0) << 0 )

We'd then be able to do this, which is a lot closer to what we had before:

const uint8_t ascii_to_shift_lut[16] PROGMEM = {
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0),
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0),
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0),
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0),
    LUT_BYTE(0, 0, 0, 0, 0, 1, 0, 0),
    LUT_BYTE(0, 0, 1, 1, 0, 0, 1, 1),
    LUT_BYTE(1, 1, 1, 1, 1, 1, 1, 1),
    LUT_BYTE(1, 1, 0, 0, 0, 0, 1, 1),
    LUT_BYTE(0, 1, 1, 1, 1, 1, 1, 1),
    LUT_BYTE(1, 1, 1, 1, 1, 1, 1, 1),
    LUT_BYTE(1, 1, 1, 1, 1, 1, 1, 1),
    LUT_BYTE(1, 1, 1, 0, 0, 0, 0, 1),
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0),
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0),
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0),
    LUT_BYTE(0, 0, 0, 0, 0, 0, 0, 0)
};

[kitlaan]

I had considered it but didn't really think it through. Actually seeing it typed out, I should have tried it!

I'll update the branch and see if I can clean it up even further.

[kitlaan]

Did some changes, and things are looking promising. Much cleaner and "easier" to maintain. I'll finish it up shortly and push, and see if folks like it better.

Now that I have my board running properly, I can finally test and see if there are any real performance differences. Even if there aren't, keeping both flows "for a while" still seems wise.

Reminder: resync master and make the same edits to the new sendstring LUTs.

[kitlaan]

A question I was pondering is if there are any folks that have their own LUT definitions. If there are, then changing to packed-always would hopefully compile error (type redefinition?) if we kept the old variable name. Or they'd silently go back to the default LUT without warning if we changed variable names.

Is that reasonable to do? Or is it a breaking change? Or an I just being over-cautious?

[tzarc]

Discussed with the others, the general feeling is that we'll go with the bitmasks and drop the full-size arrays. Makes no sense to have it configurable.

If we can get the other languages sorted as well, I think we'll be much closer to merge!

[kitlaan]

All updated, and gave all the headers a quick compile-smoketest.

I believe there' still the Hungarian pull request pending, so once that's merged, I'll update my branch. And hopefully that's it.

[drashna]

I'm really unsure if this is even worth it given the annoyance...
I did NOT test this, other than compiling a few random user keyboard configs to see for size differences. For example, kyria:drashna moved from a failed build to just back under the line.

lol. Yeah, My keymaps tend to run very close to the line, and depending on which compiler version you're using, may actually go over it. :D

For the most part, as long as the default keymap compiles, and nothing is broken, that's fine. And in the case of my keymaps, as long as it compiles, even if it's over, that's fine.

And in this case, testing locally, looks good! No issues from what I am seeing (namely, my make and version commands)

[fauxpark]

A spot of prettifying

[tzarc]

Hungarian can get sorted out later. Merging.