"Open Source" Generic keyboard controller.

[Mnemonix]

Some do not want the external programming software. Just a text editor to edit the layout, write it to SD and re-insert it into the controller. Also, if you use on-keyboard programming you can remove the SD to backup or edit your layout. So I think the main reason for SD is software-less data exchange.

Hm. I think would be easier to communicate with the keyboard controller directly using some tool, without the SD card detour. It is possible over USB, but would it also work over PS/2?

Using SD cards also means that (V)FAT(32) needs to be supported (because it is supported by any major OS). Microsoft has some stupid patent pending for supporting long file names, which is the reason why LFN support can be disabled in recent Linux kernels... I would hate those patent trolls doing the same to the GeeKey firmware.

[msiegel]

The USB AVR series would be great, but they are not available in DIL packages (or are they?). But if there were cheap devboards for these...

i'm using the $20 Teensy dev board, with ATMEGA32U4

[inornate]

Good work, inornate. Is this your own project you mentioned on page 8?

Exactly. anyway AVR-based projects are really hard to support 19*9 matrix without additional hardware supports - because of its number of available pins The best available is 19*8. I think.

Maybe we can use MUX to increase its ability to handle more matrix but I'm not sure that additional hardware only for one extra column, is a good solution.

[cb951303]

Exactly. anyway AVR-based projects are really hard to support 19*9 matrix without additional hardware supports - because of its number of available pins The best available is 19*8. I think.

Maybe we can use MUX to increase its ability to handle more matrix but I'm not sure that additional hardware only for one extra column, is a good solution.

XMega and AVR USB can support even much bigger matrices but the problem is they are not in DIL packages. Is there a 34+ pins DIL package in any other brand?

[Mnemonix]

i'm using the $20 Teensy dev board, with ATMEGA32U4

Oh yes, the Teensy and Teensy++ come with USB AVRs. Completely forgot about this. :loco:

Exactly. anyway AVR-based projects are really hard to support 19*9 matrix without additional hardware supports - because of its number of available pins The best available is 19*8. I think.

The IBM M4-1 has a 19x9 matrix, hence the requirement. I'd love to see it fully supported, including its trackpoint if possible.

Maybe we can use MUX to increase its ability to handle more matrix but I'm not sure that additional hardware only for one extra column, is a good solution.

Yes, a MUX was the first thing I was thinking of, too. Then I realized that we don't need to multiplex arbitrary signal patterns, but only need to generate very specific patterns. You are probing rows one by one, so only a single row is activated at any given time:

Row 1: 10000...   (first row pin is activated, the others are not (e.g., tri-stated))
Row 2: 01000...   (only second pin is activated)
Row 3: 00100...
...

That is, we are shifting the "1" from the first to the last pin in order to probe the corresponding rows. This is easily done using a shift register, which only has two input pins to be driven by the MCU: Data and Clock. You trade 8 I/O pins on the AVR with 2 I/O pins at the price of an additional component. It is also possible to cascade multiple shift registers so that instead of 16 or 24 I/O pins you are using 2 or 3 additional components while still only using 2 I/O pins.

In the end it's a matter of additional cost and PCB space. Alternatively, we could just use a bigger MCU with more I/O pins.

[cb951303]

BTW if we need to keep the PCB small we may have to design it modular like arduino and its shields.

With bluetooth, SD(or eeprom), a BIG mcu and all other requested stuff it would probably fail to fit in any of the current keyboard cases

[inornate]

In the end it's a matter of additional cost and PCB space. Alternatively, we could just use a bigger MCU with more I/O pins.

Yes it's matter of cost (money and space); I agree that shift register is very good choice.

In my case I needed to build hundreds of units so cost was the most critical issue for me => therefore I chose minimal hardware parts in my project.

[Mnemonix]

BTW if we need to keep the PCB small we may have to design it modular like arduino and its shields.

With bluetooth, SD(or eeprom), a BIG mcu and all other requested stuff it would probably fail to fit in any of the current keyboard cases

A 1391401 has plenty of space, probably enough to stow a whole mini computer, but the Space Saving version is not so roomy.

But yeah, modular design would be good, albeit a bit more expensive.

[lowpoly]

Any suggestions for a collaborative spreadsheet? Has Google something here?

bump

[lowpoly]

I started a google docs spreadsheet here:

http://spreadsheets.google.com/ccc?key=0AkMZsZqYsU0kdDdQZ2V3ZEJ6RENuUm5TTDRUS2FTUmc&hl=en

As of now, anyone can edit.

[lowpoly]

As of now, anyone can edit.

Didn't realize this would start immediately. :-) Sorry for deleting that word I couldn't remember having written.

[Specter_57]

Hello all.

For those thinking of using shift registers in order to keep with the p-DIP type of devices, there is a rather detailed explanation on the use of shift registers with code examples on this Arduino-related page.

See here:

Serial to Parallel Shifting-Out with a 74HC595
http://arduino.cc/en/Tutorial/ShiftOut

and

Using shift registers to extend the microcontroller I/O
http://homepages.which.net/~paul.hills/Software/ShiftRegister/ShiftRegister.html


Just started reading about this Arduino device (mentioned from time to time here...)...which uses some of the same controllers suggested in this thread...looks interesting, at least for me it is...still at the bottom end of the learning curve when it comes to microcontrollers.

Anyway, hope this link I provided is useful to some readers here.

Spec57

[dmw]

Hey all,

After a long hiatus, i'm finally back working on my keyboard project.  I've almost completely rewritten and open-sourced my firmware.  You can find it on github.

It has many features, such as:

• Multiple layers, invoked through either momentary or toggle keys
• key maps specified in a simple text file format
• multi-key macros
• a special "matrix discovery" mode to help you figure out your keyboard's matrix
• a key can be mapped to modifiers + key (to be able to produce shifted keys without hitting shift, for example)
• a single key can have different bindings depending on what modifier keys are pressed (allowing you to completely divorce a key from its shifted state)

Those last two work, but are still in development to iron out issues when keys overlap. The HID keyboard protocol does not make this easy, since keys and their shifted states are tied up in a single code (e.g. 'Keyboard 1  and !').

The code has only been tested on the AT90USB1287, but should run on any chip in the AT90USB series.  It's currently running on my HumbleHack'd TypeMatrix 2030.

I've started using github's issue tracker.  You can take a look there to see what I've got planned, or add your own feature requests.  I could also use some help in figuring out the best way to solve the key overlap problem alluded to above.

[dmw]

Exactly.  That's what I did with the 2030.  It's nice to see that the price on the USBKEY has come down so much.  I paid $75 each for mine a few years ago.



I thought I'd post some examples of the keyboard definition files.  First, here's the keyboard matrix for the 2030.  Each cell in the table is filled with a 'location code', which is arbirtrary, but must also be used in the keymaps.

Code: [Select]

Matrix:2030-USB rev:197
/*            0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17 */
/* 0 */ Row: 7L, --, 7J, 7M, --, --, --, --, 7K, 1N, 5L, 6C, --, 5H, 5F, --, --, --
/* 1 */ Row: 1O, --, --, --, --, 6N, --, --, --, 4G, --, 5K, 5J, 5I, 5E, 5D, 5C, 5B
/* 2 */ Row: 6E, --, 7C, --, --, --, --, --, 6L, 1M, 4M, --, 1H, 4H, 4F, 1E, --, 1A
/* 3 */ Row: 1G, --, --, 3O, --, 6A, --, 6O, 6K, 1K, 2M, 1J, 2N, 2H, 2F, 1C, 1B, 2A
/* 4 */ Row: --, --, --, --, 6J, --, 4N, --, 5O, 5M, 4L, 4K, 4J, 4I, 4E, 4D, 4C, 4B
/* 5 */ Row: --, --, --, --, 7A, 1F, --, 7O, 6M, 1L, 2L, 2K, 2J, 2I, 2E, 2D, 2C, 2B
/* 6 */ Row: --, 7B, --, --, 6D, --, 4A, --, 2O, 2G, 3M, 1I, 3N, 3H, 3F, 1D, 4O, 3A
/* 7 */ Row: --, --, --, --, --, --, --, --, 6B, --, 3L, 3K, 3J, 3I, 3E, 3D, 3C, 3B

This is the US layout.  The 'tl:' and 'bl:' are key labels that are currently not used, but may be in the future (to generate keyboard images, for example).  They at least serve as a measure of documentation on what the key is expected to produce.
 
The 'base:' keyword shows that keymaps can be based on other keymaps.

the 'default' keyword says that this is the default keymap, i.e. the one that will be set when the keyboard is plugged in.

Code: [Select]

KeyMap:US base:Common default rev:205

  /* Row 3 */
  Key:2A Map:`_and_~           tl:"~"    bl:"`"
  Key:2B Map:1_and_!           tl:"!"    bl:"1"
  Key:2C Map:2_and_@           tl:"@"    bl:"2"
  Key:2D Map:3_and_#           tl:"#"    bl:"3"
  Key:2E Map:4_and_$           tl:"$"    bl:"4"
  Key:2F Map:5_and_%           tl:"%"    bl:"5"
  Key:2H Map:6_and_^           tl:"^"    bl:"6"
  Key:2I Map:7_and_&           tl:"&"    bl:"7"
  Key:2J Map:8_and_*           tl:"*"    bl:"8"
  Key:2K Map:9_and_(           tl:"("    bl:"9"
  Key:2L Map:0_and_)           tl:")"    bl:"0"
  Key:2M Map:-_and_Underscore  tl:"__"   bl:"-"
  Key:2N Map:=_and_+           tl:"+"    bl:":"

  /* Row 3 */
  Key:3B Map:q_and_Q           tl:"Q"
  Key:3C Map:w_and_W           tl:"W"
  Key:3D Map:e_and_E           tl:"E"
  Key:3E Map:r_and_R           tl:"R"
  Key:3F Map:t_and_T           tl:"T"
  Key:3H Map:y_and_Y           tl:"Y"
  Key:3I Map:u_and_U           tl:"U"
  Key:3J Map:i_and_I           tl:"I"
  Key:3K Map:o_and_O           tl:"O"
  Key:3L Map:p_and_P           tl:"P"
  Key:3M Map:[_and_{           tl:"{"    bl:"["
  Key:3N Map:]_and_}           tl:"}"    bl:"]"

  /* Row 4 */
  Key:4B Map:a_and_A           tl:"A"
  Key:4C Map:s_and_S           tl:"S"
  Key:4D Map:d_and_D           tl:"D"
  Key:4E Map:f_and_F           tl:"F"
  Key:4F Map:g_and_G           tl:"G"
  Key:4H Map:h_and_H           tl:"H"
  Key:4I Map:j_and_J           tl:"J"
  Key:4J Map:k_and_K           tl:"K"
  Key:4K Map:l_and_L           tl:"L"
  Key:4L Map:;_and_\:          tl:":"    bl:";"
  Key:4M Map:\'_and_\"         tl:"\""   bl:"'"

  /* Row 5 */
  Key:5B Map:z_and_Z           tl:"Z"
  Key:5C Map:x_and_X           tl:"X"
  Key:5D Map:c_and_C           tl:"C"
  Key:5E Map:v_and_V           tl:"V"
  Key:5F Map:b_and_B           tl:"B"
  Key:5H Map:n_and_N           tl:"N"
  Key:5I Map:m_and_M           tl:"M"
  Key:5J Map:,_and_\<          tl:"<"    bl:","
  Key:5K Map:._and_\>          tl:">"    bl:"."
  Key:5L Map:/_and_?           tl:"?"    bl:"/"
  Key:5M Map:\_and_|           tl:"|"    bl:"\\"

And here is a Programmer Dvorak layout, which illustrates some of the more advanced key bindings possible.  

Basically, modifiers are placed in <>, and separated by | (e.g. ).  Modifiers appearing before the Map: keyword are called pre-modifiers.  They change what the key will do when combined with the given modifier.  

Modifiers appearing after the Map: keyword are just called modifiers.  They affect what modifier keys are sent to the computer along with the given key binding.

So given this, and looking at key 2A, hitting the key by itself will produce '$', while hitting the key with will produce '~'.

Code: [Select]

KeyMap:pDV base:US rev:57

  /* Row 2 */
  Key:2A         Map:4_and_$              bl:"$"
          Map:`_and_~      tl:"~"
  Key:2B         Map:7_and_&              bl:"&"
          Map:5_and_%      tl:"%"
  Key:2C         Map:[_and_{                     bl:"["
          Map:7_and_&             tl:"7"
  Key:2D         Map:[_and_{              bl:"{"
          Map:5_and_%             tl:"5"
  Key:2E         Map:]_and_}              bl:"}"
          Map:3_and_#             tl:"3"
  Key:2F         Map:9_and_(              bl:"("
          Map:1_and_!             tl:"1"
  Key:2H         Map:=_and_+                     bl:"=
          Map:9_and_(             tl:"9"
  Key:2I         Map:8_and_*              bl:"*"
          Map:0_and_)             tl:"0"
  Key:2J         Map:0_and_)              bl:")"
          Map:2_and_@             tl:"2"
  Key:2K         Map:=_and_+              bl:"+"
          Map:4_and_$             tl:"4"
  Key:2L         Map:]_and_}                     bl:]"
          Map:6_and_^             tl:"6"
  Key:2M         Map:1_and_!              bl:"!"
          Map:8_and_*             tl:"8"
  Key:2N         Map:3_and_#              bl:"#"
          Map:`_and_~             tl:"'"

  /* Row 3 */
  Key:3B          Map:;_and_\:           tl:":"  bl:";"
  Key:3C          Map:,_and_\<           tl:"<"  bl:","
  Key:3D          Map:._and_\>           tl:">"  bl:"."
  Key:3E          Map:p_and_P            tl:"P"
  Key:3F          Map:y_and_Y            tl:"Y"
  Key:3H          Map:f_and_F            tl:"F"
  Key:3I          Map:g_and_G            tl:"G"
  Key:3J          Map:c_and_C            tl:"C"
  Key:3K          Map:r_and_R            tl:"R"
  Key:3L          Map:l_and_L            tl:"L"
  Key:3M          Map:/_and_?            tl:"?"  bl:"/"
  Key:3N          Map:2_and_@    tl:"@"
          Map:6_and_^    bl:"^"

  /* Row 4 */
  Key:4C  Map:o_and_O                    tl:"O"
  Key:4D  Map:e_and_E                    tl:"E"
  Key:4E  Map:u_and_U                    tl:"U"
  Key:4F  Map:i_and_I                    tl:"I"
  Key:4H  Map:d_and_D                    tl:"D"
  Key:4I  Map:h_and_H                    tl:"H"
  Key:4J  Map:t_and_T                    tl:"T"
  Key:4K  Map:n_and_N                    tl:"N"
  Key:4L  Map:s_and_S                    tl:"S"
  Key:4M  Map:-_and_Underscore           tl:"__" bl:"-"

  /* Row 5 */
  Key:5B  Map:\'_and_\"                  tl:"\"" bl:"\'"
  Key:5C  Map:q_and_Q                    tl:"Q"
  Key:5D  Map:j_and_J                    tl:"J"
  Key:5E  Map:k_and_K                    tl:"K"
  Key:5F  Map:x_and_X                    tl:"X"
  Key:5H  Map:b_and_B                    tl:"B"
  Key:5J  Map:w_and_W                    tl:"W"
  Key:5K  Map:v_and_V                    tl:"V"
  Key:5L  Map:z_and_Z                    tl:"Z"


[dmw]

Ok, I just finished reading through all the posts in this thread.  Maybe should have done that _before_ I posted.

I know I'm late to the game, but I have to say... Mnemonix, awesome job with your controller board and firmware!  If I had access to this a while ago, I probably would have never decided to try to do it myself.  I'm also very excited about the Teensy++.  With that, I see no need to build my own controller board.

Mnemonix, there's a lot of overlap between our projects.  I would like to borrow some of your ideas for my firmware, if you don't have any objections.  For example, I have been planning to add some method of programming the keyboard without re-flashing the firmware, but I wasn't sure how to go about it.  Looks like you have that feature already.  It seems from reading your posts that you have a lot of experience with this kind of development.  I'd like to pick your brain on a few things, as this is my first foray into MCU development.  I have a lot of ideas - would you consider collaborating?  Or have you moved on from this project?

[ricercar]

You didn't to start with dog-dares this time? :laugh:

[sethstorm]

Thanks.

OK, who at Geekhack is gonna go 2nd?   I'd volunteer but I'm in the 25% of the Geekhack population that isn't in IT.  I don't even have a beard.

Show Image

On using the controller?  Would this be adaptable for the card-edge connector that model M membranes present?  Count me in.

It would seem to be quite usable to use this, the firmware, and attach it to my Wheelwriter 5.  It has a nice, small 13x8 matrix.

[timofonic]

Interesting...

Some site or wiki page showing the schematics plus the link to the firmware code? Or update the first page

Also...

Aren't most USB adapters sucky? I mean about unable to push several keys at once.

Anyway, it IBM keyboards are 2kro. It could be nice to replace the original controller by a N-key rollover capable one.

[noctua]

Interesting...

Some site or wiki page showing the schematics plus the link to the firmware code? Or update the first page

Also...

Aren't most USB adapters sucky? I mean about unable to push several keys at once.

Anyway, it IBM keyboards are 2kro. It could be nice to replace the original controller by a N-key rollover capable one.

You may notice there exist a big difference between a idea and doing so, for
example you have to check the matrix carefully, some needs additional
1N4148 (or similar), some firmware code needs to revise..

[Mnemonix]

(Sorry for the late answer, but I'm quite busy at the moment.)

Ok, I just finished reading through all the posts in this thread.  Maybe should have done that _before_ I posted.

I know I'm late to the game, but I have to say... Mnemonix, awesome job with your controller board and firmware!  If I had access to this a while ago, I probably would have never decided to try to do it myself.  I'm also very excited about the Teensy++.  With that, I see no need to build my own controller board.

Thank you!

Good you've decided to try it yourself, diversity is good. Also, thanks for sharing your work. As I understand it, your code will only work on USB-enabled AVRs. So when extending my own code for these I can take a look at your code how you've done it.
I've also thought about ordering a Teensy++ to play around with, but that will have to wait for now.

Mnemonix, there's a lot of overlap between our projects.  I would like to borrow some of your ideas for my firmware, if you don't have any objections. For example, I have been planning to add some method of programming the keyboard without re-flashing the firmware, but I wasn't sure how to go about it.  Looks like you have that feature already.

Well, it's all GPL'ed code, so, by definition copying is OK as long as your code is GPL-compatible, too, or if the copied code is trivial. Otherwise, borrowing ideas is always allowed, of course.

Concerning the programming of the keyboard, I am using the AVR's internal EEPROM for storing alternative key maps and configuration data. The tricky part was to find a method for communicating with the keyboard so that data other than HID packages could be exchanged. Fortunately, there is libusb which is taking care of the nasty OS-dependent details (detaching the HID driver from the device, re-attaching it later, sending/receiving data).

It seems from reading your posts that you have a lot of experience with this kind of development.  I'd like to pick your brain on a few things, as this is my first foray into MCU development.  I have a lot of ideas - would you consider collaborating?  Or have you moved on from this project?

This was my first microcontroller-based project, too, but I have done some VHDL and other low-level stuff before, plus lots of experience in C and software development in general. I may seem more experienced than I really am. My MCU skills are currently improving, though, since I've got a new job in embedded systems development. Now I am getting paid for having fun.

I haven't moved from the project, but I have less time to work on it -- and it is working for me already anyway, so there's not much left to do from my perspective.
Still, if you have questions or would like to discuss ideas, feel free to do so (here in public or PM). I'd love to hear your ideas.

[JBert]

Anyway, it IBM keyboards are 2kro. It could be nice to replace the original controller by a N-key rollover capable one.

Forget about it. You need to alter the matrix before you can use an NKRO controller, something which isn't possible seeing how the matrix is printed on non-sticky mylar sheets.

The only NKRO IBM keyboards are the model Fs or earlier models.

[Halo]

I haven't moved from the project, but I have less time to work on it -- and it is working for me already anyway, so there's not much left to do from my perspective.

Weren't you originally wishing to implement trackpoint/trackball support?
Your IBM M4-1 has one so I hope I didn't just miss mention of support.

Thank you for sharing your kbupgrade by the way.

[Mnemonix]

Weren't you originally wishing to implement trackpoint/trackball support?
Your IBM M4-1 has one so I hope I didn't just miss mention of support.

Thank you for sharing your kbupgrade by the way.

Yes, trackpoint support is still missing. Didn't think of it when writing my last message.
As a matter of fact, trackpoint support is getting more interesting for me right now because my desk is usually full of stuff at work, so throwing away the mouse would definitely help (I'm using the M4-1 at work).

So, for the keyboard part, there's not much left to do; trackpoint is still planned. Concerning the keyboard support, getting the Model F to work I got from Meltie some months ago is on top of my list.

Edit: Oh, welcome to Geekhack!

[chimera15]

I'm reading through this, is there a ready made program to upload to a teensy++ that can define a matrix or not?

Is DMW's the most complete?  I need to compile it with a c++ compiler?  Is there a walkthrough of what I need to do exactly to get it running on my teensy++.  I've never had a ton of luck compiling programs before.

Is there precompiled, or an exact list of what I need to do?

[dmw]

chimera15,

If you want to try to use my firmware, I'll be happy to help you get it going.  I do have it compiled and running on my Teensy++ 2.0.  What keyboard do you have in mind for it?

You need a C compiler to compile it - avr-gcc to be exact.  There are different packages for each OS.  WinAVR for Windows and  CrossPack for Mac.  You'll have to use your favorite package manager to install avr-gcc on Linux.

You can find my source code at http://github.com/humblehacker/keyboard.  If you're not familiar with git, you can download a tarball or zipfile from http://github.com/humblehacker/keyboard/downloads. Choose the one labeled 'teensy-test.'

[noctua]

To my knowledge there exist no specific adapted version for Teensy++. Some
are based on V-USB other are based on LUFA that i have seen, since the
matrix scan mechanism self is portable to any controller. The bottom line
is therefore the programming of the built-in USB device controller..

We'll see.

[dfj]

chimera15,

You can find my source code at http://github.com/humblehacker/keyboard.  If you're not familiar with git, you can download a tarball or zipfile from http://github.com/humblehacker/keyboard/downloads. Choose the one labeled 'teensy-test.'

I've got a teensy++ and some matrices handy too, I'll give it a shot this weekend, hopefully. Just dl'd yer test...

I've also got a mess of code which is near-release quality, but missing a bunch of mnemonix's features... I want to see which areas you cracked well...
  With a bit of luck, we killed largely different problems.
(e.g. I kilt the 6-key/nkro problem in USB for my driver... but I din' bother doing software-remappable keys...)

   I've used atmega168s, the teensy++ and the atmega 32 on this - din' quite manage to get a ps2-usb converter working on an 8-pin tiny yet, though.

yup,
dfj

[dfj]

- is that one can mount double-height pins in it for prototyping. Once you are happy, you can snip the bottoms, tops or use another one to lay flat inside yer keyboard.


dfj

[chimera15]

chimera15,

If you want to try to use my firmware, I'll be happy to help you get it going.  I do have it compiled and running on my Teensy++ 2.0.  What keyboard do you have in mind for it?

You need a C compiler to compile it - avr-gcc to be exact.  There are different packages for each OS.  WinAVR for Windows and  CrossPack for Mac.  You'll have to use your favorite package manager to install avr-gcc on Linux.

You can find my source code at http://github.com/humblehacker/keyboard.  If you're not familiar with git, you can download a tarball or zipfile from http://github.com/humblehacker/keyboard/downloads. Choose the one labeled 'teensy-test.'

I'm going to try to build a scratchbuild with it, with this layout:
http://geekhack.org/showwiki.php?title=Island:10454

I'm using Windows...

Is it possible to create the two function keys like I describe with this programming?

I'm installing winavr, is that all I need?

Alright, I've installed winavr, and downloaded the zip file.....now what. lol

[dmw]

I'm going to try to build a scratchbuild with it, with this layout:
http://geekhack.org/showwiki.php?title=Island:10454

Do you know the keyboard matrix already?  If you don't, my code includes a custom build option that will help you determine the matrix.

Is it possible to create the two function keys like I describe with this programming?

You can have as many function keys as you like.

I'm installing winavr, is that all I need?

There is a ruby script code generator that turns the keymap files into code.  If you don't have ruby installed, you'll have trouble building. You can get ruby for Windows here. There are additional dependencies once you've installed ruby.  If you don't want to install ruby, I can build the keymaps for you after you've created your keymap files.  

Alright, I've installed winavr, and downloaded the zip file.....now what. lol

• Unzip the zip file
• Navigate to the directory keyboard/firmware
• make a copy the directory kb_reference.  Call it whatever you like - kb_chimera, for example.
• from the command-line, navigate to keyboard/firmware/kb_chimera
• type 'make'

This will build the reference firmware, which is just a starting point for doing your own keyboard.  There are some files you'll need to modify to actually build a working firmware.  Take a look at keyboard/firmware/kb_chimera/layouts to get an idea.

Once you reach this point, contact me and we'll take it further.  Maybe PM me, so we don't clog up this thread.  You can also reach me on freenode at ##humblehacker, if you do IRC.

[Specter_57]

.

Here is something that may be of interest, related to this thread...see my post in the "Making a Cheap Model M USB Controller" thread, post #257 on page 18:

http://geekhack.org/showwiki.php?title=Island:8406&do=comments&page=18

..............
Spec_57

[chimera15]

DMW wins. lol

[repeatrate]

nvm worked great.

[intealls]

I just wanted to say thanks to dmw, your firmware is absolutely awesome. Finished wiring up one of my AEK II's yesterday, and it works fabulously. Thanks to you, I can bring my dvorak and fn-hax to every computer on the planet. THANK YOU!

I think you can all tell where I'm going to chop it off. The layout is very MiniGuru-ish at the moment.

[Jaga]

Hello!
I'm interested in building custom keyboard. I don't like stuff for sale.
I need a custom arrangement of keys, some custom keys (like compose, dead keys etc.), custom codes from keys and of course custom keycaps.
I need a custom controller, I think. But I don't know the full technology. Is there a FAQ of making a keyboard from scratch?

[alaricljs]

Kinda sorta.

Here
Here
Here
Here

There are likely to be several more, but that should get you pretty well on your way.  There are a number of already developed KB firmwares for the teensy, or you can go with an Aikon, or Chamelon (available on TaoBao), or some other controller.

[Jaga]

Thank you. And sorry me not searching properly.

[alaricljs]

Unfortunately with GH sometimes that requires already knowing what you're searching for and knowing to use google and site:geekhack.org to do it.  

[Input Nirvana]

So what is the status of this? Is there current work still being done? Or is it at it's final point?

[Niy]

I guess this project is dead -- tho I really hope there are some guys out there working on it.
But I'd be happy to be part of a restart of this project.

[uberben]

I guess this project is dead -- tho I really hope there are some guys out there working on it.
But I'd be happy to be part of a restart of this project.

I'll be starting a custom, generic keyboard controller project shortly that I intend to release as open source. I'm building it for my Kinesis Contoured keyboard, but I intend to make it as generic as possible. It will be a combination USB/bluetooth (though it could easily be made bluetooth optional) keyboard controller and I have plans to integrate a pointing device as well. I've already got many of the parts, I just need to find some time to start playing with it.

My current plan is to kind of make a combination of the HumbleHacker keyboard and the Keyglove. Once I get started, I'll probably start a thread here with details and progress updates. I'm all for working with others to speed up development.

[komar007]

Could you tell some more details about the controller, hardware specifically?
I already have a working codebase for AVR with a USB HID nkro stack.
I can release it as open-source if necessary. I don't have much time to end this project, so if it can help, let me know.

[uberben]

Could you tell some more details about the controller, hardware specifically?
I already have a working codebase for AVR with a USB HID nkro stack.
I can release it as open-source if necessary. I don't have much time to end this project, so if it can help, let me know.

The dev board I have is the 32u4 breakout from Adafruit. The bluetooth module is the Bluegiga WT-12 (I have this breakout board). Ultimately, I hope to make a custom circuit board for it. If it is going to be a universal controller, I might need some help finding an appropriate set of dimensions for the board to maximize compatibility.

I haven't started on software yet, but I intend to use the LUFA stack for USB HID to maintain maximum open-source code. My goal is ultimately to have nkro, but 6kro compatibility for boot is desired too. I have seen some projects with this, though I haven't dug much into the details of their implementation. The one that caught my eye though was just using the standard 6kro headers for when there are <7 keys pressed, then switching to the extended headers when there are more. Seems simple enough to me, but like I said, I haven't started coding it up yet.

The more code examples I can get my hands on, the better. I would be glad to us your code as an example.

[hasu]

I used WT12 from Jeff for HID stack of my keyboard and I found firmware 4.0 has some bugs on HID. I think you should get 4.1beta or 5.0beta from Bluegiga support. I'm using 4.1beta but not try 5.0beta yet.
I have some lag on the Bluetooth module to register keys, I don't want to use this keyboard for serious typing work though I'm not sure whether this lag is normal or not on Bluetooth. I have no Bluetooth keyboard excepting this DIY board. I guess I should try 5.0beta or use HCI instead of iWRAP.

FYI: I have a memo about NKRO on USB.
https://github.com/tmk/tmk_keyboard/blob/master/USB_NKRO.txt

[uberben]

Ya, I have heard that the 5.0 software should work a lot better for HID than the 4.0. Is it a simple process to upgrade the module?

[hasu]

Not a lot of work for upgrade itself.
But to get account from them was a bit hell. They didn't accept my gmail address so I had to setup a new email of a neat domain