Hi - my Model 01 came a couple days ago (from Hong Kong to Japan without incident), and I’m just getting started learning what it can do. I’d appreciate some guidance:
Sometimes hardware firmware is some kind of .bin hex file, separated from a settings file. However, the .ino files I’m seeing seem to be both firmware and settings. Is that the case?
In Chrysalis I see that I can load two versions of the firmware - a basic one and a more advanced (the sw might have called it “experimental”) one with more plugins available. With the advanced one loaded, I can see when mapping keys, I can select this or that plugin. However, I’m also seeing that use of many plugins needs code, like you can see with @algernon’s example for TapDance in this thread. Does that mean even though something is available for selection in Chrysalis, that it might not work?
When I make a mapping change in Chrysalis, it appears to be saving in EEPROM. Is that the case? If so, how do I back that up…?
It appears that in layers, keys that are marked as “transparent” are passed through to another layer. What’s the rule: are they being passed to the default, or, to the previous one in the list, i.e. 5 passes to 4, 4 passes to 3?
Also I observed:
At least on macOS, it appears you can’t have the Arduino app and Chrysalis open and working on the same 'board. It causes trouble because it appears one or the other is grabbing the COM port.
The .bin files are the compiled firmware. The .ino file is an Arduino sketch. Think of it as the user-facing aspects of the firmware. It’s where you define your keymap and any plugins you’re using. It’s not the complete firmware, though; it pulls everything else in from Kaleidoscope.h and any plugin-specific headers.
I’m not especially familiar with Chrysalis. I’m 99% sure it saves things in EEPROM. Do note that it’s in alpha right now.
My understanding is that transparent keys pass down to the next active layer (so 5->4->3, not 5->0).
Chrysalis currently offers every possible key, even if the plugin that implements them is not available in the firmware. We currently do not have a way to detect which plugins are enabled and which aren’t, and until we do, Chrysalis will not limit what options it offers.
This can become confusing, and we’ll fix it, but Chrysalis being alpha, we’re not there yet.
Yes, it saves to EEPROM. There’s no easy way to back it up yet. The protocol does offer an eeprom.contents command, with which you can save and restore the full contents of the EEPROM, but Chrysalis does not make this possible yet. We do have a CLI utility (bin/focus-test in the Kaleidoscope sources) that can help with this, but that isn’t very friendly.
This is the case on all operating systems. Chrysalis needs exclusive access to the COM port, because that’s how it communicates with the keyboard. If there’s anything else working on it too, there’s a high chance of data getting lost.
ok, @algernon thanks. I noticed playing with focus-test.sh that my device name is slightly different than what is in the script. Made a github issue.
I enabled the “experimental” firmware in Chrysalis, which appears to be loading colormap, but in the menu there is only layout editor and firmware update. Shouldn’t there be a color related selection. Sorry to be so thick.