"Open Source" Generic keyboard controller.

[Mnemonix]

and yeah i do think this is pretty amazing, it went from idea to something that works pretty fast, makes me wonder if i will ever have a hardware colemak keyboard just to have

To be fair, it went fast because I had two other projects to look at (see my first post here). They gave me a good jump start into AVR programming and also came with working circuit diagrams to learn from.

If you care to post the schematic, I can get that into a colour-shaded form (Colour blocks for pin groupings etc), pretty quickly. Probably into a downloadable PCB layout as well (I work for an electronics Retailer... handy sometimes!)

As msiegel wrote already, the schematic is on Github in PDF format, ready for direct download.

A PCB layout would be awesome! But keep in mind that this circuit does not support the trackpoint yet (that's why port A is completely unutilized in my version), so it may need to be extended later. I also didn't include jumper headers for config in the schematic. Still, a PCB layout for this schematic would be useful for those who don't need/want a trackpoint.

If you like, you can perhaps make a simplified version designed not to support trackpoints, by removing one of the shift registers and corresponding diodes, and routing the corresponding 8 pins to port A on the ATMEGA. A proper firmware could be made quickly. :wink:  Such a controller would also be useful for an IBM M4 (the version without a trackpoint).

I do have an older copy of Eagle somewhere, but I am using Win7 (If there is a *nix binary, I don't have it), so not sure if it works.  But I'll dig it out and see what happens.

There is Eagle for Linux. Haven't tried it in a long time, so I don't know how badly crippled the current test version is. Last time I checked, it had a limit on the maximum PCB size in the unregistered version, I think.

[lowpoly]

But keep in mind that this circuit does not support the trackpoint yet

What kind of trackpoint support do you plan (most if not all come as a ps/2 device)?

[Mnemonix]

What kind of trackpoint support do you plan (most if not all come as a ps/2 device)?

I'll try to do both, keyboard and mouse, over the same USB port. I know it's possible, but I don't know yet if the V-USB driver that I am using will be good enough. In case it's not, a dedicated MCU driving another USB port just for the mouse could be used, but I'd like to avoid that.

On the hardware side, a trackpoint is just a stick with four strain gauges attached. The resistance of the strain gauges need to be measured and transformed into mouse motions. On the original controller, there is a digital potentiometer that, presumably, is used to calibrate a Wheatstone bridge. I hope to be able to make a similar circuit and take meaningful measurements using the ATMEGA's A/D converters, but that will take a bit of experimentation.

Any hints are appreciated!

[JBert]

For the trackpoint: automatic (re)calibration and acceleration would be extremely nice. These are probably the most wanted features for non-IBM trackpoints.

[quadibloc]

Thanks. AIKON was the new name. Couldn't remember that. Here's another page in english:

http://www.otd.kr/bbs/board.php?bo_table=aikon_manual&wr_id=10

The first thing I noticed was the statement that client software for the keyboard doesn't work on 64-bit Windows. Client software?

Well, it is true that if the keyboard is programmable, it probably is desired to program it from the computer, and this is a special function which requires additional software. But that makes me think the keyboard might not be an exact plug-in replacement for an ordinary USB keyboard.

EDIT: Ah, I see. It's designed to be used with any keyboard, so because different keyboards have different matrices, it has to be programmed to start with.

[quadibloc]

I say we just slap an 8 core Parallax Propeller in there and call it good =P.

While the development board is $80, the chip itself - available in a 40-pin DIP version for convenient old-fashioned interfacing at the same price - is $7.99 in single-unit quantities ($7.49 if you buy 20).

Eight cores for eight dollars!!!

We live in amazing times...

[msiegel]

propeller also requires an external eprom :-/

edit: for the code

[inornate]

Thanks. AIKON was the new name. Couldn't remember that. Here's another page in english:

http://www.otd.kr/bbs/board.php?bo_table=aikon_manual&wr_id=10

The manual page is not completed yet.

The full circuit is also available, -
http://www.otd.kr/data/file/pj_LIMKB/1964092542_24157b90_Aikon28LIMKB29-SMD_Schematic.PNG

means, you can always build your own with relatively little budget - maybe under $5. (Anyway it needs ISP loader but it costs under 10$ if you try Serial port one. USB version is bit more expensive I think)

Aikon is totally reconfigurable and firmwares are still in progress.

[msiegel]

The manual page is not completed yet.

The full circuit is also available, -
http://www.otd.kr/data/file/pj_LIMKB/1964092542_24157b90_Aikon28LIMKB29-SMD_Schematic.PNG

means, you can always build your own with relatively little budget - maybe under $5. (Anyway it needs ISP loader but it costs under 10$ if you try Serial port one. USB version is bit more expensive I think)

Aikon is totally reconfigurable and firmwares are still in progress.

great!
the circuit is surprisingly simple.

edit: no pull-up resistors on this one either, guys. do we really not need them, or are they just being omitted for clarity because the circuit is all digital logic?

[inornate]

Super-simple version, Thanks to Aqua.

[inornate]

The first thing I noticed was the statement that client software for the keyboard doesn't work on 64-bit Windows. Client software?

Well, it is true that if the keyboard is programmable, it probably is desired to program it from the computer, and this is a special function which requires additional software. But that makes me think the keyboard might not be an exact plug-in replacement for an ordinary USB keyboard.

EDIT: Ah, I see. It's designed to be used with any keyboard, so because different keyboards have different matrices, it has to be programmed to start with.

Client only needs for configure its matrix.(means you need 32-bit XP(or vista) machine for its configuration NOTE : ONLY IN CONFIGURATION STEP)

After configuration, you can use Aikon-implemented keyboard in any computer environment.(Tested in Linux, Apple(with firmware beta 1.0.3), XP, Vista, 7, includes 64bit version)

[inornate]

great!
the circuit is surprisingly simple.

edit: no pull-up resistors on this one either, guys. do we really not need them, or are they just being omitted for clarity because the circuit is all digital logic?

Aikon uses internal pull-up registers integrated in AtMega chip.

[msiegel]

Aikon uses internal pull-up registers integrated in AtMega chip.

thank you

we've been discussing whether the internal pull-up resistors are strong enough. apparently, they are

[Mnemonix]

Super-simple version, Thanks to Aqua.

Ah, these circuits look familiar to me.  Looks a lot like what is used in Rump or Dulcimer. I guess then there are not too many ways to do this right on an AVR.
It won't work for an M4, though (19x9 matrix, but apparently AIKON offers 18x8 only).

Isn't AIKON going a lot into the direction that Talis had in mind when starting this thread?

Client only needs for configure its matrix.(means you need 32-bit XP(or vista) machine for its configuration NOTE : ONLY IN CONFIGURATION STEP)

Oh, so I couldn't even configure that thing.

Do they have source code for download somewhere? I tried downloading their 1.0.4 Beta firmware to have a look, but failed for the following reason:



Huh? Sorry, no Korean here...
They should really translate their site to English to get a broader audience; I've never stumbled across that project while googling for related stuff.

[inornate]

Ah, these circuits look familiar to me.  Looks a lot like what is used in Rump or Dulcimer. I guess then there are not too many ways to do this right on an AVR.
It won't work for an M4, though (19x9 matrix, but apparently AIKON offers 18x8 only).

Isn't AIKON going a lot into the direction that Talis had in mind when starting this thread?



Oh, so I couldn't even configure that thing.

Do they have source code for download somewhere? I tried downloading their 1.0.4 Beta firmware to have a look, but failed for the following reason:



Huh? Sorry, no Korean here...
They should really translate their site to English to get a broader audience; I've never stumbled across that project while googling for related stuff.

OOPS? I can download it normally.. That message is "Invalid operation".

I tried to give you as much as information in english (a least about Aikon)

Key informations(manual, download section) is offered in Eng (not all information-not completed. sorry. It needs really hard work. but I'm still trying)

anyway it's not offered as open source and we bought the V-USB license (so it's not need to be distributed as GPL). I'm really sorry about that but I'm second author of the its firmware and client and original author doesn't want its source be opened.

Anyway if you want the keyboard controller, and if you want the problem be simple(who don't care about authoring source code), Aikon can be a good alternative - key matrix is reconfigurable during use, 3 layers offered(FN key, Numlock key), and super easy keymapping sequence.

You can refer this video (about how easy to mapping it is)
http://www.youtube.com/watch?v=3qAIEpUoJjU

I'm still trying to make another version of keyboard controller (PS/2, supports true N-key rollover / or also offered with blocking algorithm, 4-layer selected by dip switch, 17*8 matrix). This will be opened to you guys. I promise.

[Mnemonix]

OOPS? I can download it normally.. That message is "Invalid operation".

Nevermind, seems to be a proxy problem. I can download the firmware by bypassing the proxy. Not much to see there, though!

anyway it's not offered as open source and we bought the V-USB license (so it's not need to be distributed as GPL).

What a pity.
Of course, it's your decision to keep the code closed and secret, and I am not intending to talk this out of you, but personally, I found it a lot easier to open up. It's just so convenient that people can point at problems and even fix them for you.

I'm really sorry about that but I'm second author of the its firmware and client and original author doesn't want its source be opened.

In this case, please s/they/you/g in my previous post. I didn't realize you are involved in the Aikon project.

Edit: By the way, is there a specific meaning to the word "Aikon"?

I'm still trying to make another version of keyboard controller (PS/2, supports true N-key rollover / or also offered with blocking algorithm, 4-layer selected by dip switch, 17*8 matrix). This will be opened to you guys. I promise.

Sounds great! I'm looking forward to see it then!

[Xichekolas]

Been following this thread closely the last few days.

I'm mainly interested because I'd love to experiment with different layouts, and having a drop in controller that I can just wire my switches to would be great.

I'm more of a programming guy, so I'll have to let you guys do all the difficult hardware stuff, but I was thinking about ways to make it easy for the end user to program.

My thought is that keyboards lend themselves naturally to an event-based model. You call each key an 'event' and define an action to be executed when that event happens. The actions come from a nice clean API of stuff the keyboard can do. An example:

Code: [Select]

esc :key11
alt :key18, :key811
shift :key15, :key85

capslock :key14 do
  toggle_led 1 # toggle first LED from on to off or vice versa
end

# shortcut for normal acting letter keys
q :key23
w :key24
e :key25

# or you can really remap things

# first create a new layer and key to activate it
create_layer :fn
fn :key31 do
  toggle_led_while_down 2
end

# now do some complicated mapping for this key
set :key42 do |key|
  # ever seen programmers dvorak?
  key = :!           # no modifiers
  key.shift = :1    # shift key is down
  key.shift.alt = :print_screen # shift and alt down

  # fn key is down (and we are in the fn layer)
  key.fn = :ctrl, :alt, :delete
end

I gather our little microcontroller isn't going to have enough memory/power to process something like this on the fly, but it would be trivial to generate whatever format was needed from a description like this (including binary formats). Using this single representation, you could generate mappings for various controllers, or xmodmap files, or whatever else.

So anyway, I have no idea if this is helpful or just redundant, since I haven't really seen how existing keyboard programming models work... but if there is any interest in creating something like this, I'd be happy to work on it. I'd just need some samples of whatever target code I need to generate. It shouldn't take too long... this is the kind of stuff I do for my paychecks.

As for getting what I generate onto the board, someone suggested putting some kind of microSD reader or something on the controller. That sounds good to me. Create a config like above, generate microcontroller code, put on microSD card, hit a button on bottom of keyboard to make it read new settings... something like that.

[talis]

thank you

we've been discussing whether the internal pull-up resistors are strong enough. apparently, they are

In some applications they will be, in some they may not.  There's really no reason not to include pads for them (or even include them at the cost of maybe $0.08 total) in case someone finds an application where they are necessary.  The actual hardware design will ultimately be fairly simple, with most of the complexity coming in the software design.

I'd like for anyone with any form of requirement to start adding them on the project page, so we can start on the process of uC selection (then everything will proceed from there).  The requirements really should be thought of as a wish list at this point (eg.  If I could have any controller, it would do x, y, and z).

Again, I'm not saying the Atmel chips aren't the right choice, I'd just like to go through the formal process of requirements gathering -> selection -> development to make sure nothing is missed.   It may turn out that some other device better meets the requirements, or some trade off between them.

[msiegel]

I'd just like to go through the formal process of requirements gathering -> selection -> development to make sure nothing is missed.   It may turn out that some other device better meets the requirements, or some trade off between them.

sounds good to me

i'll be working from the other end, using a teensy avr dev board and modifying mnemonix code to develop a capacitive-matrix version of the controller

[lowpoly]

I'd like for anyone with any form of requirement to start adding them on the project page

Done.

I just figured out that you have to be logged in to see the forum.

[JBert]

I'd like for anyone with any form of requirement to start adding them on the project page.

Where? I don't see anything special on this mod's wiki page.

[msiegel]

Where?

http://geekey.org/

[JBert]

Heh, I just noticed it was in his signature...
Seems I was getting so disillusioned by reading people's signatures that I stopped reading them.

[Mnemonix]

i'll be working from the other end, using a teensy avr dev board and modifying mnemonix code to develop a capacitive-matrix version of the controller

Cool! Did you order the older or the ++ version?
And do you think it will be hard interfacing with a capacitive matrix? What extra parts would you need for this?

[msiegel]

Cool! Did you order the older or the ++ version?
And do you think it will be hard interfacing with a capacitive matrix? What extra parts would you need for this?

i ordered the regular less expensive version, with 22 contacts... and also ordered an rgb led

i'm pretty sure it will require an oscillator, to generate an em field on the pads... possibly an op-amp to read the signal back (don't know how strong the signal is yet)... then either use on the on-chip adc or figure out some fast, simple way to measure the field strength.

calibration will be an interesting area

[talis]

i ordered the regular less expensive version, with 22 contacts... and also ordered an rgb led

i'm pretty sure it will require an oscillator, to generate an em field on the pads... possibly an op-amp to read the signal back (don't know how strong the signal is yet)... then either use on the on-chip adc or figure out some fast, simple way to measure the field strength.

calibration will be an interesting area

This is probably the best place to start : http://www.cypress.com/?docID=2192

[msiegel]

This is probably the best place to start : http://www.cypress.com/?docID=2192

thanks talis, that's great!

[Mnemonix]

My thought is that keyboards lend themselves naturally to an event-based model. You call each key an 'event' and define an action to be executed when that event happens. The actions come from a nice clean API of stuff the keyboard can do. An example:

OK, so this would be for the user defining key maps, macros, and so on?
I can see some inconsistencies in the example, but I suppose this is just an idea for how it could be written down, right? Maybe the forum on http://geekey.org/ is a more appropriate place for discussing the details, though...

I gather our little microcontroller isn't going to have enough memory/power to process something like this on the fly, but it would be trivial to generate whatever format was needed from a description like this (including binary formats). Using this single representation, you could generate mappings for various controllers, or xmodmap files, or whatever else.

Basically, this is what I am doing in my own firmware already, but in a more limited way (e.g., no macros). There is a config file describing the keyboard (row/column-to-key assignments), and there are files that describe how to transform from the generic QWERTY map to anything else. A Python script takes these and produces a C structure that is used in the microcontroller program for processing the keystrokes.
At the moment, this key map structure is hardcoded into the firmware, but reading alternative key maps from EEPROM can be done easily. Maybe I can do that over the weekend...

So anyway, I have no idea if this is helpful or just redundant, since I haven't really seen how existing keyboard programming models work...

I haven't seen those either, but I guess you are supposed to use some GUI program for programming them. I wouldn't want that.

As for getting what I generate onto the board, someone suggested putting some kind of microSD reader or something on the controller. That sounds good to me. Create a config like above, generate microcontroller code, put on microSD card, hit a button on bottom of keyboard to make it read new settings... something like that.

Generating MCU code might not work since not all MCUs can execute code from RAM, but only from their flash memories. Therefore, the generated code would have to be some bytecode for a virtual machine to be interpreted by the MCU, so the MCU needs to run a virtual machine interpreter.
This is doable, provided the VM is kept simple.

[Shawn Stanford]

Oh, man: this stuff sounds so cool! I wish I had the background and time to get involved...

[msiegel]

another source for development components -- preprogrammed avr microcontrollers from Evil Mad Science

$5

http://evilmadscience.com/partsmenu/132

[Mnemonix]

For the record: I have added support for user-defined key maps to my keyboard controller firmware.
You can generate key map files from keyboard definition files + transformation files, and upload the result to the keyboard's EEPROM using a small command line tool.
Key maps can be selected via jumpers: up to 4 user-defined maps in 512 bytes of EEPROM, plus the default QWERTY map in the firmware image.

Basically, this gives you Colemak, Dvorak, etc. in hardware. :smile:

[DreymaR]

Sounds nice.

Maybe it's been covered somewhere in the previous pages that I didn't see, but: Could you make a QIDO-type adapter with this (preferably USB-to-USB these days, but there are of course other options)? Because that's what I'd love to have, without paying the full QIDO price (and there's no 'QICO' for colemak yet that I'm aware of).

[JBert]

A custom "QICO" would only work when your keyboard doesn't contain an USB hub, otherwise it might be hard but possible to make it with only bit-stuffing.

[Mnemonix]

Could you make a QIDO-type adapter with this (preferably USB-to-USB these days, but there are of course other options)?

I thought a bit about this idea... Unfortunately, I think USB-to-USB cannot be done using a single ATMEGA, at least not in software.

The task of such an adapter seems trivial: forward any traffic between computer and keyboard, just rewrite the packets containing the keystrokes. This, however, requires the adapter to operate as a USB hub (or, as a hack, some kind of invisible bridge), and this is what makes it non-trivial. The keycode translation itself would be embarrassingly easy, but I don't think an ATMEGA has enough compute power to act as a USB device and a host at the same time.
A way out might be to use an external USB host controller chip, hook it up to the microcontroller, and use it to interface with the keyboard. But I am not really an expert on this field, so I don't have any idea which chip to choose.

On the other hand, a PS/2-to-USB converter with built-in keycode translation seems more feasible since PS/2 is a lot simpler than USB. Then again, there must be something hard about designing such a converter, given all those crap converters that you can buy today.

I guess the quickest way to get a QICO would be to ask the QIDO guys to make one. All they would have to do is to exchange the key maps in their firmware. Maybe they are not aware of Colemak?

[Mnemonix]

A custom "QICO" would only work when your keyboard doesn't contain an USB hub, otherwise it might be hard but possible to make it with only bit-stuffing.

Hm, that's right. A USB hub on the keyboard would make things even more complicated.

[DreymaR]

Mnemonix: Thanks for the answers - a bit clearer now.

Stuff USB hubs. I won't need one, and a lot of boards don't have them so I'm not going to make that into a problem.

The USB controller thing is worse I guess. However, even if the current PS/2-to-USB adapters are of varying quality I think I could live with using one. So a PS/2-to-USB piece would do the job. I could then just hook up any USB boards with one of those crappy USB-to-PS/2 thingys and plug that into the converter and it'd work well enough for my uses. I also have a lot of PS/2 boards so in fact it'd be very useful in that respect!

However, couldn't the USB controller inside the USB keyboard handle all the USB device stuff and the converter only intercept the scan codes and let the rest pass through?

Sure, the QIDO people know about Colemak from several people and they may well be on their way to making a QICO... if they think it'll pay off. But did you see the price tag on that QIDO? Making your own might cost as much but then at least I'd have the new knowledge and pride to show for it!

[Mnemonix]

The USB controller thing is worse I guess. However, even if the current PS/2-to-USB adapters are of varying quality I think I could live with using one. So a PS/2-to-USB piece would do the job. I could then just hook up any USB boards with one of those crappy USB-to-PS/2 thingys and plug that into the converter and it'd work well enough for my uses. I also have a lot of PS/2 boards so in fact it'd be very useful in that respect!

USB-to-PS/2 converters? Never had to use one of those, but this is probably the cheapest way to go then.

However, couldn't the USB controller inside the USB keyboard handle all the USB device stuff and the converter only intercept the scan codes and let the rest pass through?

I guess you have something like a USB protocol sniffer in mind, which is what I had in mind when writing "some kind of invisible bridge". It would have to capture all communication between host and keyboard and repeat all it sees. But it would also need to decode the USB protocol, filter out the reports sent by the keyboard, modify those, encode the packet back to USB, etc.

Such a device could actually work, but I doubt it would be easy. It would be half device, half host, but invisible on the bus. Being invisible makes it also difficult to communicate with it, for instance, for updating its firmware. It would also introduce delays not expected by neither host nor keyboard, probably causing some extra trouble.

Sure, the QIDO people know about Colemak from several people and they may well be on their way to making a QICO... if they think it'll pay off. But did you see the price tag on that QIDO? Making your own might cost as much but then at least I'd have the new knowledge and pride to show for it!

It would be cool if they could make a QIAO ("anything-out") which allows the user to define his own mappings. The high price may then be a bit more acceptable.
They could still use some competition... :wink:

[Mnemonix]

Upgraded my firmware once again... There is a command mode now, activated by hitting Scroll Lock.
Key maps are not selected by jumper anymore, but by pressing a number key between 0 and 9 in command mode. Thus, key maps can be exchanged quickly at any time now. The selection of the key map is stored in EEPROM so that it is not lost during power cycles.

[inornate]

I'm glad to introduce my project - ps2avr.

It's available now at
https://sourceforge.net/projects/ps2avr/

Also some movies at
* LED Fading action
http://www.youtube.com/watch?v=qMCEfqjF7LY

* Rollover support
http://www.youtube.com/watch?v=GjPz_o9pHXI

* repeat rate
http://www.youtube.com/watch?v=I7puVuMktzk

Have fun & any collaboration will be appreciated.

[Mnemonix]

I'm glad to introduce my project - ps2avr.

It's available now at
https://sourceforge.net/projects/ps2avr/

Nice, thanks for sharing!

It is hard to tell from the videos (for me it is, at least): which keyboard do you use your firmware with?

[inornate]

It is hard to tell from the videos (for me it is, at least): which keyboard do you use your firmware with?

356CL Dark Gray Edition, full-custom built keyboard from OTD, Korea. (not commercial one)

[lowpoly]

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

Unrelated, beside two personal projects that were or are being run independently (Mnemonix, inornate) this project looks stalled. Before we could go to the next step (uC family selection), someone had to go through all the requirements posted here and on geekey.org and collect and condense them. Which I did.

I posted a new thread on geekey.org with the collected requirments here:

http://geekey.org/forum/viewthread.php?thread_id=3

Let me add the personal opinion that the traffic on geekey.org is too little ATM which may have added to the stalling situation we're in. I'm sure we will need it soon, it may just be too early yet. So I'll post the requirements here too and invite everybody to post here as well. If my time allows it I'll go through both threads again and do another summary.

Here are the collected requirments (yes, I may have added one or two things while doing this :-) ):

Hardware (core):

• capacitive switch support
• must not require special OS drivers
• ability to operate with only power supplied over the selected bus interface
• hardware switch for programming (to avoid hacking)
• generally large device family (to allow simplification for commercialization, or expansion for big projects)
• minimum number of rows and columns: 19x9
• the hardware output of this project should also be relatively easy to hook up to archaic hardware (e.g. Commodore 64/128)
• re-flashing of program ROM with no specialized tools
• cheap hardware possible for volume production
• while most keyboards are enclosed by a single piece of plastic, the developed solution should be designed to allow multi-piece keyboards, e.g.completely separate left half, right half, and ten-key modules that can be placed as desired
• standardized matrix interface that would make it easy to interface with most current keyboards (through separate interface cards probably), or work into new custom designs

Hardware (extended):

• a sD/usD card reader to store layouts
• LED support, including RGB LEDs and one LED per switch
• ability to drive up to 6 groups of backlight LEDs
• ability to drive standard keyboard LEDs
• some sort of visual feedback interface provided, i.e. LED/LCD segment display
• PS/2 pass through, that can be used for onboard PS/2 based pointing devices, or separate keyboards if controller is used in a macro pad application
• ability for PS/2 pass through to operate with USB host interface (basically built in PS/2 -> USB conversion)
• trackpoint support, at least 3 mouse buttons
• USB hub

Protocols:

• ability to select between PS/2, USB, (other) communications protocols
• ps/2 support should use the usb cable with a passive usb->ps/2 adapter, auto selection of connection
• Bluetooth / Bluetooth HID interface / Bluetooth wireless

Layers:

• at least five layers (for ex. Qwerty, Colemak, cursor movement, frequent words, special characters)
• must support both hardware and software locking switches for layers (for ex. to switch between Qwerty and Colemak)
• ability to make any key (or key combo) on the keyboard either a locking or a non-locking modifier
• fairly large number of allowable over-riding layers, as well as a small number of compound layers
• ability to build up to 3 compound layers (x, y, or x+y), and any number of non-compound layers with the ability to set priorities on layers
• encrypted layer storage with master password to unlock a layer

Programming:

• programming possible without external programmer software
• if software-less programming, layout should be downloadable from keyboard to pc and restorable (for ex. through SD card storage)
• programming possible with external programmer software
• multi-platform sdk for this programming software so it's possible to write a proprietary programmer
• firmware upgradeable, must not brick
• ability to program over both PS/2 and USB
• fairly basic bootloader, that will allow re-programing of the core code using the flash card interface
• public key certification to ensure that the firmware people download from some site is not malicious
• ability to re-program ROM, key layouts, macros, and overall behavior under any host operating system
• anti-ghosting optional (some 'boards may have diodes)
• if possible: emulate a mouse interface to send scroll wheel or even mouse movement events. (Only feasible with USB interface. You can add an extra endpoint which appears to the PC as a regular mouse)
• firmware features should not rely on specific keys (tenkeyless keyboards for ex.!)
• decoupling of key map and layout map possible
• if there's going to be ample flash memory on the controller chip, it would be smart to have a self-calibration procedure for key debouncing
• sticky modifiers (sticky control key feature)
• macro playback with humanizing randomization added (randomized delays)
• Ability to program the matrix/layers without needing development tools/source modifications.
• layout selection (i.e.) remapping character keys to use "native scancodes" (regular ANSI/US layout), "colemak-qwerty" (hardware-remapped scan codes), "dvorak-qwerty", "colemak-azerty", ...

Development tools (hardware and software):

• use all open source/free (as in speech) software development tools
• simple / inexpensive to build at home using "cheap" development tools (eg no $400 ICDs to program the chips)
• firmware should be written mainly in C, not ASM or proprietary languages

Other:

• commercial use possible (= find a license we all can live with)
• ability to small run produce the boards cheaply
• well documented, easily extensible, modifiable etc.

[lowpoly]

uC family decision next. We will probably need a spreadsheet for this. Rows: requirements, Columns: chip families and members.

So we need a list of chips that may fit the requirements.

[keyb_gr]

Hardware (core):

• capacitive switch support

Is it even clear how a capacitive keyboard normally operates? Not really to me at least. I am under the impression that there is more than one way of doing it...

[cb951303]

I would suggest a simple eeprom (couple of MBs)for the layout storing instead of SD because
1. SD is totally overkill for this purpose
2. AFAIK it has a restrictive license and the developer may have to sign an NDA to get the full spec. Not exactly in the spirit of open source.

for uC, I worked with Atmel AVR and PIC in the past. Atmel almost wins in every aspect but mostly in development tool support. It has pretty good GCC support.
and also, as stated before, there is V-USB which implements USB HID in software for most AVR chips.


EDIT: BTW there is no AVR chip other then XMEGA (fairly new series) that has  enough I/O pins for a 19x9 matrix + other things if we decide to use V-USB.
There is always the USB AVR series though.

Also note that V-USB requires a fee for commercial use. It's free for other purposes.

[lowpoly]

Is it even clear how a capacitive keyboard normally operates?

We probably have to go through some iterations until most requirements are 'checked' in the spreadsheet. Some never will and will need some sort of extension (or be dropped if there isn't enough interest, which should be another column).

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

[lowpoly]

I would suggest a simple eeprom (couple of MBs)for the layout storing instead of SD because
1. SD is totally overkill for this purpose
2. AFAIK it has a restrictive license and the developer may have to sign an NDA to get the full spec. Not exactly in the spirit of open source.

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.

I'm in EEPROM camp but having both can't hurt. The NDA you mention can collide with the open source requirement but maybe the full spec isn't necessary?

[Mnemonix]

uC family decision next.

Thanks for pushing this again! I thought Talis would show up one day to do this.

Is it even clear how a capacitive keyboard normally operates? Not really to me at least. I am under the impression that there is more than one way of doing it...

There are multiple ways to measure capacitance, which is what needs to be done here. Talis once posted a link to a PDF that explains how capacitive switches are supposed to work. The figure on the first page pretty much says it all (think of the finger as some part of the key): you need to be able to decide between small and big capacitance. Which method you are going to use is up to you.

I don't know which way is best, or which would work at all. Msiegel is doing some research on this area for his Model F mod. Maybe he has found a good method already?

I would suggest a simple eeprom (couple of MBs)for the layout storing instead of SD because
1. SD is totally overkill for this purpose
2. AFAIK it has a restrictive license and the developer may have to sign an NDA to get the full spec. Not exactly in the spirit of open source.

I also think its overkill, but this is an anything-goes wish list. Signing an NDA would be unacceptable though, IMHO.

EDIT: BTW there is no AVR chip other then XMEGA (fairly new series) that has  enough I/O pins for a 19x9 matrix + other things if we decide to use V-USB.
There is always the USB AVR series though.

Yes, I ran into that problem when building a controller for an M4-1. I used two external shift registers (74164) to drive 16 of the matrix rows while using only two I/O ports on the AVR.

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...

[cb951303]

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.

but what will you do after the data exchange. how will you tell the keyboard to use a certain layout on the SD card without an external software (I may be missing a point)? but if an external software is unavoidable we might very well include a simple data exchange capability to that software. Something like a very simple multi purpose command line tool maybe?

I'm in EEPROM camp but having both can't hurt. The NDA you mention can collide with the open source requirement but maybe the full spec isn't necessary?

yes it's certainly possible. I think there is a lite spec that doesn't require an NDA but I'm not sure if it's totally free to use either.

[msiegel]

Msiegel is doing some research on this area for his Model F mod. Maybe he has found a good method already?

IBM patents describe a method of driving column lines with digital pulses, and seeing if the pulses couple (through the fly-plate and sensor pads) to row lines.

according to formulas in one of the patents, a current of ~1-10 uA appears on the sense lines when pulses come through. the inputs and outputs to the microcontroller would seem to be all digital; there's some analog amplification and thresholding in between.

i'll be starting electronics experiments soon