|
|
|
|
// Copyright 2016 Keyboardio, inc. <jesse@keyboard.io>
|
|
|
|
|
// See "LICENSE" for license details
|
|
|
|
|
|
|
|
|
|
#define DEBUG_SERIAL false
|
|
|
|
|
|
|
|
|
|
#include "KeyboardioFirmware.h"
|
|
|
|
|
#include "KeyboardioHID.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
uint8_t primary_keymap = 0;
|
|
|
|
|
uint8_t temporary_keymap = 0;
|
|
|
|
|
|
key_events: A way to hook into the event handling
This adds a new `handle_user_key_event` function, that will get called
before anything else, and can override what happens. If it returns true,
the event will not be processed further by the firmware. By default,
this function returns false, and is a no-op.
It is defined with a `weak` attribute, to let the linker know that any
other function with the same name should override his one. This makes it
possible to have another version of this function in a firmware Sketch,
and override the behaviour, to extend the event handling.
This is the foundation that allows it to use external libraries, and tap
into the firmware's event handler, to add new stuff. (We can already
hook into the main loop by changing the top `loop` function in the
Sketch)
This addresses #21 for the most part.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
8 years ago
|
|
|
bool handle_user_key_event(byte row, byte col, uint8_t currentState, uint8_t previousState) {
|
|
|
|
|
//Serial.print ("user_key_event");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void setup() {
|
|
|
|
|
wdt_disable();
|
|
|
|
|
delay(100);
|
|
|
|
|
Keyboard.begin();
|
|
|
|
|
Mouse.begin();
|
|
|
|
|
AbsoluteMouse.begin();
|
|
|
|
|
KeyboardHardware.setup();
|
|
|
|
|
LEDControl.boot_animation();
|
|
|
|
|
|
|
|
|
|
temporary_keymap = primary_keymap = Storage.load_primary_keymap(KEYMAPS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void loop() {
|
|
|
|
|
KeyboardHardware.scan_matrix();
|
HACK: Invert the order of "write to i2c" and "read from i2c"
HACK: Invert the order of "write to i2c" and "read from i2c" because we're
seeing a weird phantom issue where after writing LED data to the ATTiny,
and reading immediately, we get back its own address, a 0 byte and then
garbage
I2C,Setup Read to [0xB1] + ACK
I2C,0xB1 + ACK
I2C,0x00 + ACK
I2C,0xFF + ACK
I2C,0xFF + ACK
I2C,0xFF + NAK
It appears that this has ~nothing to do with the ATTiny's firmware,
but I've been wrong before
9 years ago
|
|
|
LEDControl.update(temporary_keymap);
|
|
|
|
|
Keyboard.sendReport();
|
|
|
|
|
Keyboard.releaseAll();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
