This is something I’ve been wondering ever since I saw QMK pushing the Proton C controller. My 01 has a handful of plugins installed, and I never was memory-constrained. However, I’m willing to believe I’m not creative enough to consider all the possibilities a more powerful controller brings.
Aside from loading even more plugins, what does it enable that couldn’t be done on the Model 01?
Compared to the ATmega32U4 in the Model01, the GD32F303 brings us:
The last part is crucial, you can’t build a keyboard if you can’t source its MCU. As far as I remember - but @jesse will correct me if I’m wrong - the former ATmega32U4 chips just weren’t available. (See here and the “Production status” part of the campaign.)
But availability aside, the most noticable thing for most people will be the vastly increased EEPROM size. That makes a whole lot of things that weren’t doable before, possible. It lets us have much more room for experimentation. The increased flash size is noticeable too: one can easily enable and play with a whole lot of plugins all at the same time.
For example, the default Model01 firmware was fairly tightly packed, both flash storage and EEPROM wise. Compiling the Model01 factory firmware with current Kaleidoscope will occupy well over 90% of flash, and will leave about 172 bytes of EEPROM free.
If we want to add dynamic macros, 172 bytes at most for macros is enough to get a feel for it, but it’s very, very tight. Even though we designed the macros to be space efficient, and Chrysalis tries its best to keep them small too, they do have a noticeable overhead when it comes to storing them.
If we want to have the firmware come with an initial colormap, with the Model01, we can’t do that, not without disabling half the plugins in the default firmware, because there’s just not enough flash left. With the Model100, we will be able supply a default colormap (we don’t yet, but the plugin to help achieve that is there, we just need to come up with sensible defaults).
We can also increase the number of layers, both in flash, and in EEPROM.
We’ll be able to have even more plugins that support storing their configuration in EEPROM, because, well, we’ll have plenty of space available! With the AVR MCUs, we could do that, but we would have had to make very hard choices about which plugins to enable this feature for. With the Model100 and the GD32, we don’t. We can enable them all, there’s plenty of space.
You want to name your layers, so that Chrysalis would show “GAMING”, “NUMPAD”, or whatever other name you come up with? That takes EEPROM space, and 1k was feeling far too small to even consider such a feature. With 16k, we can fit custom layer names in. We can fit custom macro names in, too. Those plugins do not exist yet, but they will. They wouldn’t be practically usable on the Model01, they’re a small drop in the ocean on the Model100.
Even though we’ve always been conscious about space restrictions while developing Kaleidoscope, as it matured, as it kept being improved, it did grow a bit in size. That didn’t hit most users, but it was a question of time when it would, especially if we wanted to enable more plugins in the default firmware, without removing any others (we don’t like to remove things people may have gotten used to).
Stuff like Dynamic Macros, or a colormap shipped with the firmware - those were stretching the AVR limitations hard. For example, just recently, we merged the default and experimental firmwares for Chrysalis, to reduce maintenance costs, and provide a smoother, less confusing experience (the number of times we’ve been asked why certain features Chrysalis shows don’t work is uncomfortably high). We wanted to enable Qukeys and Dynamic Macros, because the former is an often used feature, and the latter is simply interesting. To do so, we had to disable two LED plugins (AlphaSquare & Stalker), because we would have ran out of space otherwise. We could only reserve 128 bytes of space for dynamic macros too - enough to try them, not enough to make good use of the feature.
In short, the former MCU was very limiting. Perhaps less so for current uses, but for future use cases, future plugins, and plans - quite so.
As another example, I know I’m one of the very few people who drove it to its limits, but for the past ~3 years, I was unable to compile my own sketch without disabling the boot keyboard part of Kaleidoscope, simply because I ran out of space, and there were no other features I could remove without serious consequences. Consequences like not being able to work, because I grew so dependent on my sketch that working with reduced features plummets my performance deep underground.
Even with the bootkeyboard disabled, I was unable to have a keymap in progmem, because there wasn’t enough space. As of this writing, with no keymap in progmem, and bootkeyboard disabled, my Model01 firmware uses 98% of available progmem space, leaving only 518 bytes free. That’s tiny, and I already removed a number of lesser used features to even fit.
Thanks for the thorough reply! It sounds like, even for people who aren’t absolute power-users, there are some benefits, which is cool. (I’ve always been a little cynical when certain other manufacturers, like Razer, boasted about the power of their keyboard controllers.) I always wished dynamic macros were more robust, so color me excited.
This is the first I’ve heard about this upgrade, but it also occurs to me that more “assistive” options become feasible with the extra storage - e.g., it looks like the main “dict.json” from plover’s dictionaries are about 4 MB of JSON, and gzip down to 877K. That suggests to me that with clever encoding (or possibly just pruning out some infrequent/redundant keystrokes), it’s likely possible to fit a full steno dictionary into the keyboard.
I’m not sure how useful it would be, but it would be cool to be able to type in steno without requiring any software on the client. And that’s just not going to be possible without at least several hundred kilobytes to store the dictionary (and honestly, 1MB is probably still a stretch, but 2-4 MB should make it very doable.
I don’t think a full Plover dictionary is practical to put on the keyboard. We have 1Mb space for firmware and data and everything. Compressing it isn’t feasible either, because the keyboard doesn’t have enough memory to hold the uncompressed dictionary in RAM, and without that, every lookup would need to uncompress the dictionary, which would make it unusably slow.
A smaller dictionary, however, would be possible, but I’d still just use host-side Steno software. That’s more flexible.