The ErgoDox typically uses a Teensy, and the Atreus has the option to as well.
In both cases, the flashing procedure (whether through the IDE or CLI) will
require the `teensy_loader_cli` tool installed.
Fixes#479.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
* Uses usbconfig to determine the Model 01's USB modem port.
* Works around incompatibe avrsize flags.
You need to be able to run usbconfig to flash the firmware from the
buildtools. This can be accomplished with appropriate groups and devfs
rules.
Requires gmake, perl, avrdude, and (probably) arduino18 from ports.
The version of avrdude in ports uses an avr-size command that doesn't
understand the -C or --mcu flags. From what I can tell, these flags
are uneccessary, as the size computed with them is the same as what
you get from adding up the appropriate segments from the standard
output of avr-size without any flags. However, since the size is only
informative, I've opted to simply check to see if the command
succeeded, and if not, output a string saying it could not be.
It would probably be better to:
* Determine appropriate flags based on build tools, or,
* Just not use the flags at all, and grab the .text, etc., segment
sizes from the standard output and add them up via `dc` for
display.
I've been using this toolchain to build successfully on FreeBSD 12 for
the Model 01 without issue. It should work with earlier versions of
FreeBSD as well.
Signed-off-by: Brian Cully <bjc@kublai.com>
Make it possible to use the plugin for all known Atreus variants: the post-2016
PCB with A* and the FalbaTech handwired one with a Teensy (these two were the
only supported ones until now), the pre-2016 PCB with A*, and the legacy Teensy2
variant.
Fixes#430.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The pin list (and consequently the key layout list) was rearranged in the early
days of the plugin for more optimal scanning code. With -O3 and moving to
`ATMegaKeyboard`, that optimization is no longer relevant. This restores the pin
list and the layout to its original order, the order at which the hardware is
laid out.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Introduce a couple of helper methods that make it easier to work with Focus.
These abstract away the dependency on Serial as a side-effect. The intent is
that all traffic will go through Focus.
Fixes#476.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When merging into the monorepo, all documentation links were updated to point at
the new documentation locations. Even those where the plugin wasn't merged, such
as `Focus` (`FocusSerial` was). Restore the link, so it points where it needs to.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Improved the ATMega parts of row toggling, similar to how `ATMegaKeyboard` does
it, and separated it from selecting extender rows. This results in a tiny
increase in speed, and better clarity.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of only reporting the state when the timer triggers, report it every
loop, even if it is unchanged.
This is based on a similar change to `ATMegaKeyboard`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Set the previous key state when reporting the state to Kaleidoscope, instead of
on every read. This eliminates a possible chatter bug. Idea taken from a similar
change made to `ATMegaKeyboard`.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Based on the change made to `ATMegaKeyboard`, apply the same treatment to the
`ErgoDoxScanner` too, and run debouncing only 3 times per 5ms, which is closer
to what switch manufacturers recommend.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
For better organisation, we're putting examples in subdirectories of
`examples/`. The builder should support that.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Keys normally only change when switching layers, so instead of going through
every key in every cycle to look for modifiers, do that once, when layers
change (using the new `onLayerChange` event), and store the coordinates of keys
we consider modifiers in an array (currently limited to 16 items).
Then, when we want to highlight them, go over this array only, significantly
reducing the work we need to do. In a typical case, on a full-size keyboard, one
would have eight modifiers and a few layer keys, so instead of going through a
hundred keys, we go through sixteen at most, but usually considerably less.
This fixes#403, at the cost of noticeably higher PROGMEM and RAM use.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of tracking layer changes ourselves, use the new `onLayerChange` event
to do that for us. This makes the code a tiny bit easier to follow.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The intent is to make it easier for plugins to detect layer changes and schedule
work accordingly. There event receives no arguments, the current state can
always be queried with `Layer.getLayerState()`, and if a plugin requires the old
state too, they can track that on their own.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If we wish to support hardware that has LEDs, we should not define the `cRGB`
struct and the `CRGB` macro unconditionally. Define them only if the macro is
undefined. This way any hardware that has LEDs, and still wishes to use
`ATMegaKeyboard` as a base can define the macro prior to including the header.
Such hardware will override the LED functions anyway, so there's nothing else we
need to do to support such a scenario.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We already support bootloaders that have the same vendor ID as the keyboard, but
a different product ID. We should also support bootloaders that have a different
vendor ID too.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Sometimes we'd like to be in control of when reports are sent during macro
playback. This implements a way to achieve that.
Fixes#368.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of guarding the ATMegaKeyboard files with an `#if` that hard-coded which
keyboards are based on the class, guard them with
`KALEIDOSCOPE_WITH_ATMEGA_KEYBOARD`, set by the main hardware headers. Those
headers get included early, and are as such, a perfect way to guard these
things.
This way if we add a new keyboard using the base class, we don't have to modify
the base class itself, and the new hardware plugin can be entirely self-contained.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Gergely Nagy
Gergely Nagy
Brian Cully
Jesse Vincent
Jesse Vincent