Hi there, I just got my PVT Model 1 working, and am already flashing it with new firmware and having a wonderful time playing with it! (My fork of the model01 firmware is at https://github.com/antifuchs/Model01-Firmware if you’re interested.)
Now that I’ve found a color scheme that I like (yay for solid orange!), I’d like it to be active and the default right after boot. What invocations do I need for that? Does that go in the setup function?
Yes, it goes into setup(), and the following line should do the trick:
solidOrange.activate();
That did it, thank you!!
Also, @algernon - I just now recognized your name from wayyyy back in the 2000s. Great to see you again in this community (:
Just as a note: The reason we’re leaving LEDs off by default is that some devices, such as iOS devices, get really, really cranky if your keyboard draws more than 100mA. Longer-term, we have some ideas about how to auto-negotiate power draw and disable or limit LEDs in software on such hardware, but we just wanted to be careful
Ah! That’s good to know - I guess I could use the OS detection plugin to prevent LEDs turning on when connected to anything other than a macos machine (if mobile devices don’t identify as macos) (:
I was pleasantly surprised to see how easy it is to set the default lighting mode.
LEDRainbowWaveEffect.activate(); // FTW! 
But hopefully soon I can change that to LEDWaterEffect.activate() instead. I want light to splash out from each keypress. 
(and gentle raindrops can provide an idle animation when no keys have been pressed for a while)
This sounds like a fantastic plugin. I’d happily offer hints and pointers to help develop it 
iOS and MacOS are two of the hardest to tell apart, since they share a USB stack.
What we should be doing is a more advanced USB power negotiation and just disabling the LEDs if the host refuses to give us more than 100mA.
That said, for a personal device, there’s no reason to default to the LEDs being off. It’s just a safer choice for the ‘standard’ firmware.
The other thing to do is to track the last LED mode in EEPROM, so it picks up from where it left off.
As a similar question, do the LEDs have an inactivity timeout? Basically, if you don’t type anything for x minutes, do the LEDs turn off?
Not out of the box, though that’d be a neat plugin.
I was a little surprised it didn’t already do this. I’m not sure what all currently goes into eeprom, but anything which can be configured directly on the keyboard itself probably should be remembered that way.
One thing to keep in mind is that we want to limit the number of write cycles to the EEPROM as it can wear out.
One of the reasons we don’t store the LED mode in EEPROM is that the EEPROM plugins are a bit experimental. As in, I have been using them for a good while, but I’m still unsure about the API. For the curious, start at the Kaleidoscope-EEPROM-Settings plugin.
Modifying LEDControl to save the mode into EEPROM would be a reasonably easy thing to do. If anyone feels like they want to do it, let me know, and I will happily provide pointers, hints, and whatever you may need. I could do it too, and would be happy to do so, but I’d rather let one of you unlock the “Added a feature to a Kaleidoscope plugin” achievement
One downside of this though, is this would pretty much make LEDControl depend on the EEPROM-Settings plugin. Not to mention, one may not want the keyboard to remember the last mode, but prefer it to boot up with the default mode. There are a few ways to accomplish this, and still be able to store the mode in EEPROM: don’t restore the mode on boot, but provide a method that does. Those who want the feature can call this method in their setup() function, those who don’t, won’t.
Right… This complicates things further, as we can’t just update the EEPROM on every LED mode change. Perhaps a LEDControl.saveMode() would help? And the user can call that whenever they want: from a macro, from loop() (it would use EEPROM.update() which checks the previous value, and doesn’t write if it didn’t change), or something along these lines.
In the keyboard’s entire life span, how many times will the change-LED-mode function be activated?
The eeprom is rated for a minimum of 100,000 erase-write cycles per cell, though in actual testing these atmel chips tend to get about a hundred times that before actual failures tend to start. If someone changes the LED mode 20 times per day, every day, that works out to somewhere between 13 and 1300 years before failure. That could still be risky though, for a device designed with longevity in mind. So there are ways to increase that – wear-levelling is one simple option, or delayed writes which don’t happen until the mode has been set for several seconds. Either one should increase the longevity by at least an order of magnitude.
How much of the eeprom is currently used?
Typically, I split eeprom into two sections – one for settings which change frequently and one for settings which usually stay the same. The frequently-changed ones use wear-levelling while the others have a fixed position in eeprom. It seems to work well, as long as there is enough space for both. I usually only have a few bytes worth of configuration, so it’s fine even on attiny13 with only 64 bytes of eeprom. But a keyboard might have a lot more settings…
That’s a pretty good reason. 
I wonder how many people will actually reflash the firmware. I did, but I may not be typical. I would assume that anything not in the default firmware will only be touched by a minority of users unless reflashing is built into a setup wizard tool or something.
The EEPROM is used as much as you configure it. The factory firmware does not use it at all, as far as I remember. There are a few plugins which make use of it (HostOS, EEPROM-Keymap, Colormap, FingerPainter, LED-Palette-Theme), each of those to various degrees. HostOS uses a byte or two, LED-Palette-Theme uses 48 bytes (a 16 color palette of three-byte colors), Colormap uses ROWS * COLS / 2 bytes per layer, FingerPainter uses ROWS * COLS / 2 (only uses a single layer), while EEPROM-Keymap uses ROWS * COLS * 2 per layer.
My current sketch uses 1016 bytes out of 1024, because I have most of my keymap and LED colormaps there. As you see, EEPROM use can vary a lot, depending on what plugins you use, how many layers you have, and so on.
The EEPROM-Settings plugin also uses a few bytes (four or so, maybe?) for some bookeeping things.
The EEPROM-Settings plugin divides EEPROM up between the other plugins that use it, so everything will have a fixed-size area. Most of the settings are indeed small, but keymaps and colormaps take up considerably more space.
I think the idea is that most people will reflash their keyboards at least a few times. We are working on a tool (Chrysalis) that will help with reflashing too, among other things. It may not compile the firmware for you, but it will help with anything else. And firmware compilation may find its way into it too, at some point. Flashing is already there, mind you.
One of my goals with Chrysalis is to guide the user through the whole process, so they can easily and confidently customise their keyboards. If I have to build a “First time user’s guide” into it, that walks them through the process, I will. Actually, that’s a brilliant idea, and I’ll add it to the roadmap right now. Thanks! 