Single-byte key addressing (for boards with fewer than 256 keys)

[noseglasses]

@buc

I was referring primarily to the 15 years it took from the start of the design discussions to the “1.0” release.

That must be a hell of a language now.

[merlin (Michael Richters)]

@noseglasses

But seriously. A port to another keyboard would not require touching the code of KeyAddr. That’s an important aspect of portability. The only thing that needs to be done, concerning the KeyAddr class, is to define other values for the macros

KALEIDOSCOPE_MATRIX_ACCESS_TYPE
KALEIDOSCOPE_KEY_ADDR_STORAGE_TYPE
KALEIDOSCOPE_KEYBOARD_ROW_SIZE

in a hardware/platform specific type definition header.

Not true if there are holes in the key matrix, which I believe @algernon said is true of the Shortcut.

@noseglasses

If it was true what you say then the whole STL has ‘gone off the rails’.

Based on my experience dealing with it for the past month or so, I’d say it’s not the STL (which isn’t even available to Arduino, apparently) – it’s the whole language that’s gone off the rails. You cannot imagine how much I hate C++ right now.

[merlin (Michael Richters)]

@algernon

We can. The hard part with a Planck port is the Teensy, because that needs a different HID library, as far as I remember. There has been same work on that front before, and I plan to revisit that soon for various reasons. Once we make it easier to use different HID libraries, and dispatch events between them, a whole lot of things get easier. Including porting to Teensy-based platforms. Once that code is in, the Planck port should be doable in an afternoon.

Can you explain the difference between the hardware on a Planck (and/or Preonic) and the Model01? I’ve looked it up (or tried to) a few times, and all I can remember is that sometimes I look it up and it’s the same, and other times it’s different.

[noseglasses]

@merlin

Not true if there are holes in the key matrix, which I believe @algernon said is true of the Shortcut.

Does holes mean that there are unused entries in the keymap matrix?

[noseglasses]

@merlin

You cannot imagine how much I hate C++ right now.

Sorry to hear that. Can I do anything to reduce your hatred towards C++? Explanations, links, etc.

[algernon (Gergely Nagy)]

@noseglasses

Does holes mean that there are unused entries in the keymap matrix?

Yep:

Dygmalab/Kaleidoscope-Hardware-Shortcut/blob/15cfd545b18d370d39aee723035df1af32abf078/src/Kaleidoscope-Hardware-Shortcut.h#L91-L96

All those XXX stuff, those are positions that are not wired anywhere.

[noseglasses]

@merlin

Not true if there are holes in the key matrix, which I believe @algernon said is true of the Shortcut.

There are unused positions in the keymap. But when itetrating over the keymap, those holes could probably be ignored. It would in any case not pay off to stop and restart an iteration over the keymap because of five unused elements (shortcut).
In any case this would require no changes in the key addressing implementation.

[buc]

@merlin

Not true if there are holes in the key matrix, which I believe @algernon said is true of the Shortcut.

Wouldn’t it only be a problem if (ROWS * COLUMNS) >= 256 but the number of total keys is still less than 256?

[merlin (Michael Richters)]

@buc

Wouldn’t it only be a problem if (ROWS * COLUMNS) >= 256 but the number of total keys is still less than 256?

I would write a hardware module for any keyboard that simply assigned a number to each keyswitch in series, so the following test guaratees that it addresses a valid key:

if (key_addr < TOTAL_KEYS) { ... }

I would not want to expose ROWS and COLS to the rest of Kaleidoscope at all. From the top level, I’d still want the user to be able to refer to keys using some sort of coordinate system (with a compile-time translation), but that would probably only be the same as the hardware’s row and column wiring on keyboards like OLKB ones. I personally find the R#C# coordinates on the Model01 difficult to remember; past the sixth column, and I can never get any of them right. I see six rows on each half of the Model01, not four, and not all of them have the same number of keys. And tab is in the second row (I had to look it up) next to T, but it clearly ought to be next to G in the third row…

[merlin (Michael Richters)]

@noseglasses

Sorry to hear that. Can I do anything to reduce your hatred towards C++? Explanations, links, etc.

Alas, the more I learn, the more I despise it. Being unable to do conceptually simple things because of lack of familiarity is mildly frustrating and time-consuming, but the real loathing comes when I learn the solution.

[noseglasses]

@noseglasses

There is no extra overhead. The class could have (inline) getters and setters for row and column values, which would encapsule the bit manipulations. You probably couldn’t distinguish both implementations in the assembly code.

See also

Do accessors increase PROGMEM consumption?

There were discussions about the benefits of accessor functions [1], [2], [3]. Apart from religious aspects of the discussion, the statement that accessors cause runtime costs appeared quite often. This is something that is hard to get out of the heads of programmers coming from other languages that do not feature function inlining, C programmers included. But C++ has its own rules. Inline functions can actually disappear from the assembly and thus from our precious PROGMEM. C++'s inline keywo…