Is it possible to preserve the state of a variable in the keyboard, even if the keyboard loses power?
It would be useful for an idea I have. Even a single byte could be enough and if read/write is slow, that would be acceptable as well.
/Lasse
You can store such state in EEPROM, of which there’s a full kilobyte available for you to use. This would be a reasonable intro, I think:
Is it documented anywhere how many write cycles the Model 01’s EEPROM is rated for?
This says 100000 writes.
Cool, though 100000 writes isn’t very much if every state change is written to EEPROM. In such a scenario it would fall a bit short of the “heirloom that you hand down to your grandchildren” level as the EEPROM would be burned out in 2 to 3 decades. 
Which then leads to another question. Do we have any way to know how many writes to EEPROM a given Model 01 has been subjected to? (Asking because in 10 years a Model 01 with 90000 writes left will be clearly more valuable than one with only 500 writes left.)
Out of curiosity, what kind of state do you want to store? Perhaps it would make more sense to store it on the host, and let a small tool on the host tell the keyboard what the state is?
As far as I know - nope, there’s no way to know. Additionally, I’d say that 100k writes is what the EEPROM is rated for. It might very well support way more than that.
Not for me, the original question asker.
The only way I could see to reliably preserve the state of a variable in such a way that it would be guaranteed to survive power loss would be to write said variable’s contents to EEPROM on every change.
Feel free to prove me wrong on that. 
(Is there enough time/power to write out data upon detecting the cable is being unplugged? My hunch is “no”.)
If you send to the host on every change, that has roughly the same guarantees. Sending to the host is slightly more fragile, but only slightly. Saving to EEPROM isn’t 100% safe either, because the keyboard can lose power between the variable changing state and the EEPROM write starting.
1 Like
My idea was to implement the Tarmak method of learning Colemak
https://forum.colemak.com/topic/1858-learn-colemak-in-steps-with-the-tarmak-layouts/
The idea was that you could switch layouts every week or every second week to match the speed of progress. But you might quickly drop back to a more familiar layout, if the heat suddenly is on at work.
E.g. you could map ctrl+alt+shift+0 to querty
and ctrl+alt+shift+1 through 5 to tarmak #1 to #5, where #5 is full colemak.
So you’d only need to store state when they layout is switched, which would be very rare.
I am so busy at the moment - I probably won’t find the time to actually do it.
But maybe I get bored sometime during the summer holidays…
Here’s a heatmap. Almost all the red keys moves to the home row in colemak. That makes learning it seem like a worthwhile investement.
In that case, switching is rare enough that EEPROM wear shouldn’t be a problem. Mind you, for similar purposes, one might just forego storing the state, and just switch manually when required. If you unpower the keyboard, and power it back on later, and want the non-default layout, just switch. A bit of manual work required, but don’t need to worry about wear at all.
(I’m doing this with my Dvorak/ADORE layouts, so far so good.)
I did the same sort of thing when I switched to QGMLWY, and I have to warn you: it was extremely frustrating. I created three intermediate layouts, moving 6-8 keys with each one. The first intermediate wasn’t so bad, but switching to the second one really messed me up. I found that I couldn’t remember where some keys were in either QWERTY or QGMLWY and I hit a plateau where I wasn’t getting any faster or more accurate in any exercises. I gave up and switched back to QWERTY full time for a couple months, before starting over and going cold turkey. I actually found the cold turkey switch easier to master.
It’s easy enough just to create multiple layers that you can toggle, though, so instead of messing with EEPROM state you could just create a layer stack that allows you to switch to the one you want on any given week or day. Once you’re done with your transition, you can delete the transitional layers. FWIW I have a QWERTY layer that I don’t really use, but it’s the default at startup. I have the prog key set to toggle my QGMLWY base layer on or off. I’ve got color feedback defined in my configuration, so I can see at a glance what layout has been made active. Switching at startup is really, really low cost.
2 Likes
It really seems to me like the idea of doing minimal or gradual changes is misguided. The less similar it is to something familiar, the less confusion my brain has between the two. And if they’re different enough, learning the new input method shouldn’t overwrite the old one.
3 Likes
I’d agree with merlin here. I’ve found that in most instances like this, switching whole heartedly to be the way for myself. Still tempted myself to go full on Dvorak when I get my 01.
I think you might be right. I was just looking at the animated gif from the tarmak site. If I go that way, I’d have to learn 4 different positions for the J key alone! Insanity!
For what it’s worth, I did a cold-turkey switch to Colemak-DH from QWERTY in March of this year. At that time I had looked into the Tarmak route, but passed on it due to the sheer number of intermediaries (5!). At my estimated transition rate of 2 weeks per intermediate layout, I would have finally arrived where I wanted to be in the last week of May.
Instead, I put up with a month of frustration as I learned the new layout (Epistory helps! 
) and two more weeks to get back up to speed; resulting in a shorter total time to transition.
1 Like