Teensy wiring

[iceman358]

Hello there everybody, this is my first post here.

I decided to create my first mechanical keyboard. However I made the mistake of not accounting for the I/O pins on the Teensy. I have built a keyboard with 108 keys (104 plus 2 media) and I have a Teensy 2.0 which as I understand has 25 I/O pins. If I create a matrix as I have seen on the internet and here, I will end up with 20 columns and 6 rows, which counts for 26 pins.

Could I create a matrix per two columns so I would end up with 10 columns and 12 rows, ending up using 22 pins?
Is there a maximum of supported keys per I/O pin of the Teensy?

Thanks in advance.

[flabbergast]

You can create any matrix you like, 10x12 is definitely OK. Just mind the diodes
There's no "limit" on the number of keys per pin
BTW: 10x12 will also leave 3 pins for the LEDs

[iceman358]

Wow, that was quick.

When you say to mind the diodes you mean that they should connect every two columns and not sequencially?

[Muirium]

One diode for every switch. They hook up like this:

http://deskthority.net/workshop-f7/brow ... t6050.html

A square matrix is the most efficient.

[OleVoip]

A square matrix is the most efficient.

This is rarely true. For 108 keys, the minimum number of port pins required for the matrix is 22.
There is a choice of four matrices with 22 pins: 11x11, 12x10, 13x9 and 14x8.

Wiringwise, the 12x10 matrix would be most efficient, since you could simply split the physical 20x6 matrix into a left and a right half. This would also allow for the simplest mapping between mechanical and electrical coordinates.

Programmingwise, 14 outputs times 8 inputs would be most efficient, because you could route the 8 inputs to a single 8-bit controller port and check them in one go, which greatly simplifies the scanning routine (14 times probing a single port vs 11 times checking two ports). Even when probing pin by pin instead of grouping them to ports, an oblong matrix is more efficient: checking 14 inputs for each of 8 outputs is quicker than checking 11 inputs for each of 11 outputs. Not only the total number of checks is smaller (112 vs 121) but also the loop overhead is reduced (8 vs 11 iterations of the outer loop).

[flabbergast]

This is true, but unless you're after saving every microampere out of a battery-powered keyboard, it does not make too much practical difference in a keyboard. The debouncing delays effectively kill any advantage you get by wiring smartly

I think what Muirium was hinting at is that given a perimeter, you get the most area out of a square shape.

Of course it's perfectly fine to be a perfectionist

[chzel]

Mu probably meant which matrix gives more switch positions for the given pin count. And that is indeed the square matrix.

[Muirium]

Yup. Square matrices can get a bit pathological when trying to hand wire them up (or route them around a crowded, kitchen sink, every switch under the sun, 7bit-style PCB). But when pins are the hard limit in question (which they are in this thread) a square matrix yields the largest area for any given number* of pins.

*Insert pedantic disclaimer for odd numbers here! You're still talking about "as square as possible".

[OleVoip]

Well, in practice you start with a given switch count, not with a given pin count. The switch count seldom is a square number (49, 64, 81, 100, 121 or 144), so you often can choose between several matrix layouts which have the same pin count as the square matrix for your number of keys.
The point I wanted to make is that there are a number of factors involved with that matrix choice and that you can make your life easier by making a clever choice if you have a choice (and you usually have). This is about simplicity, not perfectionism.

The debouncing delays effectively kill any advantage you get by wiring smartly

There is a common misconception about the debouncing delay: Usually, people wait before they accept the state change. That's wrong. You only need to veto after you accepted the state change. (Unless you have noise on your lines that does not originate from bouncing, but that would be another issue.)
If your switch has been "off" for a while, already the first change to "on" indicates the keypress - you don't need to wait until it has become stable, you only must avoid mistaking the bounce back to "off" as a release of the key. By the same token, when your switch has been "on", it is the first drop to "off" that indicates that the user is releasing the key, you only must avoid confusing the bounce back to "on" with a new press. So you simply ignore the switch for a while after you registered a state change. Again, this is simplicity, not perfectionism.

[Muirium]

Well, in practice you start with a given switch count, not with a given pin count.

If Teensies were available with every arbitrary number of pins, sure you could. But in practice, people try to build for Teensy 2 (or even a horrible pin-starved Pro Micro if they like punishment), and must limit themselves to the number of pins on the Teensy 2++ or they're really up shit creek. People also like to dream of LED options (pro tip: don't) but no one likes to hear about multiplexers!

[OleVoip]

I love them multiplexers. I find it so nice to address a column just by putting its number to a port that I even use it when I could do without it. (And maybe one day I'll have an idea what I could use the pins for that I've spared.)

But my point was that you often can choose another matrix with the same number of pins as the square matrix.
If you only have 104 keys, you gain nothing by preferring a 11x11 matrix over a 12x10 or 14x8 matrix - all of them need 22 pins.

[Muirium]

Indeed. My hand wired 60% has 63 keys but a very rectangular 15*5 matrix for wiring and programming simplicity. I was still under the Teensy 2's limit, so why not. But when limits come at you, they matter.

A project I've had stranded for ages is a long life wireless keyboard with Cherry M84 (low profile, MX mount) switches. They need a PCB (no plate mounts) and the controller chip is an NRF thingmabob with only 15 useful pins. I planned a reduced layout 56 switch keyboard, with a pretty square matrix, but never quite got a PCB design. Do you reckon multiplexers would work well with a variable speed polling matrix? Because I'd much prefer a full 60% layout with 60-65 switches instead. PCB designs welcome!

[flabbergast]

Sorry to be an ignorant - what's a variable speed polling matrix?

And multiplexers - the Chinese already use it: I've seen one on a Red Scarf PCB, they use it for selecting rows.

[Muirium]

Multiplexing is where you speak to a middleman, sending it addresses as well as commands. (Well, this is my understanding. I'm not an engineer.) A multiplexer is a dumb chip that can boost your available pins, but you have to speak to it right. Not compatible with Soarer's controller, which I currently use.

Variable polling is where the keyboard is designed to save power (battery operated) and so you slow down the matrix when there's not any action for a while. You can save a lot of power if you race to sleep, as they say.

[OleVoip]

Sorry I don't do PCBs, just perfboard and wires. I'm using the 74HC154 (high-speed CMOS) multiplexer which can be run with a supply as low as 2 Volts and which is available from DIP24 down to TSSOP24 housings. It decodes 4 bits to 16 lines, the active line is low. (Hence, the sensing lines need to be pulled up; when a key is pressed and the corresponding driver line is active, it pulls the sensing line down.) So you can drive and read a 15x5 matrix with only 9 pins.

You control the decoder by simply setting its inputs to the 4-bit column number. If you switch to the next column immediately after reading the 5 row lines and then do whatever is needed to be done with the reading, time could already suffice for the pull-down-current to build up if a key is pressed in the next column; otherwise you'll need a small delay that allows for the signal propagation.

Rather than varying the scanning speed, I'd scan in a burst that quickly goes through all 15 columns and then have (parts of) the system sleep while the decoder is parked on the empty 16th (or zeroth) column, where no keypress can lead to current being sunk.

[flabbergast]

Nice explanation, thanks! (This is exactly how the Red Scarf PCB operated, except they've only used 3bits for 8 lines.)

For variable scanning speed - I thought the "speed" related to the delays/sleeps between the scans; each scan of the whole matrix is done as quickly as possible anyway.

[Muirium]

Exactly. The whole idea with power saving is to sleep everything as much as possible. But when you're awake, you're awake, so don't waste any time! Race to sleep.

[bpiphany]

<wall of text>
There is a slight difference between multiplexing and decoding. In decoding you take a binary encoded input and activate one exclusive output depending on the binary code. This way 3 bits make it possible to choose between 2^3=8 outputs.

That's decoding. When multiplexing (actually de-multiplexing I believe) you have an additional "data signal" which you want to send to one of the outputs. On the hc154, hc138 chips and so on this is done by using one of the enable inputs to send a digital signal to the output corresponding to binary on the select inputs.

There are also analog multiplexer/de-multiplexers where a data line is "connected through" to one of the selectable pins. They are not directional in the same way as digital de-multiplexers.

So technically you should be able to decode n io-pins to select between 2^n outputs (let's say columns). The hc138 chip will let you do 3->8 decoding, the hc154 will do 4->16, and the hc42 does 4->10. There are others as well with active high outputs and other extra functionality.

When I made the HID Liberation Device I used a hc238 (the active high variant) 3->8 decoder. The bastards at Costar made their matrix 18×8 and eighteen is not very nice in binary =P The hc238 force me to use external pull-down resistors on the 18 inputs. That was a terrible idea, soldering 18 extra resistors...

For the subsequent controllers I swapped to two hc42 decoders instead. They are a bit special in that they do not have any "enable inputs" (and hence can't really be used as de-multiplexers). With some trickery it is still possible to get a 6->20 decoding. Min you that 2^6=64 so we are really wasting binary digits here =D

To achieve a 4->16 decoding it's also possible to use two hc138s instead of the hc154. The hc138 is a bit less bulky, more common, and it would make sense to separate them physically on the board. Then they will sit closer to the columns they are driving, and routing should be easier.

It's also possible to achieve a 5->24 decoding using three hc138s. This would be handy for a full size (or slightly larger) board where there are "naturally" 22 columns.

For simpler daughter controller board designs a couple of decoders could be put on the main board. Through hole variants may even fit between the number and function rows.



Then there are serial communication shift registers if you really want to minimize the number of IO-pins needed.. Serially there are also nifty LED drivers that can be used if silly amounts of LEDs are desired. They come with built in PWM, current regulation, and more current resources then the average microcontroller. Hey, they were purpose built to drive LEDs after all =)
</wall of text>

[OleVoip]

Yes, sorry, I've been sloppy. You use the decoder to multiplex the input lines, but this doesn't make it a multiplexer.

[bpiphany]

I just wanted to get the terminology correct, just in case someone picks it up from here =) If asked, I couldn't say I had any source at hand to back up what I just claimed about the definitions of what is a decoder/demultiplexer/multiplexer...

I honestly thought I multiplexed a signal when I put it out to multiple places. But the datasheet on the hc154 says it's a demultiplexer. So I've been wrong about the direction up until tonight =)