Compared to the ATmega32U4 in the Model01, the GD32F303 brings us:
- More RAM (2k → 98k)
- More Flash space (32k → 1mb)
- More “EEPROM” space (1k → 16k)
- More powerful MCU (16Mhz → 120Mhz)
- Hardware availability
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.