GOLEM keyboard project

T.Storm keyboard matrix

Sometimes, a straightforward matrix is not possible. You would run out of pins or you have to save on pins for lighting or rotary encoders. No problem, we have to be creative.

This page is under construction.

Version 1

Looking at the S.Torm's layout, witnout too much thinking, we can see 16 columns and 5 rows. 21 pins? I only had a Pro Micro with 18 pins. Even after utilizing its LED pins I'll have 20.

Version 2

First step to the solution is embracing meandering rows/colums. A matrix row or column doesn't have to be a straight line. The modified matrix below results in 10 colums only. 6 pins saved! 15 pins used altogether. The matrix is more complex but manageable.

Version 3

Can we go even further? Yep, but with the increasing complexity keeping track of the neighbouring switches (while soldering) and maintaining the QMK files is getting harder.

Let's think about it. The layout has 46 keys. A 7x7 would be the most effective, but because of the split design, we need even colums numbers.

6x6 is not enough, 6x8 (14 pins) would work and is the best arrangement for minimizing pins used:

Could we do this? Sure. Will we do this? No way.

Solution

Version 3 uses one pin less than our second approach, but it's much harder to understand, implement and maintain.

Finally, I went with the second version while doing the T.Storm. By utilizing the Pro Micro's LED pins I had enough pins for two rotary encoders and I still have a spare pin for background lighting.

Another idea: port scanning

According to evangs at keebtalk, choosing the pins consciously allows port scanning. What does this mean?

Normally, the firmware scans a keyboard matrix by activating each row (set low) then each column is read and state is updated. So the firmware will loop over each row and then loop over each column.

However,:

...when you read a pin you actually can read all the pins on that port at the same time. So if we put all of our columns on the same port (b0, b1, b2, b3, b4…) we can completely eliminate the inner loop and instead just write the port value to the current row in our state matrix."

This setup is more efficient which is important for wireless applications or situations where we want to run more feature code during each scan cycle.