Blox - Modular Keyboard

[MOZ]

So we have the GH60, which seems on the path of greatness.

samwisekoi started the GH75, which also looks very impressive. It now is the time for GH100+, a full size and maybe even larger (122-terminal style) open source community keyboard.

What I am thinking is of a open source keyboard based on the GH60 as the base and extending on it with modules, which can be directly connected via a connector or ribbon cables. There will be 5 extendable modules:

• Arrow + navigation cluster - similar to the phantom style cluster, this would have 3x5 switch matrix, which can be used to create any layout you want, such as the standard arrow + nav cluster or the "+" style on the terminal Model F.
• Numpad cluster - Standard numpad cluster with 4x5 switch matrix, with 2u switch positions in normal +, Enter, and 0.
• Esc + 12 F function row - The standard function row with Esc, and F1-F12
• 24 F function rows - 12x2 switch matrix, Model F terminal style 24 function keys style matrix
• 10 key macro extension - 2x5 switch matrix, this again is similar to the Model F terminal style 2x5 matrix on the left side.

An added advantage with extendable modules is that you can play around with the positions of the modules, such as have arrow cluster on the left and the 2x5 macro module on the right side.

So what do you guys think? I have absolutely no idea on how to develop PCB circuits, however I can help with anything else.

So what say guys?
UPDATE - 22-Jan-2014

Thanks to regack who is helping me learn PCB designing this project is a go. I've also changed the name to Blox.


Features I am planning
- Support Alps as well as MX switches (Plate and PCB)
- Full LED support^[1]
- PCB mounted Stabs
- All components SMD^[2]
- SMD diodes, as well as through-hole diodes (Inside switches only)
- SMD and through-hole resistors for the LEDs
^[1] Now there are three ways (That I am aware of) to setup the LEDs,
1. All in parallel, all LEDs connected to ground and power via transistor to control brightness and effect such as fading, reactive, etc. However this will not support individual control over each LED. Each LED would require its own resistor.
2. Series and parallel, like parallel but with 3 LEDs in series and groups like these in parallel. Less resistors required.
3. LED Matrix - The best method, LEDs in a Matrix like keys, requires large number of pins to controller, no individual resistor required, just one for each column.

I will go with the 1st, with the disadvantage that it would require a resistor for each LED and you can't control them individually as that would require another controller or expansion IC, since this is my first project, I want to take it easy and not sure if there is enough demand for individually controlled LEDs. Method 2 is just messy so i chose not to use it.

^[2] Atleast the controller parts, so it is easy to manufacture with PnP and also keeps a lower profile, and I find things are more organised. There will be option of through-hole for things that may require changing such as diodes/resistors.


The blox
0. Central block - I plan to have a central 60% (Base) similar to the GH60 and similar flexibility in layouts, there will then be modules that can be connected using ribbon cables.
1. 5x3 block - This is the nav+arrow part on the Phantom, so you can have it in a traditional nav cluster and arrow or use the whole matrix, or something like on the terminal keyboards (Nav cluster and fours arrows with select keys in center). Can be installed on either side of the base. Now, when installing this module next to the base either as PCB mount or plate mounted, user can choose if they want to have it right next to the their base (No space between them) or with a 0.25u (u = 1 Cherry unit = 19.05mm = 0.75") gap like on a usual TKL board given the adequate mounting holes on the case and adequate plate.
2. 6(5)x2 block - 2x6 block with one row removable. This is  the 2x5 keys on the left on the 122-Terminal keyboard or KMAC-MINI. Again complete flexibility on which side and with how much gap one wants to maintain between the base and the module when installing it, since this is true for all modules, I will not be re-iterating it again for the other modules.
3. 6(5)x1 block - 1x6 block with one key removable. This is the 1x5 on the MX-MINI.
4. 1x15 block - Function row that will support 15x1 configuration as well as Esc & F1-F12. This will not have the Scroll Lock/Pause/Print Screen.
5. 1x3 block - These are the Scroll Lock/Pause/Print Screen keys.
6. 2x12 block - This is the 24 Function row from the 122-Terminal.
7. 5x4 block - Your numpad, will also have have the 2x keys on 0, +, Enter.
8. 1x4 block - This is for four keys above the numpad.


Interaction between blox

This is simple schematic of how things would connect



I've started off easy with designing the 3x5, 2x5, 1x5 modules first, I will then move onto the other ones.

[MOZ]

Reserved

[Photekq]

We're missing a GH80. A TKL PCB with full LED, SMD, usb port etc. Phantom is great but not perfect.

I'm going to try and learn how to design a PCB to try and make the above happen (but it ain't easy).

Can't say I'd use a GH100+ but I'm sure loads of people would.

[SpAmRaY]

Why not!

Modular! 

[MOZ]

We're missing a GH80. A TKL PCB with full LED, SMD, usb port etc. Phantom is great but not perfect.

I'm going to try and learn how to design a PCB to try and make the above happen (but it ain't easy).

Can't say I'd use a GH100+ but I'm sure loads of people would.

I agree regarding the Phantom, what we need on it based on priority for me:
1. PCB Stabs (Way ahead of anything else)
3. Easily accesible USB connector
2. SMD
3. Integrated controller
4. LEDs

Did you notice that with this design we can have a GH60 as well as a GH80, since it is modular.

[Photekq]

Oh yeah PCB stabs and PCB-mount switch pin holes for sure. PCB stabs are the best

And hold on.. I don't fully understand the modular concept. Are you telling me komar designed the GH60 so that you can simply add all this stuff on?

[MOZ]

Oh yeah PCB stabs and PCB-mount switch pin holes for sure. PCB stabs are the best

And hold on.. I don't fully understand the modular concept. Are you telling me komar designed the GH60 so that you can simply add all this stuff on?

There is some extension available on the current GH60, but not as much as we want for this case I think. However we can extend the current GH60, to make it as modular, since it is open source, as long as we give due credit to the original GH60 team, we should be fine.

[Photekq]

There is some extension available on the current GH60, but not as much as we want for this case I think. However we can extend the current GH60, to make it as modular, since it is open source, as long as we give due credit to the original GH60 team, we should be fine.

Ah I see.

[regack]

I started working on a 77key layout, but I sort of dropped it when trying to work out some LED arrangements on one of my other projects... then I sort of disappeared into a black hole for about 6 months.



I'll have to keep an eye on this

[MOZ]

I started working on a 77key layout, but I sort of dropped it when trying to work out some LED arrangements on one of my other projects... then I sort of disappeared into a black hole for about 6 months.

Show Image

I'll have to keep an eye on this :D

I hear you make beautiful PCBs :)

[Melvang]

For this GH100+ what would you guys think of the possibility of an orbweaver type module on the left side.  Say 4x3 or 4x4 matrix plus at least a couple thumb buttons IE mini ergo dox to the left of the alphanumerics.

This idea came from my wifes keyboard which is this but make the left side more cherry matrix friendly.  the rest of it seems to be a fairly standard 75% layout.

[MOZ]

For this GH100+ what would you guys think of the possibility of an orbweaver type module on the left side.  Say 4x3 or 4x4 matrix plus at least a couple thumb buttons IE mini ergo dox to the left of the alphanumerics.

This idea came from my wifes keyboard which is this but make the left side more cherry matrix friendly.  the rest of it seems to be a fairly standard 75% layout.

Would be possible and I can understand that gamers might appreciate this.

[Moosecraft]

We're missing a GH80. A TKL PCB with full LED, SMD, usb port etc. Phantom is great but not perfect.

I'm going to try and learn how to design a PCB to try and make the above happen (but it ain't easy).

Can't say I'd use a GH100+ but I'm sure loads of people would.

I would be more into a GH80 than a GH100+ aswell

[MOZ]

We're missing a GH80. A TKL PCB with full LED, SMD, usb port etc. Phantom is great but not perfect.

I'm going to try and learn how to design a PCB to try and make the above happen (but it ain't easy).

Can't say I'd use a GH100+ but I'm sure loads of people would.

I would be more into a GH80 than a GH100+ aswell

I'm into neither, I am an ErgoDox person, but that is beside the point when trying to make something for the community.

[MOZ]

The interest for this is too damn low

[pasph]

Interestred in regack's 77key, maybe in lefty version

[tricheboars]

i would be interested in this if i could find terminal sets for caps. the only descent set that comes to mind is the R4 SPH SA Terminal set. 

plus this community does seem to be obsessed with smaller and smaller boards (guilty as charged) or ergo.

[MOZ]

i would be interested in this if i could find terminal sets for caps. the only descent set that comes to mind is the R4 SPH SA Terminal set. 

plus this community does seem to be obsessed with smaller and smaller boards (guilty as charged) or ergo.

I am an ergo fan, but this is one for the collection.

[Niomosy]

I'm not sure it's so much that the community is that fond of smaller keyboards that a large keyboard wouldn't sell.  It's probably more that there is more availability on full size keyboards.  Though I do like the idea of having even more keys for some customization.  It could come in handy for any number of things.

Now all we need is the GH keyboard similar to an MS Ergo and I'm set (ie. tented, single case, no thumb cluster, FX row, and all keys in their regular locations).

[Melvang]

I'm not sure it's so much that the community is that fond of smaller keyboards that a large keyboard wouldn't sell.  It's probably more that there is more availability on full size keyboards.  Though I do like the idea of having even more keys for some customization.  It could come in handy for any number of things.

Now all we need is the GH keyboard similar to an MS Ergo and I'm set (ie. tented, single case, no thumb cluster, FX row, and all keys in their regular locations).

^^^ This

[jdcarpe]

How did I miss this thread?

You mean something like this, that I designed a while back?

[metalliqaz]

That is all together too many keys )

[Melvang]

How did I miss this thread?

You mean something like this, that I designed a while back?

Show Image

Is there even that many functions on a windoze PC without macro?

[Photoelectric]

That is all together too many keys )

Super serious gaming macros that you reach with your left elbow, while your feet are on some clicky pedals to make more macro combos.  Totally legit!

[Melvang]

That is all together too many keys )

Super serious gaming macros that you reach with your left elbow, while your feet are on some clicky pedals to make more macro combos.  Totally legit!

Don't forget the switches that are on each side and behind your head.

[MOZ]

Haha, the idea is to have it modular, so you can make anything layout you want, a keyfest like the one jdcarpe posted or just keep it to a 60%, or a TKL, any layout one wants.

I know regack has been exploring on this front, I will be designing some PCBs myself this winter break after my exams, so I am extremely thankful to him for all his efforts so far.

BTW, I will try to design PCBs so they support MX as well as alps switches with Cherry PCB stabs.

[kektr0city]

Is N-Key Rollover something that could be built into this kind of design?

[MOZ]

Hopefully yes.

[IvanIvanovich]

I want this:

Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.

[MOZ]

When this gets done, it will support layouts like the GH60 and PCB mounted switches cause we know how much Ivan loves those.

[IvanIvanovich]

Yeah basically take the GH60 and add more switch on bottom row for proper JIS, and add the functions and numpad on the side. Done.

[jdcarpe]

I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.

Sorry, but you can only have this:



Bwahahahaha

[IvanIvanovich]

That's ok too. )

[SpAmRaY]

I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.

Sorry, but you can only have this:

Show Image

Bwahahahaha

why not wireless modules....that could all be rearranged on the desk?

[thegagne]

Ok, taking another stab at the modular idea...

Does the ATmega32u4 support that kind of idea? What are it's limitations? Assuming the GH60 is not a suitable host in it's current revision, could it be revised into say, GH60+ to be extensible with ribbon cables? Or maybe each module has it's own controller, and you simply use a USB hub to connect them all?

[MOZ]

Still a lot to do. The two ideas are:
1. Separate controller on each module and some way to have them connected to a base module and recognize each module with a unique ID
2. Base module and then using I2C and I/O controller like the Ergodox.

[agodinhost]

interesting
+1 to modularity
+1 to I2C
I promissed to myself to finish my own projects before asking to help in any other initiative ...
gosh!!!
kinda swamped here

[justnits]

I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.

+1 for this! except the Function keys are grey too for the AT feel 
sometimes, i wonder if we are going backwards...

[MOZ]

Thanks to regack who is helping me learn PCB designing, this project is a go. I've also changed the name to Blox.

Updated the OP with new information. Feedback, critic, suggestions, corrections, assistance are more than welcome.

[bueller]

I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.

This with Pure mods would be my dream.

[MOZ]

I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.

This with Pure mods would be my dream.

Hmm, let's see, 5x2--Base--Numpad, TADA!

[jdcarpe]

I don't know whether people will "get it" or not. But I love it! So exited that this is finally coming together, MOZ.

[moonexe]

I want... A tenkeyless G80-like layout. So I can make custom cases and be awesome.

[MOZ]

I don't know whether people will "get it" or not. But I love it! So exited that this is finally coming together, MOZ.

By "get it", do you mean:
1. Lack of clear information, if this, I am willing to sort out any doubts
2. This project will reach fruition, I can't comment on this, but I will give it my best shot
3. Buy it, well it will be an open source project and a GB or anything of that sort is the last thing on my mind
4. Understand the concept, which I think is most likely what you meant, the crowd on GH is one of the most intelligent I've seen, so they should. In case they don't, remember, in one way we are working at "unit" level with this project, so once all the blox are done, we can easily combine them onto one PCB, without any problem at all and have that design ready for production; just like computers, those that "get it", assemble their own system as it offers more choice and is generally superior and customised, those that do not, buy preassembled ones.

[SpAmRaY]

I don't know whether people will "get it" or not. But I love it! So exited that this is finally coming together, MOZ.

By "get it", do you mean:
1. Lack of clear information, if this, I am willing to sort out any doubts
2. This project will reach fruition, I can't comment on this, but I will give it my best shot
3. Buy it, well it will be an open source project and a GB or anything of that sort is the last thing on my mind
4. Understand the concept, which I think is most likely what you meant, the crowd on GH is one of the most intelligent I've seen, so they should. In case they don't, remember, in one way we are working at "unit" level with this project, so once all the blox are done, we can easily combine them onto one PCB, without any problem at all and have that design ready for production; just like computers, those that "get it", assemble their own system as it offers more choice and is generally superior and customised, those that do not, buy preassembled ones.

So your going to make all the different case options to go with all possible combinations

[MOZ]

So your going to make all the different case options to go with all possible combinations

Never.

[SpAmRaY]

So your going to make all the different case options to go with all possible combinations

Never.

So without cases, whats the point?

[moonexe]

So without cases, whats the point?

Make it! that's half the fun!

[MOZ]

So without cases, whats the point?

Will make for the common ones

[OldDataHands]

Hi MOZ,

Before you go too far down this road you should evaluate
the scan rate you'll be able to achieve over I2C. With the
I2C I/O eXpander (IOX) @100kHz in my 5-row switch
matrix I'm only able to complete a scan every ~5.2ms.

If you have 3 IOXs and end up at a 15ms scan rate...
well I don't think that's fast enough. You'll have to see
if you've added too much capacitance with 6 connectors
, 3 cables, and 3 slaves to run at 400kHz - which is the
max that the 32U4 supports.

Maybe you'll end up deciding that the 32u4 isn't an option,
instead opting for a micro with more I2C busses, or more
I/O pins so that you can have one matrix and connect your
blox with ribbons rather than I2C...

Regarding lighting:  The reason to stack 3 LEDs in series
with one resistor is that you might be able to drive all 3
with the same 10mA rather than using 30mA to do the job.
no big deal either way if you only have 3 total, but if you
have 60, then you've used too much current for normal
USB if each is driven individually.

You should also consider the AS1130:
http://www.ams.com/eng/content/view/download/13457

and possibly the WS2812: https://www.sparkfun.com/products/11821
for lighting solutions as this would be hugely flexible...

[regack]

and possibly the WS2812: https://www.sparkfun.com/products/11821
for lighting solutions as this would be hugely flexible...

There's actually a WS2812b which is even nicer with only a single vcc & ground pin (so 4 connections, instead of 6).  I've been playing with some of these.

[Findecanor]

Still a lot to do. The two ideas are:
1. Separate controller on each module and some way to have them connected to a base module and recognize each module with a unique ID
2. Base module and then using I2C and I/O controller like the Ergodox.

A while ago, I worked a little on a similar idea: a breakaway keyboard that I called the "ErgoHack". "Ergo" because it was split, and "Hack" because you would break or cut away (using a hacksaw) the parts of the PCB that you did not want or wanted to relocate somewhere else. If you wanted to relocate a module, you would solder a ribbon cable from the main board to that module.
However, taking a hacksaw to a PCB made of fibreglass is something that I learned not to encourage: it is very unhealthy to inhale the dust and I don't want to cause that.

Instead of using I/O expanders, I designed each module to own a part of a single matrix (for each hand, though, because it was split). Each sub-matrix was as tight a square as possible within its larger matrix so as to require as few lines as possible. The smallest unit was 2×2: a 2×2 matrix needs four lines, which are as many as are required for I2C (+V, GND, D+, D-).

You should know that the MCP23018 does not have general-purpose I/O pins like the AVRs. There are only eight lines for strobing and eight lines for sensing.
I think also that for a smaller matrix, you should look into using smaller I/O expanders.

[MOZ]

Before you go too far down this road you should evaluate the scan rate you'll be able to achieve over I2C. With the I2C I/O eXpander (IOX) @100kHz in my 5-row switch matrix I'm only able to complete a scan every ~5.2ms. .....

If you have 3 IOXs and end up at a 15ms scan rate...well I don't think that's fast enough. You'll have to see if you've added too much capacitance with 6 connectors , 3 cables, and 3 slaves to run at 400kHz - which is the max that the 32U4 supports.

Maybe you'll end up deciding that the 32u4 isn't an option, instead opting for a micro with more I2C busses

I'm planning to maybe use this MCU instead: NXP LPC11U37FBD48/401. The advantage is the FM+ I2C bus. If I do make the switch, I will then also be using the PCA9670/71/74/75 IOX to utilise the 1MHz I2C bus, the added advantage is that the AS1115/17/30 are all 1Mhz compatible. The FM+ allows capacitance of upto 400pF, increased drive current. Since everything is contained in a small area, there isn't much distance so hopefully there isn't too much capacitance that we can't run it at 1Mhz at the allowed 400pF, if in the case there is, we can always use the PCA9601/05/46 buffers/repeaters. A single PCA9601 alone can increase the allowed capacitance by a factor of 10, so 4 nF without introducing too much delay.

or more I/O pins so that you can have one matrix and connect your blox with ribbons rather than I2C...

I do no want to use too many ribbon cables for extension as it provides multiple issues such as complexity, large number of solder points, more error prone, more tracks to draw up on PCB.

You should also consider the AS1130: http://www.ams.com/eng/content/view/download/13457

That is a very interesting LED controller and one that I am impressed with immensely. Thanks a lot. I also liked the AS1115/17 for driving LED as well as keyscanning for smaller blox upto 16/8 inputs respectively.

[MOZ]

A while ago, I worked a little on a similar idea: a breakaway keyboard that I called the "ErgoHack". "Ergo" because it was split, and "Hack" because you would break or cut away (using a hacksaw) the parts of the PCB that you did not want or wanted to relocate somewhere else. If you wanted to relocate a module, you would solder a ribbon cable from the main board to that module.
However, taking a hacksaw to a PCB made of fibreglass is something that I learned not to encourage: it is very unhealthy to inhale the dust and I don't want to cause that.

Yeah, everything is a module, the only breakaway is the 6(5)x2 and 6(5)x1, which I may decide to also just go with separate PCBs altogether.

Instead of using I/O expanders, I designed each module to own a part of a single matrix (for each hand, though, because it was split). Each sub-matrix was as tight a square as possible within its larger matrix so as to require as few lines as possible. The smallest unit was 2×2: a 2×2 matrix needs four lines, which are as many as are required for I2C (+V, GND, D+, D-).

I sort of maybe get what you are saying and sort of don't as well,  so could you elaborate a bit more, maybe a diagram or something, as I am definitely interested in the various options that are out there.

You should know that the MCP23018 does not have general-purpose I/O pins like the AVRs. There are only eight lines for strobing and eight lines for sensing.
I think also that for a smaller matrix, you should look into using smaller I/O expanders.

Yeah, I'm now leaning towards these components:
Controller:
-- NXP LPC11U37FBD48/401
I/O expanders:
-- NXP PCA9674 - 8 I/O lines for smaller matrices
-- NXP PCA9675 - 16 I/O lines for larger matrices
LED drivers/controller:
-- AMS AS1115 - Upto 8x8 LED matrix, upto 14 switches as well (More possible as well using part of the LED matrix)
-- AMS AS1130 for larger matrices
Buffers if need be:
-- NXP PCA9601 primarily
-- Maybe some NXP PCA9605/46 if need further
-- I might also do a NXP PCA9646 --> 4x NXP PCA9601 as the PCA9646 has four outputs, this should be sufficient for any expansion monstrosity as each I2C line would allow 4nF, so total 20nF, which is quite enough.

[MOZ]

Oh, and I am going to try for the LED matrix now, since I have learnt enough of KiCAD to design a PCB, now it is about the electronic parts and the most efficient methodology to design a modular keyboard.

And none of the concepts, component choices are concrete yet, suggestions are always welcome.

Other possible modules for future:
-- Bluetooth - Wireless!
-- Daughter board with an I/O expander and all it's lines accesible via easy to solder pad for custom hand wired matrices.

Now the various I2C devices require addressing when multiples of the same device are on the I2C bus, thinking about how to do this, dip-switches?

[doub]

How do you envision the mechanical assembling of the whole keyboard? Custom backplates with all the modules the user want, or some generic assembly system for self-contained modules?

Also to connect your different modules, maybe you should make them smarted, ie. instead of using I²C I/O expanders, you can put a small micro-controller in each module and only send actual key changes to the main micro-controller over I²C, which should eliminate any bandwidth issue.

Another alternative would be to put a USB MCU in each module, and a USB hub chip on the main keyboard. This would make it very flexible (a user could use a 2x6 module on its own, or just the numpad, without the central unit. It doesn't use more pins than I²C (2 for data, Vcc and GND).

[JPG]

Just saw that. Very nice project.


Now, just to make it even harder, why not a modular case 3D printed so you could just add/remove modules as you like?


Edit: BTW, here's my idea of how to do this modular case: Take a F122 3D model, slice it vertically, then add some cross shapes on the left/rigth sided of each slice so they can be inserted one in the other and have stability on the Y and Z axis. Then add a hole at the bottom and top of the case (and just above the TKL function row) that would go all the length of the kayboard on the X axis (from left to right). This hole would be used to put a rod that would be locked at both ends of the keyboard. You would need different rods to support the 3 different possible width. Just an idea, there's probably many more, but it sounds interesting!

[MOZ]

How do you envision the mechanical assembling of the whole keyboard? Custom backplates with all the blox the user want, or some generic assembly system for self-contained blox?

I have been pondering on how I can have it so it would be completely generic, so each blok would be self-contained. That is what I would like, now, the ideas I've had thus far, have all been very wild, trying to learn from the most modular thing most of us have been playing with from a very young age, legos and puzzles.

Since the blox go laterally, it isn't as easy, however we can have notches on the blox on the edges on them and they can slide into each other. They would be constructed so that there would be a bottom plate and  mounting plate, both of them will have the notches so different blox can be combined, we can also have edge bezel and inter-blok space blox as well.

Another idea is to have different size base plates, and the blox can then be PCB or plate mounted on it. We can also again have spacer and bezels that can be mounted directly on the base plate.

The third option which is possible, however not modular, is to generate case files using a GUI. This can be done for both layered cases or 3D printable cases. SVG for 2D vector graphics allows easy editing as it is a markup language, so a GUI can be made, where the end-user chooses/builds there config by selecting the blox used and their position. Based on this the program can generate an SVG using the preknown footprints for the different cutouts, screw holes, etc. Similarly OpenSCAD allows generation of 3d models using scripting language, again, once the configuration is setup by the user, and STL can be generated. This program can be tied in with the application to setup the keymapping and LEDs.

Also to connect your different blox, maybe you should make them smarted, ie. instead of using I²C I/O expanders, you can put a small micro-controller in each blok and only send actual key changes to the main micro-controller over I²C, which should eliminate any bandwidth issue.

I do like the idea of a smaller MCU on each board specially if in a similar price range to the expanders, however since I am not an electronics engineer, and have no experience in the field thus far, I can't compare their pros/cons. I would request any electronics gurus, to please chime in and help in the project if possible.

Another alternative would be to put a USB MCU in each blok, and a USB hub chip on the main keyboard. This would make it very flexible (a user could use a 2x6 blok on its own, or just the numpad, without the central unit. It doesn't use more pins than I²C (2 for data, Vcc and GND).

This is an idea regack and I have discussed earlier as well; one reason I am not in favour of this is, redundancy, as a separate controller on each blok, means many more components besides just the MCU, higher costs aswell. I'm  not sure, but with numerous blox, we might even need a powered source due to the multiple MCU, this might be the case with the non-USB MCU system as well, need someone with more know-how on this.

The only blok which I think anyone would use besides the base unit is numpad/6x4 blok, one one around this is to have a MCU blok, which will have a USB MCU, and I2C line, so you can connect any blok and run-it standalone.

I know some would suggest to do this anyway and have the base unit connect in a similar manner, however the argument I have against that is, most people would _USE_ the central  unit, and it would be another added extra I/O expander (That too the mighty PCA9698 with 40 I/O pins) on the I2C bus and the added cost of separate PCB, extra expander. This would be good and give some breathing room on the base unit PCB though.



Also wanted to get this out, I am not an electronics person, and have never had any experience like this before, but I do like tryign new things, and I do love keyboards, I am a software engineering student and a very bad one at that. However I do learn fast, about a few months back, I didn't even know how to make simple diagrams in Corel, and now I can easily make so many keyboard cases and other stuff, and this community is a great encourager, one the best, so bare with me, and we will make this one-of-a-kind project come true. Oh and unless it wasn't clear, this is going to be a completely open source project, I just created a github account and setup a repository for it. Oh and at end of all this, if we do not succeed, I can assure you, I would have learnt enough to churn out some fixed non-modular (Well maybe a little bit) keyboard PCBs, open-source for anyone to make.

[doub]

I do like the idea of a smaller MCU on each board specially if in a similar price range to the expanders, however since I am not an electronics engineer, and have no experience in the field thus far, I can't compare their pros/cons. I would request any electronics gurus, to please chime in and help in the project if possible.

You can find simple MCUs in almost all families (AVR, PIC, ARM, etc.) for a few dollars. For extra reusability you could even have your main keyboard block have two MCUs, a block one directly wired to a hub one that would aggregate all blocks.

The drawback is that each require programming, but it would at the same time simplify the main MCU code and it's mostly reusable for each block. And if you're in software engineering that shouldn't be a big issue.

[mkawa]

hmm.. have you vetted the 23018? i think dox and team tried a bunch of different io serializers and ended up with an atmel chip because the others were just way too slow. otherwise, looking good!

[MOZ]

You can find simple MCUs in almost all families (AVR, PIC, ARM, etc.) for a few dollars. For extra reusability you could even have your main keyboard block have two MCUs, a block one directly wired to a hub one that would aggregate all blocks.

The drawback is that each require programming, but it would at the same time simplify the main MCU code and it's mostly reusable for each block. And if you're in software engineering that shouldn't be a big issue.

Yes, I'm aware on the fact that we can get simpler MCU, in the ARM family as well (Which is looking to be the one we might go with), however when I said about pros and cons, I wanted a comparison more along the lines of electrical, ie, power draw as USB supports upto 500mA, capacitance, impedance, other electrical things I have no idea about, etc. 

Programming is not a concern right now, as it is something we can review multiple times, as Remi Taffin (Head of Renault track operations) said while explaining the new V6 Turbo engine used in Fi1 2014, that software is the key, once the engine hardware is frozen on March 1, it is software which will decide. Similarly, hardware is something we can only review so many times, not to forget the associated costs. Software we can review a lot more.

When you mention, a secondary MCU for the the hub, do you mean, running it as a USB hub or running the I2C Bus?

hmm.. have you vetted the 23018? i think dox and team tried a bunch of different io serializers and ended up with an atmel chip because the others were just way too slow. otherwise, looking good!

I'm not sure how deep the dox team looked into it, they are better than me in this field, however their application was different as they were limited to the AVR, which doesn't have native I2C, and uses something very similar called TWI (Two wire serial interface), which is essentially like I2C, but limited at 400Hz, the 23018, is ended capable of more, however it was limited by the AVR uC, and they only needed to attach a simgle device to the I2C bus, so it wasn't a problem. In our application we need to use many more devices on the I2C bus, and thus require I2C FM+ mode, allowing 1Kz, with all the same allowances as the slower I2C FM, as long as we stay below 400pF.

[mkawa]

oh good point on I2C vs TWI.

question: how about using one of the 8-bit or 16 bit freescale/atmel/Ti/AD/etc micros that has flexray support? flexray is extremely fast, self-configuring, and is emergening as a new standard for on-chip and interchip communication, all while being pretty damned cheap in both pins and cost.

[MOZ]

oh good point on I2C vs TWI.

question: how about using one of the 8-bit or 16 bit freescale/atmel/Ti/AD/etc micros that has flexray support? flexray is extremely fast, self-configuring, and is emergening as a new standard for on-chip and interchip communication, all while being pretty damned cheap in both pins and cost.

IDEK what FlexRay is :embarrassed:, Google here I come.

[doub]

Yes, I'm aware on the fact that we can get simpler MCU, in the ARM family as well (Which is looking to be the one we might go with), however when I said about pros and cons, I wanted a comparison more along the lines of electrical, ie, power draw as USB supports upto 500mA, capacitance, impedance, other electrical things I have no idea about, etc. 

There's a whole spectrum of available MCUs, so many that it's probably easier to define a spec you want, filter compatible MCUs, and pick one of the remaining ones. I don't know anything about I²C, but as for power consumption the equation is easy. You get 100mA from USB at boot, and then up to 500mA after negotiation. Most USB MCUs are designed to work under that 100mA limit. That leaves you with up to 400mA to distribute between your blocks. I'm pretty sure you can get MCUs in all families with that use less than 50mA, at least if you use them as simple key matrix to I²C controllers (ie. with internal devices like times and ADCs disabled).

To select the right MCU for you, you need to add other filters. Like your familiarity with the manufacturer, your knowledge and the availability of the toolchain, extra features, etc. In particular you might want to look at ones with a USB DFU bootloader pre-programmed by the manufacturer (and eventually in ROM to be unbrickable).

When you mention, a secondary MCU for the the hub, do you mean, running it as a USB hub or running the I2C Bus?

I meant that:



As you can see there are two microcontrollers (black boxes) in the QWERTY block. The big one manage the I²C bus, and implements the USB keyboard protocol.

In the example above, you can replace the "HUB" MCU with an actual USB hub chip, and move the extra functionality to the peripheral MCUs, and replace the I²C bus with USB links. USB is easier to deal with because it's not a bus, and you just need to route individual links from the hub to the other chips. The tradeoff is that you need to add extra external components to manage power, but they do integrated USB hub power controllers to simplify that.

[mkawa]

keep in mind that USB3.0 ups that current limit substantially, and that pretty much everyone has USB3 at this point. with a very large device like this that could potentially have very current hungry LED components etc, I would heavily consider targeting USB3 for the extra current.

[MOZ]

There's a whole spectrum of available MCUs, so many that it's probably easier to define a spec you want, filter compatible MCUs, and pick one of the remaining ones. I don't know anything about I²C, but as for power consumption the equation is easy.....To select the right MCU for you, you need to add other filters. Like your familiarity with the manufacturer, your knowledge and the availability of the toolchain, extra features, etc. In particular you might want to look at ones with a USB DFU bootloader pre-programmed by the manufacturer (and eventually in ROM to be unbrickable).

Yes, I've spent the last couple of days goign through possibly hundred of pages and datasheets of MCUs and comparing and what not, and thus I'm really keen on using the NXP's line of LCP MCU, and they have an impressive line, even some of the smaller MCU support I2C FM+, ROM with bootloader, I2C drivers, etc. Pricing wise some of them are close to the I/O expanders listed earlier, and thus are also feasibly as they reduce polling by main USB MCU over the I2C bus.

However, my lack of electronic knowledge brought me to a halt, as I didn't know what the "requirements" were for a MCU to operate as a keyboard controller.  Maybe someone with experience can let us know. Or at the least can we get a list of the MCUs used thus far for keyboard controllers and go from there.

You get 100mA from USB at boot, and then up to 500mA after negotiation. Most USB MCUs are designed to work under that 100mA limit. That leaves you with up to 400mA to distribute between your blocks. I'm pretty sure you can get MCUs in all families with that use less than 50mA, at least if you use them as simple key matrix to I²C controllers (ie. with internal devices like times and ADCs disabled).

I don't think current draw is going to be an issue with the MCU(s) and I/O expanders, as the current draw (Max) by the currently shortlisted devices is:
Controller (MCU):
-- NXP LPC11U37FBD48/401 -- 7mA @ 50Mhz
I/O expanders (IOX):
-- NXP PCA9674/75 -- 0.5mA @ No load
LED drivers/controller(LEDC):
-- AMS AS1115/30 -- 0.5mA @ No load
-- NXP PCA9634/35 -- 2mA @ No load
Buffers if need be (I2CB):
-- NXP PCA9601 -- 6.75 mA
-- NXP PCA9605/46 -- 0.17mA

So even for an elaborate system with let's say:
- Base - 7mA
- 20 blox via IOX - 10mA
- Backlit for all 21 using PCA9635 - 42mA
- 4 PCA9601 - 27mA
- 1 PCA 9646 -- 0.17mA
Total Draw = 86.17 mA

Obviously there are going to be many more components, however the ICs are not going to be the major current sink, a majority of the current draw will be by the LEDs as each LED on average takes about 20mA (Some, like 2x3x4mm white draw 30mA), now even with multiplexing, this means avg current draw by these LEDs will be:
- 160mA for a 60%
- 280mA for TKL
- 360mA for full size
- 420mA for 122Key

Practically speaking we might scrape through for most layouts that don't go absolutely crazy.  )

The smaller MCU use between 3-5mA, so compared to the LEDs, this is quite small, considering the number of LEDs required per blox vs only one MCU on it.

Hence, I've started to look into USB hubs as blox, which would be required by those creating beast keyboards requiring more current draw than usual. One of the good ones with on-chip power management that I've found is: http://www.cypress.com/?docID=39996. This one only has 3.3V on downstream USB ports, this means, we will have to step-down to lower VCC for the system. The devices shortlisted thus far, do work in this range quite easily, however it means we would be limited to max 2.3V LEDs.

[mkawa]

why the NXP MCU? imo pretty much everyone else has a better MCU at every price point. why not STM or Ti arm chips?

NXP is does power fets, afaic. the other guys are better soc designers.

[MOZ]

keep in mind that USB3.0 ups that current limit substantially, and that pretty much everyone has USB3 at this point. with a very large device like this that could potentially have very current hungry LED components etc, I would heavily consider targeting USB3 for the extra current.

USB3 is definitely popular and something I had already try to rummage through the internet to find a cheap USB 3.0 MCU as it seemed like a feasible solution, given how most new USB host devices do have atleast 1 if not multiple 3.0 ports, however besides cheap, I couldn't find any viable options. We are still not there yet.

Similarly for FlexRay, it just seems a little overkill and doesn't have as much application on our scale yet, and thus a lack of available devices/components.

Kawa, you are ahead of time bro:P

why the NXP MCU? imo pretty much everyone else has a better MCU at every price point. why not STM or Ti arm chips?

NXP is does power fets, afaic. the other guys are better soc designers.

To be honest, I did not study or look too much for better alternatives, as I was going with the I2C interface and NXP/Philips are the pioneers in I2C, so it was more of a natural choice. Once I went into that field, I had some communication with AcidFire (Who has been doing some similar and amazing work on the Nexus modular ergonomic keyboard project) and had been following his thread, the NXP LPC11U37FBD48 was the MCU he chose and seemed like a good choice given the price point and comparison to the ATMEGA32U4. However I have begun the search for a better MCU with I2C FM+ or HS at a similar price point.

Now, the question is requirements of the MCU?
1. Do we really need EEPROM when we have ample amounts of FLASH (As comapred to EEPROM) on MCU? If yes, then why and how much is the minimum? Do we still need FLASH then? Again, if yes, why and how much?
2. How much RAM is suitable for a keyboard controller?
3. How fast is fast enough? 16Mhz (Used in ATMEGA32U4)? Or we can go even lower?

[moonexe]

Everyone has USB3? Are you guys serious?

[SpAmRaY]

Everyone has USB3? Are you guys serious?

There isn't a single machine at work with USB 3 :/

[MOZ]

Everyone has USB3? Are you guys serious?

That isn't what I said , kawa did though, but remember gucci lives in the future. *Most* newer devices do though, and it is becoming popular, however we aren't there, where we can develop USB 3.0 boards.

[moonexe]

I'm still at the point where it's something I look for in system specs, rather than just assume to be there... Have I been slacking?

[doub]

I think the NXP MCU line is not that bad, many projects use them. I've only used STM32 recently myself, and it was a bit of a pain to get a free toolchain up and running.

As for what you need to implement a keyboard protocol, any MCU with USB can do it. The keyboard protocol is very simple, and even if you want to implement NKRO most if not all will be able to do it (if you stick to a simple NKRO scheme with a single HID interface).

I had a quick look at your Cypress hub chip, and I believe you misinterpret something regarding downstream ports. It has a 3.3V regulator for its own use (and eventually other chips on the same PCB, with a total limit of 150mA), but it cannot power downstream ports. You still need a separate power switch to route the 5V to each port (the hub chip has a Power-Enable output for each port, but that's just a logic signal to tell the power switch to transmit power or not).

[yasuo]

Not matter 60/80/150++ keys layout
no matter how much keys most important is symmetry )

[MOZ]

I think the NXP MCU line is not that bad, many projects use them. I've only used STM32 recently myself, and it was a bit of a pain to get a free toolchain up and running.

LPCExpresso seems to have good reviews, it uses Eclipse, which I have some familiarity with and is straightforward to setup.

As for what you need to implement a keyboard protocol, any MCU with USB can do it. The keyboard protocol is very simple, and even if you want to implement NKRO most if not all will be able to do it (if you stick to a simple NKRO scheme with a single HID interface).

I understand requirements can be fairly low for a keyboard system, but when developing a more complex system as this, we need to take into consideration larger systems and various layouts as well, we have to look at both ends of the complexity spectrum. Still, even for the most simple, let's say TKL, what would be the requirements from the MCU (Speed, FLASH or EEPROM or Both and quantity, RAM). These are the parameters I am not sure off.

I had a quick look at your Cypress hub chip, and I believe you misinterpret something regarding downstream ports. It has a 3.3V regulator for its own use (and eventually other chips on the same PCB, with a total limit of 150mA), but it cannot power downstream ports. You still need a separate power switch to route the 5V to each port (the hub chip has a Power-Enable output for each port, but that's just a logic signal to tell the power switch to transmit power or not).

I've been an amateur in reading the datasheet and in my approach for large current draw as well, the better option if we do have to use direct power would be to use it directly rather than through a hub, have a connector to connect directly to a wall-wart, and have an auto switching circuit to actively provide 5V to the system, with priority from the wall-wart.

[MOZ]

There is one other advantage to using the NXP line (Maybe other MCU product lines have this as well, not sure) and that is the USB and non-USB 48LQFP packages are all pin-to-pin compatible besides the 5 USB specific pins, meaning flexibility on what the user wants to do, they can either have blox communicate via one central USB-capable MCU or run it standalone using it's own USB-capable MCU.

One other advantage of using this setup is it allows using the one MCU for LED lighting as well (Using some discrete components)

[MOZ]

I've posted in the Simple Q/A thread: http://geekhack.org/index.php?topic=40501.msg1209309#msg1209309

IDK if this is simple question or not, but can someone explain how a keyboard controller works? What the various components, CPU, FLASH, EEPROM, RAM play?

I know that is scans rows or columns for key presses, and then matches the keypress to a scan code and sends it to the host unit. Correct?

However I wanted a more technical and detailed explanation, as in, what role does FLASH/EEPROM play, what does the RAM on the controller do?

So if you happen to know and will be willing to explain, it would help immensely understand the requirements of a keyboard controller MCU.

[MOZ]

After a fairly long discussion with HaaTa, who was kind and humble enough to bare with my noob-ness, we came to the following:

1. Central USB MCU and I2C connected IOX
-- Good for small/medium systems (internal)
-- Not very feasibly for external blox (Possible allow 2-3) due to higher latency which is proportional to  cable length and number of devices
-- Central MCU polls for keypresses on all blox
-- Firmware easy to update over USB
-- ~Cost: Central MCU @ $4-5, IOX @ 1.5-2.5
2. Central USB MCU and I2C connected MCU
-- Good for upto medium/semi-large systems (internal)
-- Possibly feasible for medium systems (external)
-- Each MCU polls its own board, central USB MCU polls these scancodes.
-- Harder to implement firmware update as there are multiple MCU, non-USB-MCUs, depends on chosen MCU if it can be updated over I2C or not
-- ~Cost: Central MCU @ $4-5, IOX @ 1.6-2.8
3. USB hub connected multiple USB MCU blox
-- Good for large+ systems (internal)
-- Feasible for large systems limited by cable mess (externa)
-- Each MCU polls its own board and communicates .
-- Harder to implement firmware update as there are multiple USB-MCUs, software-end to properly load correct firmware in each MCU, either automatically or by the user.
-- ~Cost: USB MCU @ 3-4, Hub IC @ $2.5



The other thing I am actively looking at is LEDs, there are again 3-ways to implement matrix LEDs allowing control over each LED using drivers that support I2C FM+:
1. Using PCA9674/5
-- Limitation: Upto 16/64 LEDs
-- PWM control: Every LED (You can choose brightness software end, glowing effect, anything to do with altering brightness levels software end)
-- Current Limiting Resistors: One per row or one per switch if you mix and match LEDs due to different current requirement for each LED
-- Transistors required: PNP (One per row), Darlington NPN array IC (Only one)
-- Effect on PCB: Extra IC, extra discrete components and one resistor per LED space with short-able pads
-- ~Cost: Driver @ $1.6/2.4, Darlington @ $0.9, PNP @ $ 0.1 each, resistors @ $ 0.02 each
2. Using switch-scanning MCU
-- Only possible when MCU present not with IOX, subject to available pins
-- PWM control: None
-- Current Limiting Resistors - One per column or one per switch if you mix and match LEDs due to different current requirement for each LED
-- Transistors required: PNP (One per row), Darlington NPN array IC (Only one)
-- Effect on PCB: Extra discrete components and one resistor per LED space with short-able pads
-- ~Cost: Darlington @ $0.9, PNP @ $ 0.1 each, resistors @ $ 0.02 each
3. AS1115
-- Limitation: Upto 64 LEDs
-- PWM control: Every LED (You can choose brightness software end, glowing effect, anything to do with altering brightness levels software end)
-- Current Limiting Resistors - Only one required
-- Transistors required: None
-- Effect on PCB: Extra IC and one resistor
-- ~Cost: Driver @ 4.23, resistors @ $ 0.02 each

[MOZ]

Oh and recommended requirements from the MCU are about the same as the Atmega32u4.

As far as EEPROM/FLASH is concerned, FLASH by itself is good enough and EEPROM whilst not necessary may be useful in some applications, not in ours as much.

I'm thinking of doing a test run using this layout:


Will have support for all three modes of operation as highlighted above. Method 2 and 3 are easily interchangeable on hardware end at least with NXP's line of LPC MCU.

[MOZ]

Can someone please confirm what the JIS layout looks like.

[yasuo]

Can someone please confirm what the JIS layout looks like.

http://en.wikipedia.org/wiki/File:KB_Japanese.svg
http://en.wikipedia.org/wiki/Keyboard_layout
no,please symmetric actually from japan as well )
japan space is small you must smart placing

[MOZ]

Can someone please confirm what the JIS layout looks like.

http://en.wikipedia.org/wiki/File:KB_Japanese.svg
http://en.wikipedia.org/wiki/Keyboard_layout
no,please symmetric actually from japan as well )
japan space is small you must smart placing

I've seen that, but I would still like some oen to post a picture or the exact distribution of width on the base mods.

[pasph]

[moonexe]

That is a LOT of modifiers.

[MOZ]

Now I am confused, is the one on Wikipedia the correct one or the Filco one.

@IvanIvanovich, you mentioned JIS, so I'm guessing you might know.

[yasuo]

Now I am confused, is the one on Wikipedia the correct one or the Filco one.

@IvanIvanovich, you mentioned JIS, so I'm guessing you might know.

i  think same just on filco no win_r key

[korrelate]

I started working on a 77key layout, but I sort of dropped it when trying to work out some LED arrangements on one of my other projects... then I sort of disappeared into a black hole for about 6 months.

Show Image

I'll have to keep an eye on this :D

I prefer full size, but this layout speaks to me. Very interested.

[pasph]

http://deskthority.net/wiki/JIS

"The specific size and quantity of the Japanese input keys varies between keyboards"

Realforce

[vardhana]

@MOZ
JIS X4064 (Basic functions of Kana-Kanji conversion systems) Appendix 2 refers to "OADG 109A layout" as an example of physical key layout.

This is an extract about OADG 109A from their technical reference.
http://oadg.or.jp/archives/OADG-WEB/OADG/109A.pdf
(A note in page A-8 says "We don't define key pitch and legends")

[MOZ]

God damn it, why the japanese layout has to be so weird, I might drop the idea altgother if it becomes a problem placing components on the board as the area under the spacebar is a good place to build the controller parts, and with so many keys in different layouts, it will just kill that room.

Also, I'm looking to implement some ESD suppression, give how the ErgoDox recently seems to be falling prey to it.

[mkawa]

moz, ESD or EMI? litster's case doesn't really leave any pcb exposed; are people killing the MCU with that 3.5mm TRS plug they're using to link the halves?

i would just spec a nice star ground through all the connectors that sinks into a plate or USB ground or something. the ESD suppression chips i know of aren't worth the cost when dealing with circuits this simple.

[MOZ]

moz, ESD or EMI? litster's case doesn't really leave any pcb exposed; are people killing the MCU with that 3.5mm TRS plug they're using to link the halves?

i would just spec a nice star ground through all the connectors that sinks into a plate or USB ground or something. the ESD suppression chips i know of aren't worth the cost when dealing with circuits this simple.

Both ESD and EMI. There is no consensus on what is it, but there definitely is some problem and ESD induced EMI could be it as well as reported failures of the connectors, it is unclear on whether it is due to physical failure or electrical.

I'm not looking to do anything too much, just following the Atmel app notes and placing some ESD suppressors (varistors) and a ferrite bead between the USB shield and ground. Nothing over the top or pricey but able to provide some ESD/EMI protection.

[MOZ]

Just some general things to remember when designing the keyboard PCB (Just dumping information):
- Use as much PCB area as possible for power and ground
- Connect USB shells to ground preferably via ferrite beads/RC filter for EMI reduction as close to the connector as possible
- Place oscillators as far away from the USB data lines as possible
- Traces from the input USB receptable to the USB microcontroller pads should be as short as possible, and follow differential traces routing rules (same length, as near as possible, avoid via accumulation, as 90 ohm differential pair)
- Voltage transient / ESD suppressors may also be used to prevent USB pads to be damaged by external disturbances (For data lines), these should be placed as close to the connector as possible
- Ucap capacitor should be 1µF (+/- 10%) for correct operation.
- A 10µF capacitor is highly recommended on VBUS line
- Serial resistors on USB Data lines must have 22 Ohms value (+/- 5%) preferably close to the MCU
- Place 0.1uF decoupling capacitors across every pair of Vcc and GND as close to MCU as possible
- Connect RESET via pull-up of atleast 10kOhm, and 1N4148 diode (Vcc to RESET) for ESD protection
- For our application a 16Mhz crystal with 22pF external capacitors on either side to GND
- Crystal and its capacitors should be places as close to the MCU as possible with proper surrounding ground plane
- The two PCB-mount guiding pins for MX switches are an excellent choice for ground stitching to reduce impedence

[MOZ]

Here is the schematic as I have thus far, it is looking good for conversion to PCB, except for the following:
1. 3 extra LEDs in the LED matrix (They are unlabeled) Done
2. Haven't added all the mounting holes, only generic ones.
3. Haven't added stabs to schematic yet.
4. Not all switches can be seen in the matrix just yet (Eg 1.25 alt and 1.5 alt), any key that may have multiple positions, I've  only assigned a single switch right now
5. I'm thinking about segregating the LED matrix and the switch matrix into smaller ones each for it's own PCB. Done

This is obviously AVR based, I made the decision based on certain constraints (Time, finance) as the ARM route would require more testing as a contain system before implementation for something larger. So I am going to wait on AcidFire'd Nexus project and learn from there, before expanding to ARM and I2C/USB-hub based system.

This is the layout it is currently designed for, each enclosed (By red boundary) area is a separate PCB.

[MOZ]

Removed the extra LEDs and redrew the schematic with segregated matrices.

Also pondering on using resistor and capacitor arrays instead of individual components.

[mkawa]

AVR and atmel studio is a good platform for a project like this. keep the moving parts in your toolchain down. kicad alone is enough of a pain that i would heavily consider a version with a teensy and lots of twi before revising for fancier computation

[MOZ]

Lots of twi = latency.

Hence the only TWI link I am using is for the LED controllers, which are smart and can be programmed and be forgotten, one of them is used for the 6x2 block for keyscanning, since the AS1115 key scans by itself, there should be lesser latency problems.

I'm not keen using the Teensy, so I am going to go ahead with Kicad itself, in my experience so far, it hasn't been as much a problem, except for the artifacts when making changes, but a quick zoom-in, zoom-out with scroll wheel fixes it.

[MOZ]

Latest schematic.

-- Segregated the LED and switch matrices based on sub-boards.
-- All pins now pins now in schematic
-- Added stabs
-- Added mounting holes
-- Added extra switches for base mods to comply with various possible layouts.
-- Used capacitor arrays and resistor arrays where possible.
-- General clean-up

[hoggy]

Reminds me of the Somers EK1...


...but on steroids.  Can't wait to see what you end up with.

[MOZ]

Right now I am working on creating a component and module library for KiCAD, those should go up in the PCB soldering thread pretty soon.

[MOZ]

This is not dead.

As a stepping stone, I will first create a 60%/TKL, do a proto and then move from there.