controller for DIY Keyboard

[CeeSA]

i would like to make my own keyboard.

indeed i need a custom controller.

requirements:
- programmable keys
- programmable makros

nice to have:
- special keys for makros (you not found at standart layout)

do you know a controller with this features?
order information would be sweet

i have heard about "Aikon" and "MONKEY" but i dont know nothing about the featurelist.

personal experience would be awesome

[sixty]

Aikon is fully programmable, very easy to use and setup and supports full n-key rollover. However it does not have a macro option.

A while ago the Aikon was available for purchase in Korea as a pre-made smd part based pcbs, however those are long sold out. You can read about my first experiments with that controller here:

http://geekhack.org/showwiki.php?title=Island:8308

Its also kinda easy to make one yourself, though I have not done so yet. I have ordered all the parts though!

The schematics were posted by one of the original Aikon designers a while ago:



If you decide to go this route, you will also need a ISP programmer to burn the bootloader to the atmega32. Cheap and portable one is available for us Germans here on eBay.

After you are done building and burning the bootloader the rest is a real breeze.



Programming is as easy as pressing a real key and then assigning a new one in the software:

Aikon features:
* Cost effective DIY design
* Easy to reassign and reprogram keys on the fly
* Full N-Key support
* FN Layer Support and Num-Layer support (making a total of 3 possible key layers)
* Matrix support up to 18x8 (144 keys)

[taswyn]

Teensy 2.0 is an (out of stock until ~Jan) Atmega32U4 based board, is it software compatible with the Aikon firmware? I don't know enough about microcontrollers to tell at a glance =/ Could a Teensy 2.0++ be loaded with the firmware, is the AT90 microcode compatible just with more addressable ports/ram/rom? That is, something only trying to address the subset available on both would still work fine? Or could you at least recompile the firmware (assuming it's available in C/etc?) easily with the AT90 as a target? I can try to figure that out on my own, but it would be easier if someone already knows, since I know next to nothing about microcontrollers ^^;

And I do know that a teensy can be used as a custom programmed keyboard controller in general, it just seems like the Aikon firmware/software is a very nice package already, if it can be loaded on a teensy. They seem nicely cost effective for someone who doesn't necessarily have all of the needed parts just sitting around. Of course for those of you in Germany, I doubt that's as true =(

[Lanx]

i'm using a g15v2 for my current mod, 5 programmable buttons, has pins so you can solder to.

this is if you don't want to get those controllers, repurposing an existing controller that has macro buttons (like g15) is an option, unless you need to program everything?

[bpiphany]

Teensy 2.0 is an (out of stock until ~Jan)

From the pjrc page...

If you really need the smaller size board, they are still in stock at Adafruit and Floris.

I have ordered both a teensy and teensy++. I have my own little project going =) I too would like to know if that aikon software is available somewhere and would work on the teensy.

[Vitaly]

http://goo.gl/PkPE6g
is it the same as teensy?

Is any difference between teensy 2.0 and 3.1 for keyboard?

[Melvang]

The teensy 2.0 and 2.0++ both use the Atmega32U4 chip and has various different firmwares that work very well with it.  The 3.0 and 3.1 both use Arm chips and does not have the same amount of development yet with use as a keyboard controller, though it has been done.

[Vitaly]

The teensy 2.0 and 2.0++ both use the Atmega32U4 chip and has various different firmwares that work very well with it.  The 3.0 and 3.1 both use Arm chips and does not have the same amount of development yet with use as a keyboard controller, though it has been done.

Now I'm searching controller for first diy board, I guess teensy 2.0 best solution for starting point?

[Melvang]

That would be my reccomendation.  At least in this community there are two primary firmwares, Soarers, and TMK.

[Vitaly]

That would be my reccomendation.  At least in this community there are two primary firmwares, Soarers, and TMK.

I found that only difference between teensy 2.0 and ++ is "teensy++ adds USB host capabilities" and this is not necessary for keyboard? I can buy cheaper version teensy 2.0 (15 vs 27 on adafruit)?

[jdcarpe]

That would be my reccomendation.  At least in this community there are two primary firmwares, Soarers, and TMK.

I found that only difference between teensy 2.0 and ++ is "teensy++ adds USB host capabilities" and this is not necessary for keyboard? I can buy cheaper version teensy 2.0 (15 vs 27 on adafruit)?

Teensy++ 2.0 just has more I/O capability. Teensy 2.0 should be fine for just about any keyboard.

[Vitaly]

That would be my reccomendation.  At least in this community there are two primary firmwares, Soarers, and TMK.

I found that only difference between teensy 2.0 and ++ is "teensy++ adds USB host capabilities" and this is not necessary for keyboard? I can buy cheaper version teensy 2.0 (15 vs 27 on adafruit)?

Teensy++ 2.0 just has more I/O capability. Teensy 2.0 should be fine for just about any keyboard.

Thanks. Will take teensy

[cribbit]

How much beyond just a keyboard can the teensy++ support? Eg, leveled RGB backlighting, USB hub, sound chip, etc.

Are there any firmwares that will simply tell me whether a key is pressed or not at any given moment, and let me program the rest from there?

[Oobly]

How much beyond just a keyboard can the teensy++ support? Eg, leveled RGB backlighting, USB hub, sound chip, etc.

Are there any firmwares that will simply tell me whether a key is pressed or not at any given moment, and let me program the rest from there?

Teensy 2.0 can support up to 6 PWM signal controlled LED's, so you could use those for driving RGB LED's through FET's and still have Caps, Num and Scroll Lock LED's, but it limits how many columns/rows you can still use. The PWM signal can be adjusted to control the brightness.

You'll have to write your own firmware based on an existing one to get the RGB LED's working, though, since you'll have to add code for it.

USB hub and sound chip would have to be external solutions, the Teensy doesn't support that functionality.

[cribbit]

Does any controller allow for every RGB LED to be independently controlled?

[dorkvader]

Does any controller allow for every RGB LED to be independently controlled?

Not really. You'd have to get a dedicated LED driver chip and control that with the main KB controller.

Even then, individual control of that many RGBLEDS requires like 300-400 pins, so you'd need a quite expensive answer. There are methods to alleviate this somewhat.

[cribbit]

Does any controller allow for every RGB LED to be independently controlled?

Not really. You'd have to get a dedicated LED driver chip and control that with the main KB controller.

Even then, individual control of that many RGBLEDS requires like 300-400 pins, so you'd need a quite expensive answer. There are methods to alleviate this somewhat.

Perhaps small "substation" chips, which take data from the main chip and then put it to the surrounding LEDs? Still a lot of pins to soder, but makes it easier to manage paths as they'd be a lot shorter. Also, doesn't the RGB control only use one or two of the pins? They could all have the same power level, but data only needs to be unique for fewer pins.

[Melvang]

Does any controller allow for every RGB LED to be independently controlled?

Not really. You'd have to get a dedicated LED driver chip and control that with the main KB controller.

Even then, individual control of that many RGBLEDS requires like 300-400 pins, so you'd need a quite expensive answer. There are methods to alleviate this somewhat.

Perhaps small "substation" chips, which take data from the main chip and then put it to the surrounding LEDs? Still a lot of pins to soder, but makes it easier to manage paths as they'd be a lot shorter. Also, doesn't the RGB control only use one or two of the pins? They could all have the same power level, but data only needs to be unique for fewer pins.

Doesn't work that way.  The way they work is there is actually 3 LEDs with discrete positive pins and all sharing a common negative pins.  They way color is controlled is by adjusting the brightness of the individual LEDs inside each unit.  Now how to actually implement this I don't know.

[cribbit]

Does any controller allow for every RGB LED to be independently controlled?

Not really. You'd have to get a dedicated LED driver chip and control that with the main KB controller.

Even then, individual control of that many RGBLEDS requires like 300-400 pins, so you'd need a quite expensive answer. There are methods to alleviate this somewhat.

Perhaps small "substation" chips, which take data from the main chip and then put it to the surrounding LEDs? Still a lot of pins to soder, but makes it easier to manage paths as they'd be a lot shorter. Also, doesn't the RGB control only use one or two of the pins? They could all have the same power level, but data only needs to be unique for fewer pins.

Doesn't work that way.  The way they work is there is actually 3 LEDs with discrete positive pins and all sharing a common negative pins.  They way color is controlled is by adjusting the brightness of the individual LEDs inside each unit.  Now how to actually implement this I don't know.

So most RGB boards group up LEDs so they don't take up 3x the number of pins as keys?

The substation thing could still work though. Then again, I'm pure CS not an EE so I have no idea.

[dorkvader]

Does any controller allow for every RGB LED to be independently controlled?

Not really. You'd have to get a dedicated LED driver chip and control that with the main KB controller.

Even then, individual control of that many RGBLEDS requires like 300-400 pins, so you'd need a quite expensive answer. There are methods to alleviate this somewhat.

Perhaps small "substation" chips, which take data from the main chip and then put it to the surrounding LEDs? Still a lot of pins to soder, but makes it easier to manage paths as they'd be a lot shorter. Also, doesn't the RGB control only use one or two of the pins? They could all have the same power level, but data only needs to be unique for fewer pins.

Doesn't work that way.  The way they work is there is actually 3 LEDs with discrete positive pins and all sharing a common negative pins.  They way color is controlled is by adjusting the brightness of the individual LEDs inside each unit.  Now how to actually implement this I don't know.

So most RGB boards group up LEDs so they don't take up 3x the number of pins as keys?

The substation thing could still work though. Then again, I'm pure CS not an EE so I have no idea.

I think so. With an IO expander, or lots of PWM driver chips, you can have a microcontroller orchestrating it all. And if you cant' get LED matrix driver chips for some reason, the PWM into transistors should work (but it'll be expensive)

You may run into issues with a normal teensy2.0, so something more powerful (ARM, etc.) would likely be needed. I'm no CS, so I'm not sure about that.

Actually, I don't know much about communicating between chips, since I'm not a computer engineer. I know much more about the EE side of things with power and diodes and voltage and all that.

[cribbit]

My experience in the past (namely robotics) is all pure programming. I tell the EEs what things I want sensors reading and what outputs I want to give, they give me that as functions I can call.

[qwack]

Even then, individual control of that many RGBLEDS requires like 300-400 pins, so you'd need a quite expensive answer. There are methods to alleviate this somewhat.

Is it not possible to get individual control on LEDs arranged in a matrix ? That would be 32 pins "only" to control 64 RGB LEDs (enough for a 60%) for instance.

[dorkvader]

Even then, individual control of that many RGBLEDS requires like 300-400 pins, so you'd need a quite expensive answer. There are methods to alleviate this somewhat.

Is it not possible to get individual control on LEDs arranged in a matrix ? That would be 32 pins "only" to control 64 RGB LEDs (enough for a 60%) for instance.

It is possible to do a matrix, I think.