Hyper Keyboard - technical discussion

[7bit]

You can choose another chip, ATMEGA168A-AU for example have only 28 pins (while still having 23 io pins), ATMEGA168A-PU is a rectangle as opposed to a square for 32U4.

I suppose there's a lot of space under space bar/enter/tab etc for mcus.

If you know how to program it then we can go for that option.

[7bit]

Once I finished the PCB-layout, you more experienced people can take a look if everything is OK. Then comes the prototype ...

ATMega32U4 is on the GH60, so if it works for them I don't see why it should not work on the HyperMini. The alternative is you solder wires to pads spread accross the PCB.

[7bit]

Does anybody know the track width they use on the GH60 for the controller?

[bpiphany]

The ATmega32u2 does make a perfectly fine keyboard controller. I don't know if it is capable of acting as a mouse at the same time though. That is a question for someone more experienced in the AVR controllers. The ATmega32u4 is the most common choice for keyboards so far, much due to the Teensy being one of course. The TQFP44 package is really one of the simpler SMD jobs you are going to get. But it is big, the QFN-packages are a lot smaller, and really only for re-flow soldering.

It's not too hard getting a matrix of push buttons hooked up to a controller working (hey I did it...). The only issues I've ever heard of is EMI, and that should probably be handled by the firmware anyway.

But don't expect anyone to just sign off on your PCB design. It takes time to get into it properly, the kind of time you spend to draw the damned thing to start with =D Better to ask someone on the schematics in that case.

[7bit]

I understand next to nothing ...


Why should something which works on the GH60-PCB not work here?

The LED pads can be made just holes, so they don't get into the way at all.

Pin 34 should be far away enough to not interfere with the soldering pad of the switch below.

[bpiphany]

If it's the controller you are talking about, the GH60 is using the TQFP44. The crystal is going to be more of a pain to solder. There are larger SMD crystals with leads, and there are through hole crystals as well. They are all a lot larger than the lead-less ones.

The GH60 schematic should work fine.

The measurements for the TQFP package is at the bottom of the ATmega32u4 datasheet, this is where you usually find component physical specifications. http://www.atmel.com/Images/doc7766.pdf

You just need to do it right.. but you can specify several track widths in KiCAD under the design rules dialogue. And also different via dimensions. Once you have more of them you can switch between them while drawing traces, by right clicking.

[7bit]

If it's the controller you are talking about, the GH60 is using the TQFP44. The crystal is going to be more of a pain to solder. There are larger SMD crystals with leads, and there are through hole crystals as well. They are all a lot larger than the lead-less ones.

The GH60 schematic should work fine.

The measurements for the TQFP package is at the bottom of the ATmega32u4 datasheet, this is where you usually find component physical specifications. http://www.atmel.com/Images/doc7766.pdf

Thanks for clearing this up.



Just for better understanding:

The ATmega32u4 as on the GH60 is only on the backside, so tracks can go above, right?

You just need to do it right.. but you can specify several track widths in KiCAD under the design rules dialogue. And also different via dimensions. Once you have more of them you can switch between them while drawing traces, by right clicking.

This is exactly what does not work. I can add endless many to the list, but can only coose the Default one.

[tlt]

It would be nice to have the not used pins on the controller connected to soldering points somewhere that they can be used for add-ons like mouse buttons or a trackpoint.

The controller need to have a bootloader on it so that it can be program via USB without programming hardware and we need a reset switch somewhere.

[7bit]

Thanks for mentioning this.

I will also add soldering points to connect a replacement controller.

[philpirj]

The controller need to have a bootloader on it so that it can be program via USB without programming hardware and we need a reset switch somewhere.

Good idea!

According to Atmel's USB DFU Bootloader Datasheet Complete, bootloader is already there and

Code: Select all

Bootloader can be run by ... Regular application execution: A jump or call from the user application program. This may be initiated by a trigger such as a command received via USB, USART or SPI and decoded
by the application...

So a pushbutton should be there to trigger flash mode.

[7bit]

I plan for a key combination to do the reset.


What about Control-Alt-Delete?

[philpirj]

I plan for a key combination to do the reset.
What about Control-Alt-Delete?

Windows guys are using this too often for other purposes lol.

[tlt]

A key combination requires a working firmware and if you programmed a broken one your probably want to replace it

[tlt]

I guess you could have a bootloader that goes into programming mode if your holding down keys at power on. But that requires a custom bootloader with this feature. The DFU bootloader goes into programming mode by restarting with a jumper on some pins I have only tried it on the Arduino Unos Atmega16U2 (that is used for USB communication on that board) and I don't know what pins it is on the chip.

EDIT: Looked at the data sheet and its PE2 to ground during reset.

[7bit]

1st solution: solder a switch to the reset pins.
The reset happens when the switch is down.

2nd solution: put 2 switches between these 2 reset pins.
The reset happens when both switches are down.

I don't know if there are any problems with pressing buttons while pressing reset, but I think it should work.

Someone with this ...

.. and a teensy should give it a try!

I recommend MXLOCK for easy reset.

[tlt]

PE2 is not the same as the reset pin. If we are going to use the DFU bootloader then it's the possibility to easily connecting PE2 to ground that is important. The reset can be done by unplugging the keyboard and plug it in again. We could have a hole in the bottom of the case where you can put something pointy on a push button while plugging in the keyboard to set it in programming mode.

EDIT: or have a keyboard switch connected to PE2, but then you can set it to programming mode by mistake

EDIT2: I think you can just reset the controller again to get out of the bootloader programming mode if you enter it by mistake. But this need to be tested or confirmed by someone with more avr experience.

[7bit]

Sure can there be a microswitch or whatever on the underside, but I said more than one switch!!!!

Are there any interferences with regular typing?

Maybe I should just finish the PC-layout and give it a try later...

[uberben]

I only skimmed, so maybe this was suggested, but what about a key combo that goes to bootloader mode as weld as a tiny switch that is a fallback reset button in case the firmware screwed up the shortcut?

[tlt]

Sorry I didn't think it thought. You might not want to connect a keyboard switch between PE2 and ground, than it would not be part of the keyboard matrix. I think you can't get out of bootloader mode without reprogramming it with the DFU software if you set it from the firmware (with a key combo), but if its not easily done by mistake I guess its ok. You can always take the keyboard apart and connect PE2 to ground if you really need to do it.

[uberben]

I've not used the default DFU bootloader (my ATmega32U4 is running Adafruits modified LUFA CDC bootloader) and as far as I know, it only remains in bootloader mode for a couple seconds before going back to normal operation. Even if it got stuck, I would think unplugging and plugging the keyboard back in would restore it anyway.

[7bit]

Just realised the controller must be on the underside.

Also, I must turn it by -90 degrees, because the USB-pins should point to the top.

I also need to sort the columns. The GH60 is quite messy, or is that on purpose?

Does anybody know if I can put vias directly under the pins?

[7bit]

I've stolen komar007's scheme file of the controller.

I've added some more column and row-positions.

Can someone explain what the marked components are for?

Especially the stuff marked in orange I do not understand.

[Soarer]

red - power supply decoupling capacitors. The large one can go almost anywhere between the socket and the CPU. The smaller ones should be one per power supply pin on the CPU, positioned as close as possible to the pin.

green - crystal oscillator.

blue - resistors to a) hold reset high unless the switch is pressed, and b) to hold PE2 low. See the datasheet for Reset option.

orange - Programming connection. You can omit this if you have a bootloader already on the chip.

[Soarer]

Just realised the controller must be on the underside.

Also, I must turn it by -90 degrees, because the USB-pins should point to the top.

I also need to sort the columns. The GH60 is quite messy, or is that on purpose?

Does anybody know if I can put vias directly under the pins?

What does your mapping of matrix rows and columns to keys look like? And theirs? Did they use the autorouter?

Why put vias under pins? You could put a small track towards the middle of the chip instead.

You should also think about adding a ground plane, at least under the chip.

[7bit]

...

Thanks for clearing things up!

What I still do not understand is where the power supply decoupling capacitors are connected to (ie which pins).
Programming connection: These are only active in programming mode and can therefore be the same as row/column connections, right?

[7bit]

What does your mapping of matrix rows and columns to keys look like? And theirs? Did they use the autorouter?

I think these connections where just convenient to the controller placement. Just found it strange that adjacent rows or columns where not connected to adjacent pins.

Why put vias under pins? You could put a small track towards the middle of the chip instead.

So it is possible to have a green track going from the pin above (remember the controller is on the underside) the controller. Great!

You should also think about adding a ground plane, at least under the chip.

What is a ground plane?

[tlt]

A ground plain is an area of copper layer connected to ground to reduse interference.

I mostly used the modifyed lufa cdc bootloader in the sparkfun breakout board and I think it works like the adsfruit one. I think Tennsy has its own custom bootloader too. An advantage of using dfu is that its already on the chip.

[Soarer]

What I still do not understand is where the power supply decoupling capacitors are connected to (ie which pins).

They are all connected between Vcc (+5V) and ground, but one per Vcc pin on the chip, close to each pin and with a short, direct PCB trace to the pin. TBH, I think 4 is overkill.

Programming connection: These are only active in programming mode and can therefore be the same as row/column connections, right?

I suppose they could, I never really thought about it. If you're happy to just use the DFU bootloader that's pre-installed on the chips though, you don't need them at all.

[Soarer]

What does your mapping of matrix rows and columns to keys look like? And theirs? Did they use the autorouter?

I think these connections where just convenient to the controller placement. Just found it strange that adjacent rows or columns where not connected to adjacent pins.

Oh, you mean the mapping of rows and columns to pins. Hmm. I dunno! The pins don't have a lot of logical order to them anyway (ports are split around the chip in many cases).

So it is possible to have a green track going from the pin above (remember the controller is on the underside) the controller. Great!

Something like this... could be even closer to the pin's pad, I just used paint...

controller_via.png (34.42 KiB) Viewed 12048 times

[7bit]

I suppose they could, I never really thought about it. If you're happy to just use the DFU bootloader that's pre-installed on the chips though, you don't need them at all.

I think it is better to have them, because the thing will be dead if the controller forgets about the bootloader.