deskthority

Hi guys,

after lots of information gathering on how things might work every now and then during the last half year or so I'm finally at the point where I'm looking for help to actually build my first custom hand wired keyboard. So I'm not looking for general information anymore but I guess I'm looking for more specific information, specific to my build.

Why do I want to build a custom keyboard and not one off the shelf? My approach to building this keyboard: A little bit about me and a little critique of existing solutions: The obligatory feature list:

1. ISO DE layout
2. compact in size
3. fully programmable
4. more than one layer
5. some sort of key backlight (on/off)
6. mobility (on board memory for programmed layers/macros - unlike the G84-4700)
7. hand wired
8. a budget controller (not 55$ incl. shipping and import tax)

Optional feature list (incomplete):

1. adjustable brightness for backlight
2. bottom/case light
3. pluggable number pad (to avoid a second controller for the pad)
4. on the fly macro programming
5. basic backlight effects
6. a PCB (as a future upgrade)

I have not yet decided what kind of case to use - if any and not just a metal frame instead (similar to the infinity). Also, the coloring of the key caps in the picture below is just an example. I'm not trying to mimic an existing set of key caps - this is just something that kinda I like.

The keyboard I want to build could look somewhat like this, just so you know what we're talking about (I call those two Emuboard 1 and Emupad 1 - so they don't have to be without a name whereas "Emu" are initials of my name.):


My assumptions:
TMK is the most versatile for firmware and different controllers - I don't know if I'd be able to program macros on the fly though, I don't think so.
The number of pins of the controller determine how many keys they keyboard can have. Not all those pins can be used to the key matrix. Also, more pins are needed to control the backlight.
Please explain to me what would be correct if I'm wrong.

My Question:

1. Since the number of pins is key, I can't use a Teensy for 69/86 keys + backlight?
   I was hoping that the big Teensy++ (or any compatible controller) with the AT90USB1286 was enough. I mean, GON is able to controll a full size keyboard and different backlights with just one controller...
2. Talking of GONs keyboards, is it possible to flash his firmware on a controller that I can use?
3. What controller (the cheaper the better) would you recommend me to get if I want to be able to implement all the above mentioned features as well as still have the most choices for firmware (e.g. input club, easy AVR, TMK - remember, I'm not a programmer so "easy" to do is key for me) if it's
   1. only for the keyboard (69 keys)?
   2. for the keyboard + the ability to connect the Numpad to it (86 keys in total)?

I guess that's it for now. Any help is welcome. If someone is willing to help me with his/her experience and knowledge to bring this project to it's completion, someone who I can contact when I'm stuck, that would be very welcome as well.

You don't have to be a programmer to use and customize Easy AVR, but it certainly helps. Creating your own keyboard from scratch is a complicated undertaking to begin with. A bit of know-how doesn't hurt.

For the keyboard shown, a Teensy may work fine depending on your backlighting plans. A Teensy++ would certainly work, though it takes up much more space. Both are well supported in the keyboard community because of projects like the Phantom. Can't go wrong with those.

You need to decide first what backlight you really need. The minimum solution is all keys backlit with always the same brightness. That will require only one Pin on the microcontroller. The maximum monochromatic solution is that each key can have different brightness. If your switch scanning matrix is e.g. 10 x 10 then you will need at least 10 additional pins for controlling brightness (maximum duty cycle a bit less than 1/10). If you would want an individually controlled RGB leds then it would be better to modify the swithc scanning matrix to 5x19 and you would need 15 additional pins to control the RGB leds (maximum duty cycle a bit less than 1/19 ... or possibly 1/15). You will need a FET for each pin of the grounding side of the led brightness control matrix.

When you know the number of needed pins then you can select the cheapest controller which gives you all the pins needed.

I do not know about the level of firmware support for matrix based LED brightness control.

An example of a small LED matrix schematic is attached.

Consideration of backlight options for number of pins:
For the start I'm totally fine with having just a general backlight for each key. In the last 11 years with the G15 I've never felt the need for anything more than just basic backlight in everyday life. According to you vvp that would be one extra pin and from that I'd expect that it's still only that one pin if I want to be able to change the general brightness or even have a basic breathing mode?
But I'm quite sure I read something somewhere that using just one pin for all the keys would be too little power or something? I think it was recommended to tap the power directly from the USB connector, build a seperate circuit from there and skip the controller. I mean, it's 69 or even 86 LEDs plus up to 2 more LEDs for Caps and Num Lock - one pin can handle all of them?
Anyways, should I decide to have a separate case backlight that is single color LEDs and nothing more like on/off/adjustbale general brightness it's two more pins. So that would make it three pins for lighting of the keys and the case, right?
And just for my understanding: For cycling RBG LED case backlight it also would be just two extra pin or 4 extra pins for RGB LEDs where I'm able to only set the general color myself. For individual color per LED... - that would depend on how many case LEDs I wanted... say 9up to nine, then that would be 12 pins (for a 3x3 LED matrix)?

You wrote that for a 10x10 switch scanning matrix I would need 10 extra pins - I thought that would be 20 pins!? Same for 5x19 and individual RBG LEDs - which I'd have expected to be 24 extra pins, not just 15. Seems like I got something totally wrong here. Unless... the LEDs and the switches share the same high (or low) pin (excuse my possible lack of proper terminology)? Or are you thinking of Charlieplexing (10 pins for up to 90 LEDs)? Wouldn't Charlieplexing be quite prone to errors when hand wiring and too complicated to program?

By the way, what is a maximum duty cycle in regards of controlling LEDs? Is it how often I can change the LEDs state (on/off/brightness/color) per second?

As for individual control of the backlight for every single key with two pin LEDs or even RGB, it would be nice to have a controller that can handle it but it's nothing I plan to go for right from the start - I don't want to make programming too complicated right from the start. And since I'm not a programmer it's unlikely that I'll be able to program something like a RBG backlight control for single keys. At least for now I doubt it.
But maybe there is code around at least for single colour LEDs that I could use sometime in the future to extend my firmware to individual key backlight control and then it would be nice to be able to use the controller that I already have. If individual key backlight control makes things with common firmware (TMK, Easy AVR,...) too complicated, then I have no problem to refrain from that option though.


Backlight pin summary:
I need
21 pins (for the keyboard only using a 5x15 switch matrix +1 pin for the Shift Lock LED) or
26 pins (if the keypad should be connected to the same controller +2 pins for Shift and Num Lock LEDs)

and if I'm right it is - depending on which options I go for:
+1 pin for basic key backlight (on/off/brightness and even modes that affect the complete backlighting like breathing)
+10 - 15 pins for individually controlled key backlight (non-RGB/RGB)
+2 pin for single colour or cycling RGB LED case backlight
+4 pins for RGB LED case backlight
+12 pins for individually controllable RGB LEDs case backlight(?)

The small version would be the keyboard with basic key backlight and two legged LED case backlight - 24 pins.
The basic version would be the keyboard with individually controllable non-RGB key backlight and RGB case backlight - 35 pins.
The medium version would be the keyboard with individually controlled non-RGB key backlight and individually controllable RGB LEDs case backlight - 43 pins.
The big version would be the keyboard with individually controlled non-RGB key backlight, individually controllable RGB LEDs case backlight and the keypad - 48 pins.
The deluxe version would be the keyboard with individually controllable RGB LED key/case backlight and keypad - 53 pins.
It's several pins more if the keypad should have the same backlight options. I doubt this is easily duable with only one controller - so lets forget about that for now.


Decision:
I'm aiming for the small version first - I'll be happy once at least that works. Nevertheless I would rather go for a controller that is able to handle the medium version which needs 43 usable pins (if the pin calculation is correct). This will allow me to add more features later on. That is if the price difference isn't too big. I.e. (exaggerated) if I can get a Teensy 2.0 for 5$ I probably won't spend 40$ for the ++.


Which controller should I get?
metalliqaz wrote that a Teensy (assuming he meant the 2.0) and certainly the Teensy++ would work for me. Though if I'm not mistaken, the Teensy 2.0 would only work for the small version with 24 pins. As soon as I go "better" or keyboard without any backlight but with keypad, the 2.0 hasn't enough pins and I have to go at least for a Teensy++.
I would think that the basic and the medium version are both in range of the same controllers. So even with the keypad added to the basic version (= 40 pins) the controller needed should be able the handle the keypad. This guess might be totally wrong though - it's just that most controllers I've seen so far either were as small as the Teensy 2.0 (or smaller, pinwise) or as big or even bigger as the Teensy++ with 45 I/O pins (according to pjrc - I don't know if I could use all of the pins for my purposes).
What about the Arduino Micro or boards that come with the ATmega328P? There are quite a lot of controllers which are available for less than 10$ but I have no idea if with them I still could use TMK or Easy AVR.

Will you be using 2 controllers or one - ie, will the numpad be a separate 'keyboard' with it's own controller, or will it connect 'through' the main board?

The previous posts answer that question.

In short: It depends on the controller I'm going to use for the keyboard.

D'oh, sorry. Evidently I skimmed that bit and missed it. So if you do go for 1 controller, how would you connect the two? There's an interesting project here where a guy is planning to use a magsafe connector for a magnetically connected numpad: keyboards-f2/custom-75-1-layout-with-da ... ml#p297351

You can not use arduinos with atmega328p for a keyboard (without jumping through a lot of hoops and pretty much writing a new firmware). Any board that comes with atmega32u4 (e.g. a Micro) would work, however if you don't have much experience with microcontrollers like these, I would recommend going for an actual Teensy (2.0 or 2.0++) {because most information available here or on GH assumes teensies}.

For case backlighting, people tend to use WS2811 based Neopixels. These are quite nice from the hardware standpoint, because it doesn't matter how many you use, the whole "strip" only requires one MCU pin, and still all the individual neopixels are individually addressable (i.e. you can set the colour of each of them separately).

If you want the in-switch LEDs to be individually controllable, I would recommend going for an extra LED controller chip (instead of trying to control the whole LED matrix from the Teensy), e.g. this one - it's the one used in the Infinity (also Ergodox) and Whitefox. Using an external LED controller chip makes it much easier to implement from the firmware point of view.

If you're OK with just having all in-switch LEDs (maybe with an exception of a couple of them, e.g. Caps Lock) to act the same, you're right that you should not feed the current to them through the microcontroller (that would fry it since MCUs in general can supply usually only about 15mA - 20mA before frying the MCU). The usual solution is to use a transistor wired in principle something like this.

Let's say you will have a keyboard scanning matrix of 5x15 and you want a single color LED at each switch with individual brightness control for each LED. Then you can share either 5 or 15 (but not all 20) wires for scanning switches also for one side of the LED matrix (but again not for both sides). Now you have two options:

• share the 5 wires, then you need additional 15 wires for backlight control and your maximum duty cycle for PWM is slightly below 1/5 (here you need together (5+15 + 15 pins);
• share the 15 wires, then you need additional 5 wires for backlight control and your maximum duty cycle for PWM is slightly below 1/15 (here you need together (5+15 + 5 pins).

Since the switch scanning matrix (as well as the LED matrix) is sparse (has holes - not all crosses are filled) then you can put additional special LEDs (like CapsLock, ScrolLock, NumLock, ...) into to the empty spaces of the LED matrix. In such a case, you do not need any additional pins for these special LEDs.
Or you may decide to dedicate one wire for each special LED. In such a case, you need one more pin for each special LED. This is a simpler solution from the point of view of writing firmware support for special LEDs. I do not know whether any current open firmware support PWM LEDs in a LED matrix.

Even if you want just one brightness control for all the backlight LED together. Even in such a case you almost for sure need one pint for it. The reason is that before the keyboard is enumerated (i.e. its firmware fully boots) it should not draw more than 100 mA from the USB buss. This limit will be hard to obey if you have there about 75 LED. Anyway if you decide to break the limit and draw 500 mA immediately it will work with most PCs. It may be more of a problem if you connect the keyboard to an usb hub. I do not really know about the hub option.

PWM duty cycle: The idea is to use resistors so that they limit the LED forward current just below the LED limit. That is typically 20 mA. So you would design the resistors so that the LEDs are taking e.g. 15 mA. Most LEDs will be quite bright at this current (you should select as efficient LEDs as possible). If the maximum PWM duty cycle is 1/15 then in practice your LEDs will be 15 times less bright as the maximum (because from the 15 units of time only one unit of time will actually drive 15 mA of current through a LED, the rest of the time the LED will be switched off). So the maximum duty cycle limits the maximum brightness you can achieve.

One pin of a microcontroller typically can source/sink at most about 20 mA (some can do more). So if you use the pin for more than one LED and the LEDs are driven near their maximum current limit (e.g. like it is in a LED matrix) then you need to use a transistor (FET) to amplify the amount of the current the wire can source/sink.

I guess that should answer all the LED related questions in a general way. I.e. the better way