deskthority

I have a keyboard project that's sat rather... stagnant for almost a year. The main keyboard is complete, and has been for a year, save for firmware. A sin, I know... The issue is that I'm a hardware guy... The last programming I dis was on a TI-89 calculator, and before that, on the Commodore 128. All I ever knew was BASIC, and even that's been a decade and a half since I even looked at it. I picked up this keyboard project, as well as a project to build a Kerbal Space Program instrument/control panel, to make myself learn C... Only I've not made much progress. Things got busy at work, I got on a roll working on the KSP controller, I got injured at work, then my motherboard died... All in all, a full year has passed since I "finished" my keyboard. It still has no firmware, and though I did finally get the plate to build the number pad, I still have not finished it yet.

My goals are:

A: To initially get a functioning firmware on my main keyboard, so I can ACTUALLY USE IT!
B: To figure out a way to be able to poll/not poll a port expander over I2C, based on the logic level of a "sense" signal.

So, here's my progress so far.

First, I've made up a nice layout worksheet that has all the electrical rows and columns identified not he physical layout. It's top down view, so it'll be useful for defining my key layout too.
So, I did start with the TMK firmware. If it can do everything I need it to do, then I'll stick with it, but there's always the option of re-flashing the keyboard with something else in the future if I can't integrate the hot swappable port expander functionality into the code. The code for my Column and Row pin definitions are below:
I have a VERY dense matrix of 13x7. It was necessary to keep enough I/O pins open for the Caps Lock LED, Backlight LED PWM, a pair of I2C pins, and the numpad sense pin. The sense pin detects if the number pad is attached, and whether or not it should poll the numpad's port expander over I2C. I figure, software is changeable, so I can re-do code later, once I actually have the number pad built, and have half a clue what the heck I'm actually doing.

Anyway, since I had to keep the matrix small, That super dense layout has almost no gaps, and row 6 is actually a tight cluster of keys in the top right corner. An alteration part way in resulted in the very top right key having a completely nonsensical matrix position, because the change was literally a bodge. Only three intersections in the entire matrix go unused (c0-r6, c1-r6, and c12-r4). This means my matrix does not directly conform to the physical key layout in some areas (all of Row 6 is in the top right corner, and the bottom row is "electrically" compressed to the left, and then includes the keys physically in the bottom right corner well).

Now, I'm stumped at my current place in the code...

What have not figured out yet, is whether the matrix definitions need to be ordered by electrical sequence, or if the values are arbitrary, and allow for physical sequence (as long as the row and column values are correctly defined). The obviously functional way is to lay the matrix out electrically. This seems to be what's assumed with most keyboards, as most keyboards physical layout and electrical layout probably match.

My question then is which (either, or both, or neither, or 42 ;D ) would be correct?

Electrically based layout: or...

Physically based layout My question is, are the values entered into the table above dependent on position in the list, or just by content. It'd be FAR easier to follow the second layout, but I don't know if it screws with the code to mix and match rows and columns onto different lines in the list like that, or whether it's all good, as long as the numbers match.

My understanding of the code, is that those lists are not "technically" even different lines... That they are basically one long continuous list, with breaks to make it easier to read. What I don't know is whether the code expects to read the list strictly sequentially, the same way it's scanning the matrix, or whether the code is simply defining the physical layout of the key map and defining what matrix intersection applies to the physical layout. I'm confused!

Basically, is the code:

A: expecting all the rows and columns to be in a neat and orderly incrementing layout (all the columns, in order, 0 to the maximum, for row 0, then repeating for row 1, 2, 3... and so on)

or

B: Is this list arbitrarily defining the row/column intersection values for the (later to be entered) keymap, based on the row and column numbers entered. Basically, saying "I want this layout to have r0-c0 through r0-c12, then r6-c3, r6-c11, r6-c12, and finally r6-c5 in the first physical row of keys"... Basically, so later, when I enter the keymap, it knows that ESC is r0-c0, F1-F12 is r0-c1 through r0-c12, and that F13 is r6c3, F14 is r6-c11, F15 is r6-c12, and the media EJECT key is r6-c5 (using my top row as an example).

Does that make sense?

I suppose I should also add, I know software is flexible, and I can always integrate new features later on. For now, I just wanna get my keyboard up and running. It's been a YEAR! In the long term though, I want to have the code check whether pin E6 changes states. Depending on whether it is high or low, I want to have it scan a 6x6 matrix on a port expander connected over I2C, or to skip the I2C part of the code altogether and ignore that part of the matrix. I don't yet know how I would go about doing this in the code, and I don't even know if this firmware can even be modded to support it at all. Of course, that's the nice thing about software... There's always room for change. I just don't know how.

I think, for the transistor driven under-lighting LEDs in each switch housing, I just want to have a default minimum brightness setting at power up, and the option to change the brightness with the keyboard. I already have the max brightness current limited to stay under the USB max current, but I think at power up it'd be wise to keep total draw under 200 mA, and then let the keyboard negotiate 500 mA if you increase brightness... Again, I imagine it's possible, but I don't know if TMK can do it, or how easy it'd be to mod that functionality in. I just don't want the keyboard to require an external power source to power all the LEDs, nor do I want it to trigger "The USB device is drawing too much power" warnings. It'd be nice if it were possible to cap max brightness based on USB power negotiation. I know devices can request up to 500 mA, but initial connections default to 100 mA (if the devices play friendly with he protocol).

You know... I think for the sakes of getting this thing running, I'm going to select option A, even though layout wise, it's unintuitive. It's intuitive in terms of electrical layout, not physical layout. That's because my electrical matrix kinda jumps around all over the place on the right side of the keyboard, where row 6 and the end of row 5 are all jumbled up into the right two columns.

I guess I KNOW sticking with the electrical layout WOULD work, and I can stick with the electrical layout with the character map as well. I just never got an answer in regards to if a physical layout map would work, or if it'd "confuse' the firmware.

Don't know about TMK but QMK defines keymap as following So it follows how the keyboard is physically wired.

Truth be told... Life, work, etc got busy when I was trying to learn this stuff. This is the first chance I've really had to get back into it. I have a day off this weekend, so it's tempting to just move forward and try. What's the worst that happens... The keyboard remains exactly as it has been for a year?

Quite honestly... A physical map makes keeping track of layouts WAY easier. Another comment elsewhere seems to have also suggested non-sequential matrix positions seemed to work in the lists, also suggesting that physical layouts are possible, not just only electrically accurate layouts. Nice!

It's time to get this thing working. For now, the main keyboard. Later the numberpad.

Currently, I'm only controlling a Caps Lock LED and a single unified backlight PWM. I'm going to have to control the numberpad backlight LEDs separately from the main keyboard's PWM pin. I'd have to control it over I2C. I have some small I2C DAC boards that I think would be ideal to control the numberpad LEDs by just commanding them to a particular level. There will be unused matrix positions on the number pad, so I could potentially use those for control of individual LEDs if I wanted to make indicators on the number pad someday. I have three spare matrix positions on the main keyboard. As of this moment, I'm not planning on using any of those spare matrix positions for anything at all though.

Being able to hot swap the I2C is going to be absolutely necessary for the numberpad to be able to detach and attach. What I really need in the future, I think, is to have the ability to "skip" part of the matrix scan, based on whether the sense signal is high or low. No idea if TMK or QMK or any other firmware has any chance of being able to be modified to make checking a port expander over I2C an optional check, based on a conditional test.

Check the split keyboard code in QMK. It uses two ATMegas so you will have plenty of pins for your leds then.

As for the physical vs. electrical layout thing: That's a main point that you can do with the KEYMAP-macro. You can use it as an abstraction layer between the physical layout and electrical connections. As a side effect it lets you save the "KC_" of the beginning of the keycode defines. Let me try to explain it bottom up:

Basically you need to have as many "KC_NO"s in the second half of the macro as there are gaps in your elecrical wiring matrix. The second half needs to represent your actual electrical wiring matrix.
In the first half, you can kind of "remap" that matrix to what you like to work with, physical layout is certainly a good option.
The KEYMAP-macro translates an easy to comprehend list into an uint16_t keymaps[][MATRIX_ROWS][MATRIX_COLS], which is basically an array of (electrical) matrices.