Keymap in eeprom

[kairyu]

Hi Hasu,

I tried to write a keymap-in-eeprom feature that make the firmware can read keymap from eeprom instead of flash at runtime.

So with this, users can change their keymap settings by only reflashing something in the eeprom. And I also wrote this to make it easier to generate an eep file with proper keymaps in it. Demo

This is only an optional feature and will not affect others, I think.

Best regards, Kai

[tmk]

Sorry for late response.

Hmm, interesting. Nice keymap editor idea. EEPROM is really another viable resource for keymap storage.

I also worked keymap editor and it is primitive but works well somehow. I use end region of flash memory for keymap storage for this. Usually you will have enough free flash memory at the end of region. http://www.tmk-kbd.com/tmk_keyboard/editor/index.html

And I noticed this concern: Seems like Teensy's bootloader and loader program are not capable of programming EEPROM region.
If I'm right this may be a problem for many users of tmk, because of its popularity in the keyboard community. Many many poeple prefer to use Teensy.

And I'm working on porting tmk to Cortex M and I'll need to learn how we can handle EEPROM with that MCU.

Looks like some more investigation is needed.

[kairyu]

Thanks for you reply.

I'm sorry for the lake of explanations.

When KEYMAP_IN_EEPROM is enabled, keyboard will check is there a "good" keymap in EEPROM (by a simple checksum). If there is no keymap (almost the initial status) or no good keymap (perhaps caused by some accident?) in EEPROM , a default keymap copied from FLASH region will be written to EEPROM.

So I think even someone who is not able to access EEPROM enabled this feature unexpectedly, this feature won't brick their keyboard, they can type with the default kemap as well.

I'm also thinking about to implement a feature what can transfer keymap via USB HID in the future.

And I'm very glad to hear that you are planning to port tmk_keyboard to Cortex M, it's really a good news. 楽しみにしてます。

[bgould]

It would be nice to make this into an API of sorts that you could use to plug in different means of storage... for example an alternative could be to use an external FRAM for example which could be written dynamically and store many different keymaps, I'm sure there are many other possibilities as well.

On 2014-07-07 03:26, Kai Ryu wrote:

Thanks for you reply.

I'm sorry for the lake of explanations.

When KEYMAP_IN_EEPROM is enabled, keyboard will check is there a "good" keymap in EEPROM (by a simple checksum). If there is no keymap (almost the initial status) or no good keymap (perhaps caused by some accident?) in EEPROM , a default keymap copied from FLASH region will be written to EEPROM.

So I think even someone who is not able to access EEPROM enabled this feature unexpectedly, this feature won't brick their keyboard, they can type with the default kemap as well.

I'm also thinking about to implement a feature what can transfer keymap via USB HID in the future.

And I'm very glad to hear that you are planning to port tmk_keyboard to Cortex M, it's really a good news. 楽しみにしてます。

Reply to this email directly or view it on GitHub [1].

Links:

[1] https://github.com/tmk/tmk_keyboard/pull/113#issuecomment-48147906

Benjamin Gould [email protected] Hire me on elance.com: http://bcgould.elance.com/

[shayneholmes]

This change makes the EEPROM setting the default for gh60; is that something this is ready for, or should it remain off by default?

I think that confusion could arise if someone goes with the old workflow and compiles a new layout and puts it on their device without clearing the EEPROM, only to find that it's not working right (because the old layout is still in the EEPROM and still has a valid checksum).

[kairyu]

This change makes the EEPROM setting the default for gh60; is that something this is ready for, or should it remain off by default?

This feature is disabled by default, it will change nothing just like the other optional features unless someone writes KEYMAP_IN_EEPROM_ENABLE = yes in his Makefile or define the macro in some other ways.

If someone want this feature, it will works with any keyboard with some settings as follows.

• Define KEYMAP_IN_EEPROM_ENABLE = yes in Makefile.
• Define FN_ACTIONS_COUNT and KEYMAPS_COUNT in config.h which mean how many fn_actions and keymaps (layers) are the maximum you can have (usually decided by the size of matrix and EEPROM).
• Implement two functions: const uint8_t* keymaps_pointer(void) and const uint16_t* fn_actions_pointer(void) to tell system where your keymaps and fn_actions are in FLASH region.
• Implement two functions: uint16_t keys_count(void) and uint16_t fn_actions_count(void) to tell system how many keys and fn_actions do your keymap have.

Then you can get keycode and fn_action from EEPROM by calling eeconfig_read_keymap_key(layer, row, col) and eeconfig_read_keymap_fn_action(index) now.

I think that confusion could arise if someone goes with the old workflow and compiles a new layout and puts it on their device without clearing the EEPROM, only to find that it's not working right (because the old layout is still in the EEPROM and still has a valid checksum).

Yes, you are quite right. This is also the reason why I made the boot magic which clears EEPROM to clear keymap-in-eeprom too.

[kairyu]

It would be nice to make this into an API of sorts that you could use to plug in different means of storage... for example an alternative could be to use an external FRAM for example which could be written dynamically and store many different keymaps, I'm sure there are many other possibilities as well.

It's a good idea! Seems some more investigation is really needed.

[shayneholmes]

Change 0f3116255468cb89492072c775987b255d469d9e adds that KEYMAP_IN_EEPROM_ENABLE = yes line to the gh60 Makefile and does all the things you said needed to be done to turn it on, making it the default for gh60 users. It sounds like that change should not be part of this pull request, but should be in some kind of example file instead of the main Makefile.

[kairyu]

Change 0f31162 adds that KEYMAP_IN_EEPROM_ENABLE = yes line to the gh60 Makefile and does all the things you said needed to be done to turn it on, making it the default for gh60 users. It sounds like that change should not be part of this pull request, but should be in some kind of example file instead of the main Makefile.

Thank you, I got it. Then what about commenting out KEYMAP_IN_EEPROM_ENABLE = yes line in the Makefile of this pull request? Other changes in 0f31162 are protected by macros like #ifdef KEYMAP_IN_EEPROM_ENABLE so code size will not change I think.

[shayneholmes]

That sounds like a good fix to me!