This is a typedef that defines what type we need to use for storing row states.
Defaults to uint16_t. For boards with 8 columns or less, we can use `uint8_t`,
but the default is 16 bits.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This makes it easier to initialize them in the cpp (shorter too!), and reduces
code size as well. It's also a bit simpler to understand the initialization
part, because it's no different from the props init.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Due to the introduction of MCU properties recently, we need to declare the class
for virtual builds, and can't get away with simply typedefing it to Base.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
When using the A* pinouts, the bootloader should - by default - be Caterina, not
HalfKay, which should only be used for the legacy Teensy2 pinout.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
This drops the now unused `ATMEGA32U4_KEYBOARD`, `ATMEGA32U4_DEVICE_PROPS`,
`ATMEGA_KEYSCANNER_PROPS`, `ATMEGA32U4_DEVICE`, `ATMEGA_KEYSCANNER_PROPS`, and
`ATMEGA_KEYSCANNER_BOILERPLATE` macros.
These were macros that made the code less verbose, but none of them were
future-proof, and all of them were pretty opaque. Using them did not help one to
understand the code.
All use of these have been changed to use the raw structures as-is, which is
more verbose, but much more extensible, and a whole lot clearer in intent
aswell.
Since these are not particularly user facing macros, I opted not to include them
in `UPGRADING.md`, and removed them without prior deprecation.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using opaque macros which aren't even extensible, just expand them,
and use the raw data structures for the hardware definition. While this is more
verbose than the macros, it is more future proof, and clearer for the reader
too, because they don't need to understand the magic macros.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using opaque macros which aren't even extensible, just expand them,
and use the raw data structures for the hardware definition. While this is more
verbose than the macros, it is more future proof, and clearer for the reader
too, because they don't need to understand the magic macros.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using opaque macros which aren't even extensible, just expand them,
and use the raw data structures for the hardware definition. While this is more
verbose than the macros, it is more future proof, and clearer for the reader
too, because they don't need to understand the magic macros.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using opaque macros which aren't even extensible, just expand them,
and use the raw data structures for the hardware definition. While this is more
verbose than the macros, it is more future proof, and clearer for the reader
too, because they don't need to understand the magic macros.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Instead of using opaque macros which aren't even extensible, just expand them,
and use the raw data structures for the hardware definition. While this is more
verbose than the macros, it is more future proof, and clearer for the reader
too, because they don't need to understand the magic macros.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
While the code became shorter with the previous commit, it did not become much
easier to understand and follow. Some of the choices made weren't self
explanatory. For that reason, lets put comments around the relevant parts, that
explain why we've done it that way.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The `kaleidoscope::Device` aliases are there for use-cases that need to be
device agnostic, we do not need to use them in the hardware plugin itself,
because that plugin _is_ very much tied to the device. We can just use the
device specific original names.
To make things shorter, we can also set up a pair of aliases for
`KeyScannerProps` and `KeyScanner`, to make the declarations even shorter.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
With this, it is possible to set the time (in milliseconds) between scans. The
aim is to make it possible to change this setting in one's `setup()` in their
own sketch.
One can do that as follows:
`Kaleidoscope.device().keyscanner().setScanCycleTime(2000);`
This is currently only implemented for the ATmega keyscanner.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We use 100kHZ for flashing, because that's more reliable. Use the same for
normal operation, for similar reasons. This appears to fix a frequent crash
issue.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
If LEDControl is used without any LEDMode plugin, `cur_led_mode_` is
an unitialized pointer. This initializes it to `nullptr` and guards
against accessing it.
Signed-off-by: Johannes Becker <alfalfasprossen@gmail.com>
This has been deprecated in March, 2019, has been a no-op since. While no
removal schedule was posted at the time, I believe it is safe to drop it now.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Originally scheduled for removal by mid-March. This also removes the similarly
deprecated named hardware object aliases.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Handling of the respective keys is moved to `beforeReportingState`
as the state of shift is only then available. Usage together with
OneShot requires OneShot to be initialized before LEDControl.
Signed-off-by: Johannes Becker <alfalfasprossen@gmail.com>
This introduces MCU properties, so that MCU drivers can change their behaviour
and/or setup tasks based on them, without having to write a `setup()` method or
a custom constructor for the top-level device.
In practice, this allows us to tell the MCU driver to - for example - disable
JTAG or clock division during setup, and thus, we won't need to do that in code
in the device constructor.
This is a breaking change, kind of, because the `mcu::Base` and
`mcu::ATmega32U4` drivers changed APIs. However, no device was using those
directly, only via `ATmega32U4Keyboard`, and those parts remain compatible.
While there, updated the `KBD4x` and `Splitography` devices to use the new
properties instead of a custom constructor.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Gergely Nagy
Jesse Vincent
Gergely Nagy
Johannes Becker
Christopher S. Corley