alpha
/
Kaleidoscope
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'e72867fe68'
${ noResults }
Kaleidoscope/examples/KeyboardioFirmware/KeyboardioFirmware.ino

67 lines
1.8 KiB
Raw Normal View History Unescape

Separate the keymap layout from the core firmware This moves the layouts to the sketch directory, so that other sketches can easily use a different keymap. In the process, not much had to be changed, and a number of things still remain in the core that assume the default keymap (such as the NUMPAD_KEYMAP thing in LEDControl.cpp), but this is a first step. The downside is that the keymap is no longer static, because that would conflict with the extern declaration, and the NUMPAD_KEYMAP is a byte, instead of a compile-time define. Alltogether, the difference is small enough to be acceptable. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
// -*- mode: c++ -*-
Update copyright year
8 years ago
// Copyright 2016 Keyboardio, inc. <jesse@keyboard.io>
point at license file. remove garbage from top of file
10 years ago
// See "LICENSE" for license details
snapshot, working on perf
10 years ago
#define DEBUG_SERIAL false
initial 'mouse active for cycles'
11 years ago
Rename Model01-MouseKeys to Keyboardio-MouseKeys The mousekeys are not specific to the Model01, name it after Keyboardio instead, as suggested by @obra. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#include "Keyboardio-MouseKeys.h"
Move macros to a separate library Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#include "Keyboardio-Macros.h"
Renamed the .ino and .h, so use that
10 years ago
#include "KeyboardioFirmware.h"
Separate the keymap layout from the core firmware This moves the layouts to the sketch directory, so that other sketches can easily use a different keymap. In the process, not much had to be changed, and a number of things still remain in the core that assume the default keymap (such as the NUMPAD_KEYMAP thing in LEDControl.cpp), but this is a first step. The downside is that the keymap is no longer static, because that would conflict with the extern declaration, and the NUMPAD_KEYMAP is a byte, instead of a compile-time define. Alltogether, the difference is small enough to be acceptable. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#include "generated/keymaps.h"
First pass at extracting key event functions to their own source files
9 years ago
LED-Off: A new "effect" that simply turns LEDs off With the BootAnimation not functioning as a LED effect anymore, ship a dedicated off effect. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#include "LED-Off.h"
Split out LED effects into smaller "plugins" Recreate LEDControl as a class with pluggable parts, similar in vein to the event handler and loop hooks. Except in this case, only the current effect runs at any one time, the current one. All existing effects were separated out into plugins, and the default firmware example was updated too. All of them were pretty trivial, save the special NumLock effect: that one also installs a loop hook, and switches the LED mode if need be. Its setup function also skips to the next effect, if the mode was selected manually. Behaviour should be the same as before, but LED effects are now pluggable, at the cost of some code and data size increase. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#include "LED-SolidColor.h"
#include "LED-Numlock.h"
#include "LED-BreatheEffect.h"
#include "LED-ChaseEffect.h"
#include "LED-RainbowEffect.h"
astyle
9 years ago
uint8_t primary_keymap = 0;
uint8_t temporary_keymap = 0;
First pass at extracting key event functions to their own source files
9 years ago
Separate the keymap layout from the core firmware This moves the layouts to the sketch directory, so that other sketches can easily use a different keymap. In the process, not much had to be changed, and a number of things still remain in the core that assume the default keymap (such as the NUMPAD_KEYMAP thing in LEDControl.cpp), but this is a first step. The downside is that the keymap is no longer static, because that would conflict with the extern declaration, and the NUMPAD_KEYMAP is a byte, instead of a compile-time define. Alltogether, the difference is small enough to be acceptable. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
#define NUMPAD_KEYMAP 2
#define KEYMAP_LIST KEYMAP_QWERTY KEYMAP_GENERIC_FN2 KEYMAP_NUMPAD
const Key keymaps[][ROWS][COLS] PROGMEM = { KEYMAP_LIST };
Split out LED effects into smaller "plugins" Recreate LEDControl as a class with pluggable parts, similar in vein to the event handler and loop hooks. Except in this case, only the current effect runs at any one time, the current one. All existing effects were separated out into plugins, and the default firmware example was updated too. All of them were pretty trivial, save the special NumLock effect: that one also installs a loop hook, and switches the LED mode if need be. Its setup function also skips to the next effect, if the mode was selected manually. Behaviour should be the same as before, but LED effects are now pluggable, at the cost of some code and data size increase. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
static LEDSolidColor solidRed (100, 0, 0);
static LEDSolidColor solidOrange (100, 30, 0);
static LEDSolidColor solidYellow (90, 70, 0);
static LEDSolidColor solidGreen (0, 200, 0);
static LEDSolidColor solidBlue (0, 30, 200);
static LEDSolidColor solidIndigo (0, 0, 200);
static LEDSolidColor solidViolet (100, 0, 120);
static LEDNumlock numLockEffect (NUMPAD_KEYMAP);
Implement a way to do simple macros The main thing here is `Macros_::play`, which takes a list of bytes from PROGMEM, and plays a macro. The array is always a command, followed by arguments, and the size of the argument depends on the command: key presses and releases take a 16-bit argument, and the event is injected into the event handler flow. Waiting and interval change take a 8-bit time. Helpers are provided to make it a little bit easier to construct a macro. Of course, the `macroAction` method may do any other side effects, and is not restricted to returning a sequence of commands. Fixes #5. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
const macro_t *macroAction(uint8_t macroIndex, uint8_t keyState) {
Use an overridable macroAction function for macro actions Instead of hardcoding the macro actions into the core firmware, use a `macroAction` function that is marked weak. This makes it possible to override the function from Sketches, and implement the handlers there. While there, also made sure that the `macroAction` is always called, with `keyState` argument appropriately set. With this, macro actions can trigger on keyup, or while held, or anytime the implementor wants, not just on keypress. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
if (macroIndex == 1 && key_toggled_on(keyState)) {
Serial.print("Keyboard.IO keyboard driver v0.00");
Implement a way to do simple macros The main thing here is `Macros_::play`, which takes a list of bytes from PROGMEM, and plays a macro. The array is always a command, followed by arguments, and the size of the argument depends on the command: key presses and releases take a 16-bit argument, and the event is injected into the event handler flow. Waiting and interval change take a 8-bit time. Helpers are provided to make it a little bit easier to construct a macro. Of course, the `macroAction` method may do any other side effects, and is not restricted to returning a sequence of commands. Fixes #5. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
return MACRO(I(25),
D(LShift), T(M), U(LShift), T(O), T(D), T(E), T(L),
T(Space),
W(100),
T(0), T(1),
END);
Use an overridable macroAction function for macro actions Instead of hardcoding the macro actions into the core firmware, use a `macroAction` function that is marked weak. This makes it possible to override the function from Sketches, and implement the handlers there. While there, also made sure that the `macroAction` is always called, with `keyState` argument appropriately set. With this, macro actions can trigger on keyup, or while held, or anytime the implementor wants, not just on keypress. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
}
Implement a way to do simple macros The main thing here is `Macros_::play`, which takes a list of bytes from PROGMEM, and plays a macro. The array is always a command, followed by arguments, and the size of the argument depends on the command: key presses and releases take a 16-bit argument, and the event is injected into the event handler flow. Waiting and interval change take a 8-bit time. Helpers are provided to make it a little bit easier to construct a macro. Of course, the `macroAction` method may do any other side effects, and is not restricted to returning a sequence of commands. Fixes #5. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
return MACRO_NONE;
Use an overridable macroAction function for macro actions Instead of hardcoding the macro actions into the core firmware, use a `macroAction` function that is marked weak. This makes it possible to override the function from Sketches, and implement the handlers there. While there, also made sure that the `macroAction` is always called, with `keyState` argument appropriately set. With this, macro actions can trigger on keyup, or while held, or anytime the implementor wants, not just on keypress. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
}
astyle
9 years ago
void setup() {
Rework the hook handling We can't register hooks from constructors, because there is no guaranteed order in which the objects will be created. So it may well happen that the Keyboardio object gets created later, and zeroes out everything. Or it gets created first, and registers the default handler as the first one, making all the others pointless. Instead, we create a KeyboardioPlugin class, that has a `begin` method. This is responsible for setting up the hooks and whatnot. To make things simpler (for some values of simple), a `Keyboardio.use` method is introduced, which, when given a NULL-terminated list of plugin object pointers, will call the begin method of each. All LED effects and other plugins that used to register a static object now use an extern, and had their initialization moved to the `begin` method. The end result is not the nicest thing, but it works. We can try figuring out something nicer later. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
Keyboardio.use(&LEDOff,
&solidRed, &solidOrange, &solidYellow, &solidGreen, &solidBlue, &solidIndigo, &solidViolet,
&LEDBreatheEffect, &LEDRainbowEffect, &LEDChaseEffect, &numLockEffect,
&Macros,
&MouseKeys,
NULL);
Introduce a helper macro to compute the keymap size When one adds or removes a layer from a keymap, the keymap size has to be adjusted in the call to `Keyboardio.setup()`. This is easy to forget, so as a helper, introduce `KEYMAP_SIZE`, a macro that automatically computes the size at compile time. This way, one does not need to remember to update the size anywhere. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
Keyboardio.setup(KEYMAP_SIZE);
Rework the hook handling We can't register hooks from constructors, because there is no guaranteed order in which the objects will be created. So it may well happen that the Keyboardio object gets created later, and zeroes out everything. Or it gets created first, and registers the default handler as the first one, making all the others pointless. Instead, we create a KeyboardioPlugin class, that has a `begin` method. This is responsible for setting up the hooks and whatnot. To make things simpler (for some values of simple), a `Keyboardio.use` method is introduced, which, when given a NULL-terminated list of plugin object pointers, will call the begin method of each. All LED effects and other plugins that used to register a static object now use an extern, and had their initialization moved to the `begin` method. The end result is not the nicest thing, but it works. We can try figuring out something nicer later. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
LEDOff.activate();
Initial firmware
11 years ago
}
Add app-specific keyboard support for slack
10 years ago
astyle
9 years ago
void loop() {
Hide the keyboard setup/loop in helpers Primarily so we can use the Keyboardio_ constructor later to initialize things for us. Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
Keyboardio.loop();
Initial firmware
11 years ago
}