Store key layouts in EEPROM to enable layout changes without reflashing about kaleidoscope HOT 8 CLOSED

I've been pondering about this lately, and have a number of observations, and ideas.

Since the EEPROM is 1k, and a layer is 128 bytes, we could store at most 8 layers, but then there's no space for anything else, not even a byte to store the default layer at. So that's 7 layers, and then we have 128 bytes for other things. But all that space reserved for the keymap sounds like a waste when one would usually have about half of that. Not to mention that plugins may want to store stuff in EEPROM too. So, ideally, the number of layers to store at most would be configurable at compile-time.

This raises another question, however: what happens if one recompiles the firmware, with a different reserved size, and boots the keyboard with that? As far as the keymap is concerned, it can handle it gratefully, and only load the layers that it can. However, if we store the keymap at the beginning of EEPROM, then other settings stored after it, will suddenly find themselves in the reserved area.

For this reason, it would make sense to store the keymap at the end, and use the first two bytes of the EEPROM for some meta-data:

• 3 bits for the maximum number of layers.
• 5 bits for the default one. When not using EEPROM for the keymap, we can have up to 32 layers (assuming the layer PR gets in, 256 otherwise), so this should use more bits.
• 3 bits for the number of layers currently in EEPROM.
• 1 bit to signal whether to use the EEPROM keymap, or the firmware default. Reason for this is safety: to be able to get back to the default keymap within the firmware, without losing any info about the EEPROM one.
• 4 bits free for other settings.

I'd store the current number too, so that when a new keymap is written to EEPROM, one with fewer layers than the maximum, we wouldn't have to empty the remaining ones to not leave junk there. With this setup, we'd have about 126 bytes of space at worst for extensions, and they could safely store their settings starting from the third byte, without having to worry about finding that area reserved.

If the default layer is higher than the max supported, then the use-eeprom bit should be ignored, and we'd fall back to the firmware keymap.

I have a couple of ideas about how to implement this efficiently, in a way that is plugin friendly. will write those up later.

from kaleidoscope.

What should happen when we toggle the use-EEPROM bit on or off? Should we clear the default layer setting? What if one of the keymaps have fewer layers than the other, and the default is higher than the selected one's maximum? What about the current layers?

IMHO, the least surprising would be if we'd reset the default layer to the first, and would turn off all other layers when updating the EEPROM with the use-EEPROM bit set. Same when we toggle the use-EEPROM bit on or off.

from kaleidoscope.

Another interesting bit is how to get the keymap to EEPROM? Trigger the upload mode, and send the data over Serial: a single byte telling us the number of layers, followed by N * 128 bytes for the layers. Once consumed, and finished updating the EEPROM, sends an OK back. Data arrives in binary, and we store it as-is. Sounds simple enough...

from kaleidoscope.

Oh, and one more thing: if the max layer number is set to zero, then the whole use-EEPROM stuff should be disabled. The reason the max number is stored in EEPROM too, is for the case where the firmware gets recompiled with a different max value.

What should we do in this case?

• Firmware max == EEPROM max: Nothing to do, we can leave things as-is.
• Firmware max > EEPROM max: We can either invalidate the keymap, or move it. Invalidating has the advantage of less EEPROM writes, as one would expect that when the firmware max changes, one will upload a new EEPROM keymap soon after, anyway, so the move would be wasteful.
• Firmware max < EEPROM max: Moving in this case would lose data, so invalidate sounds best.

So, if the firmware max != EEPROM max, then the use-eeprom bit should be cleared, EEPROM layers set to zero, and then the eeprom max updated, to be safe, and least wasteful.

from kaleidoscope.

I started experimenting with an API on my wip/eeprom branch. It doesn't seem too bad, but some of the things I went on above is missing still.

from kaleidoscope.

I accidentally a plugin. Not 100% there yet, but very, very soon.

from kaleidoscope.

I am typing this from a keyboard that has NO built-in keymap in PROGMEM, it is stored entirely in EEPROM, and is update-able via the Focus plugin.

The downside is that the cycle length is about an ms longer this way, but we're still below 8ms, even with a lot of plugins enabled. If need be, we can speed things up a bit at the cost of 64 bytes of SRAM...

from kaleidoscope.

The EEPROM-Keymap plugin implements this, and a bit more.

from kaleidoscope.