keyboardio / kaleidoscope-bundle-keyboardio Goto Github PK

The files HID.h and HID.cpp are redundantly defined in library HID and KeyboardioHID.
Diffing them shoes that both are almost identical. Is there a particular reason for this redundancy or could the HID library possibly be removed from the bundle?

With #15 it is now possible to get an error from avr-ar when building. I can reproduce this reliably on mac OS with Arduino 1.8.8 (I don't want to risk upgrading to 1.8.9 until someone else can reproduce the problem). This happens when adding or removing an unused class variable in a header file (and probably in other cases).

Here's how I was able to reproduce the problem:

1. Make a fresh clone of Kaleidoscope-Bundle-Keyboardio
2. Remove the temporary build dir: rm -rf $TMPDIR/kaleidoscope-$USER
3. Build the Model01-Firmware sketch
4. Add a private variable to class Kaleidoscope_ in Kaleidoscope.h: static uint8_t dummy_;
5. Build Kaleidoscope again

Surprisingly, the second build fails with a "Malformed archive" error from avr-ar:

[merlin@brunelleschi:~/test/keyboardio/avr/libraries/Model01-Firmware] 2019-05-26 04:37
$ BOARD_HARDWARE_PATH=../../../.. make
BOARD_HARDWARE_PATH="../../../.." ../../../../keyboardio/avr/libraries/Kaleidoscope/bin//kaleidoscope-builder build-all
Building ./Model01-Firmware 0.0.0 into /var/folders/5j/1cp97c6d49v5xwhfqsfkn5w80000gn/T//kaleidoscope-merlin/sketch/12908385099-Model01-Firmware.ino/output...
- Size: firmware/Model01-Firmware/Model01-Firmware-0.0.0.elf
  - Program:   26060 bytes (90.9% Full)
  - Data:       1343 bytes (52.5% Full)

[merlin@brunelleschi:~/test/keyboardio/avr/libraries/Model01-Firmware] 2019-05-26 04:38
$ BOARD_HARDWARE_PATH=../../../.. make
BOARD_HARDWARE_PATH="../../../.." ../../../../keyboardio/avr/libraries/Kaleidoscope/bin//kaleidoscope-builder build-all
Building ./Model01-Firmware 0.0.0 into /var/folders/5j/1cp97c6d49v5xwhfqsfkn5w80000gn/T//kaleidoscope-merlin/sketch/12908385099-Model01-Firmware.ino/output...
/var/folders/5j/1cp97c6d49v5xwhfqsfkn5w80000gn/T//kaleidoscope-merlin/ccache/bin//avr-ar: /var/folders/5j/1cp97c6d49v5xwhfqsfkn5w80000gn/T//kaleidoscope-merlin/sketch/12908385099-Model01-Firmware.ino/build/Model01-Firmware.ino_joined.a: Malformed archive
exit status 1
make: *** [build-all] Error 1

We recently merged KeyboardioScanner into Kaleidoscope itself, making the inclusion of it in the bundle unnecessary. We should remove it from the bundle in a few months time.

Both are set to 2303, which throws off the labeling in Arduino.

The buildtools symlink in the avr/ directory is not handled as a symlink in Windows, but just as a random file. A quick google search says we're unlikely to be able to create a symlink compatible with all major platforms, but we can at least document how to manually solve it as part of the cloning process.

There's an issue somewhere with the test scripts, because they exit with zero even if the tests fail, see here for example: it's green, despite tests failing badly:

Ran tests:          33
Total failures:     0
3rd party failures: 12
 fail

Something's very unhappy here.

Travis tests currently fail.

I've managed to reproduce a minimal test case locally, even backing down to Arduino 1.8.7.

@algernon can you see if this makes sense to you? I feel like we're either missing a path or a definition in a file somewhere...

 jesse   master  …  keyboardio  kaleidoscope  Kaleidoscope-Bundle-Keyboardio  arduino-1.8.7/arduino-builder -compile -hardware pwd/hardware/ -tools pwd/arduino-1.8.7/hardware/tools -tools pwd/arduino-1.8.7/tools-builder -fqbn keyboardio:avr:model01 -libraries . -libraries pwd/hardware/keyboardio/avr/libraries/Kaleidoscope -libraries pwd/hardware/.. -libraries pwd/avr/libraries/Kaleidoscope/../current-libraries -ide-version 10607 -built-in-libraries pwd/arduino-1.8.7/libraries -warnings all avr/libraries/Kaleidoscope/examples/Basic/Basic.ino
Platform avr (package keyboardio) is unknown

Hi! I've made some custom hardware to drive the Tardis keyboard. I was expecting to have to write the firmware from scratch, but Kaleidoscope has 90% of what I need, plus a ton of extra stuff, and the code is so well structured that it's pretty easy to write the code to support my hardware. But there are a few issues:

1. The Tardis keyboard hardware has support for 251 keys, but only 244 switches are installed. Electronically, they are organized into 8 rows and 32 columns. This violates the assumption of MatrixAddr that every address corresponds to a key, i.e. that rows*columns = number of keys. The simplest fix breaks the static assert, making the code less safe.
2. My implementation of the key matrix scanner is very different from Kaleidoscope's assumption that rows&columns correspond to GPIO pins. I would need 40 pins just for the key matrix! Instead I bit-bang control data to six (!!) daisy chained shift registers via SPI.
3. The shift registers not only control the key matrix scanner but also the LEDs, which does not seem to be the assumption of Kaleidoscope. I can provide a separate interface to the LEDs and scanner, but they will ultimately be coupled. One consequence: the scanner frequency is an integer multiple of the LED frequency or vice versa.
4. There are 148 LEDs, all of which are monochrome red, which can function as indicators on windowed keys, e.g. caps lock, or can be used for custom purposes. I can achieve a very fast SPI frequency, which allows me to vary the brightness of the LEDs by PWM. This doesn't fit the LED model of Kaleidoscope. One solution is to treat any nonzero color vector as "on" and zero as "off." Alternatively, I could convert to grayscale, varying the brightness according to value (in the HSV sense of the word).
5. I'm using the "Blue Pill," which has an ARM Cortex-M3 based microcontroller, not AVR. But it appears the vast majority of Kaleidoscope is MCU agnostic. It's not clear to me where the dependencies are that make Kaleidoscope for AVR MCUs.
6. You guys seem to be on the verge of a dramatic hardware API change, and it's not clear when and on which branch I should write a new hardware implementation.
7. How do I set up the build environment? This is very mysterious. Most of the build scripts appear to assume the device is the Model 01. There are bits and pieces of build-related stuff all over the place. It's not clear how everything fits together.

The code base itself is pretty easy to understand, so I could just copy the Kaleidoscope code that's relevant to my project, make all the changes I want, and be done with it. But I think my code would be more useful if myself and other people could use it as part of a feature rich, actively maintained framework. And there may be some value to potential future developers in having an example of a device implementation for which the off-the-shelf classes can't be used.

Do you have any recommendations?