Gaming keypad build. Help a noob, please!

[seattle_ice]

I have been frustrated with all the standard keyboards for gaming, as I use an unusual setup - my left hand on the arrow keys. Also, my hands are quite big so it is easy to fat finger things a lot.

I am quite handy, good with solder and electronics, wood and metal, but I have exactly zero knowledge about keyboard tech.

I am planning on building a keypad like the following with cherry mx brown switches:



I believe I want to do it plate mounted, with some kind of case.

So to get started I just design the layout, and get a plate laser cut from the design? I used the editor at http://www.keyboard-layout-editor.com and then http://builder.swillkb.com to get a cad file of what I want. I can just order the plate in 2mm brushed stainless for $44 or so from lasergist. Any better suggestions?

[vextanys]

It should be quite easy. I'm not great with woodworking/metalworking skills and managed to make something similar.
A laser cut plate will help, as the tolerances for the switches are too tight for my lousy skills
I did find the arranging of rows and columns with diodes the hardest to get right first time (I put all my diodes in the wrong way round, and decided to rework the firmware instead of re-soldering them), but a Teensy can be experimented with and reflashed easily.
TMK firmware was pretty easy to reconfigure with the right keymap and row/column setup, and there was decent docs to point you in the right way.
Finding the Crouch button will be hard - I haven't seen a 2x1.5 key (2x1 might have to replace it)

[suicidal_orange]

Looks good, you want a 1.5mm plate to get the switches to clip in though.

Probably the closest key to your jumbo crouch would be a sideways ISO enter?

[seattle_ice]

Looks good, you want a 1.5mm plate to get the switches to clip in though.

Probably the closest key to your jumbo crouch would be a sideways ISO enter?

Ok, good to know on the 1.5mm. I am working on a slightly modified version of the layout without the weird size. I will post it when it is ready to go.

[seattle_ice]

Ok, I think this layout may work. I am mocking it up in cardboard to try out the size on my fingers.

[seattle_ice]

So, this is my concept of the final piece. All the single key switches I understand. But the one that is 2 units wide shows a weird hole. What additional stuff does it need for the extra wide hole? Are there some kind of extra springs or something?

[Malachor]

They're for stabilisers. https://deskthority.net/wiki/Stabiliser check under Cherry or Costar.

[seattle_ice]

They're for stabilisers. https://deskthority.net/wiki/Stabiliser check under Cherry or Costar.

Ok, thats what I thought after reading a bunch.


So if I wire the switches in a matrix, can one of the controllers  handle a certain amount of key rollover? I know I probably need 4-6KRO or so. It seems like the most suggestions on this board are for the Teensy2.0, but since I am like Jon Snow on this subject, I could use some advice.

[vextanys]

If you wire your matrix with diodes, the controller can read every key combination (controller can detect and handle N-Key rollover). For your layout, 8x8 matrix (with a slightly weird matrix) will easily cover all keys, you'd need 16 free pins on the controller (Pro Micro / Teensy 2 have more than enough free pins).

Reporting N-Key rollover to the PC/OS is slightly different, as the "standard" keyboard can only report all-modifiers + 6 key rollover.
Its possible to use a non standard keyboard descriptor for N-key rollover (where each button is a bit in the report, instead of having 6 bytes which cover up-to-6 keys), but this will no longer confirm to the boot protocol for keyboards (so may not work on older OSs and wont work with most BIOSs, cant be used with the USB-PS/2 converters you used to get before USB was common). As a dedicated gaming pad, this shouldnt matter. TMK handles this by having 2 (or more, depending on other options) USB endpoints, 1 is the standard boot keyboard (6KRO) and another is the NKRO endpoint.

[seattle_ice]

If you wire your matrix with diodes, the controller can read every key combination (controller can detect and handle N-Key rollover). For your layout, 8x8 matrix (with a slightly weird matrix) will easily cover all keys, you'd need 16 free pins on the controller (Pro Micro / Teensy 2 have more than enough free pins).

Reporting N-Key rollover to the PC/OS is slightly different, as the "standard" keyboard can only report all-modifiers + 6 key rollover.
Its possible to use a non standard keyboard descriptor for N-key rollover (where each button is a bit in the report, instead of having 6 bytes which cover up-to-6 keys), but this will no longer confirm to the boot protocol for keyboards (so may not work on older OSs and wont work with most BIOSs, cant be used with the USB-PS/2 converters you used to get before USB was common). As a dedicated gaming pad, this shouldnt matter. TMK handles this by having 2 (or more, depending on other options) USB endpoints, 1 is the standard boot keyboard (6KRO) and another is the NKRO endpoint.

Ok, that makes sense. 6KRO would be fine.

[seattle_ice]

So this is my mocked up wiring matrix diagram: 8 x 8 works out pretty decently.

This is from the back, so the top left corner is the top right in the pic.

[vextanys]

Looks good!

Personally, I'd consider swapping R4 to the full row, making R3 a full row, and merging the 5 left over keys (Num5, Num2, F11, F12, Space) into a single row, saving a row on the controller (Extra pin for LEDs, because Blue LEDs make it Gaming ) This would depend on how easy it looked to hand-wire when the switches are in the plate.

6KRO should be enough (gotta be hard to press 6+ keys with 5 fingers), and I seem to recall TMK lets you do NKRO by adding a flag to the config (it handles all the extra stuff needed)

[seattle_ice]

Looks good!

Personally, I'd consider swapping R4 to the full row, making R3 a full row, and merging the 5 left over keys (Num5, Num2, F11, F12, Space) into a single row, saving a row on the controller (Extra pin for LEDs, because Blue LEDs make it Gaming ) This would depend on how easy it looked to hand-wire when the switches are in the plate.

6KRO should be enough (gotta be hard to press 6+ keys with 5 fingers), and I seem to recall TMK lets you do NKRO by adding a flag to the config (it handles all the extra stuff needed)

Something like this? Seems doable to me.

[suicidal_orange]

That works and is still understandable.

I only count 49 switches so you could save another pin if you really mashed it up and made it 7x7, but it's not worth the headache )

[seattle_ice]

Ok, a couple more questions. I searched quite a bit, but there is so much information on here I keep getting lost:

1. I am using the Cherry MX Browns for switches. I noticed two different cutout types - a square one (which is on the cherry site) and a kind of sideways H-shaped one. Which should I be using, and why? (mine are plate mounted, not pcb).

2. Since the switches themselves are not symmetrical top and bottom, what orientation should I use to install them?

3. I assume that since they are just make/break switches you can use whichever connector you want for row/column connections. Is this correct?

4. What direction do the diodes face? 

5. From what I can gather, the teensy 2.0 with tmk seems to be a popular choice for controller. Where is the best place to purchase what I need?

Thanks, I am really looking forward to building this thing.

[Tactile]

I'd recommend supporting the folks who make the Teensy by just purchasing from them.

https://www.pjrc.com/store/teensy.html

[seattle_ice]

I'd recommend supporting the folks who make the Teensy by just purchasing from them.

https://www.pjrc.com/store/teensy.html

Perfect, thanks.  What are the differences between the teensy 2.0 and the teensy ++ 2.0? I see more pins, but not sure if that is relevant.

[Tactile]

I'd recommend supporting the folks who make the Teensy by just purchasing from them.

https://www.pjrc.com/store/teensy.html

Perfect, thanks.  What are the differences between the teensy 2.0 and the teensy ++ 2.0? I see more pins, but not sure if that is relevant.

There's a chart here, just below the pics. In general, if you don't need the extra pins of the + the regular 2.0 is a better choice. There's a lot more software (compiler) support and lots more folks to ask about problems.

https://www.pjrc.com/teensy/index.html

[dantan]

I'd like to ask a noob question because I'm also trying to understand PCBs.

Your keyboard is hand wired right? I see people using diodes to wire their keyboards. But diodes are basically exposed wires. So how do you prevent diodes from crossing each other when wiring columns across rows?

Is there some information I can find about hand wiring keyboards with minimum pain?

[Tactile]

I'd like to ask a noob question because I'm also trying to understand PCBs.

Your keyboard is hand wired right? I see people using diodes to wire their keyboards. But diodes are basically exposed wires. So how do you prevent diodes from crossing each other when wiring columns across rows?

One way is to strip a piece of wire, grab the dropped piece of insulation & slide it onto the exposed lead you wish to insulate.

[dantan]

I'd like to ask a noob question because I'm also trying to understand PCBs.

Your keyboard is hand wired right? I see people using diodes to wire their keyboards. But diodes are basically exposed wires. So how do you prevent diodes from crossing each other when wiring columns across rows?

One way is to strip a piece of wire, grab the dropped piece of insulation & slide it onto the exposed lead you wish to insulate.

It is like super hard to get wire stuffed back into insulation once you have taken it out. Any suggestions?

[Tactile]

I'd like to ask a noob question because I'm also trying to understand PCBs.

Your keyboard is hand wired right? I see people using diodes to wire their keyboards. But diodes are basically exposed wires. So how do you prevent diodes from crossing each other when wiring columns across rows?

One way is to strip a piece of wire, grab the dropped piece of insulation & slide it onto the exposed lead you wish to insulate.

It is like super hard to get wire stuffed back into insulation once you have taken it out. Any suggestions?

You strip a wire slightly larger than the lead you want to protect. In the end the insulation can rattle on the diode lead - it doesn't matter.

[dantan]

You strip a wire slightly larger than the lead you want to protect. In the end the insulation can rattle on the diode lead - it doesn't matter.

Damn, I really am a noob. Never thought of this. I didn't even think that wires come in different sizes, though of course they do.

[samwisekoi]

A few things:

#1  If you can make that Use/Enter key 1.75 wide instead of 2.00, you will eliminate all stabilizers.  That will make it much easier for you.

#2  Each switch will always be in the center of its key, so for your wider switches those vertical rows won't be the straight shots you show.

#3  User lowpoly created a hard-wiring how-to (https://geekhack.org/index.php?topic=20898.0).  That describes how the diodes are used, but basically the diodes connect one of the switch terminals to (typically) the common row wire.  And all of the diodes must be oriented the same way.

Does that help?

 - Ron | samwisekoi
Auto-typed by my GH-122 keyboard.

[dantan]

#3  User lowpoly created a hard-wiring how-to (https://geekhack.org/index.php?topic=20898.0).  That describes how the diodes are used, but basically the diodes connect one of the switch terminals to (typically) the common row wire.  And all of the diodes must be oriented the same way.

Does that help?

 - Ron | samwisekoi
Auto-typed by my GH-122 keyboard.

Yes, it helps, but can I ask you about this? http://www.lowpoly.com/keyboard/m0110/m0110_120.jpg

I notice that some of the keys are not joined the same way. For instance on the leftmost column, three keys are joined to the row via their right pins, but two keys are joined to the row via their left pins. Also the three visible lowest row keys are linked by right, left, left pins respectively. I dont' understand this.

[seattle_ice]

Yes, it helps, but can I ask you about this? http://www.lowpoly.com/keyboard/m0110/m0110_120.jpg

I notice that some of the keys are not joined the same way. For instance on the leftmost column, three keys are joined to the row via their right pins, but two keys are joined to the row via their left pins. Also the three visible lowest row keys are linked by right, left, left pins respectively. I dont' understand this.

This I do understand. Since all the switches do is connect the two terminals when pressed, it doesn't matter which terminal is hooked to which wire, as long as one is column and one is row for the matrix. So right --> left is the same connection as left --> right.

And as far as the wires touching, basically any method you want that keeps the column wires from touching the row wires/diodes is fine. You could bend the column leads so there is space. You could use insulated wires and only strip the ends at each terminal connection. You could use pieces of heat shrink in between each terminal to cover the wire. I wire cars from scratch and use a ton of heat shrink, particularly the double wall 4:1 stuff.

I'd recommend supporting the folks who make the Teensy by just purchasing from them.
https://www.pjrc.com/store/teensy.html

Perfect, thanks.  What are the differences between the teensy 2.0 and the teensy ++ 2.0? I see more pins, but not sure if that is relevant.

There's a chart here, just below the pics. In general, if you don't need the extra pins of the + the regular 2.0 is a better choice. There's a lot more software (compiler) support and lots more folks to ask about problems.

https://www.pjrc.com/teensy/index.html

Perfect, thanks, I will order the Teensy 2.0.

[seattle_ice]

A few things:

#1  If you can make that Use/Enter key 1.75 wide instead of 2.00, you will eliminate all stabilizers.  That will make it much easier for you.

#2  Each switch will always be in the center of its key, so for your wider switches those vertical rows won't be the straight shots you show.

#3  User lowpoly created a hard-wiring how-to (https://geekhack.org/index.php?topic=20898.0).  That describes how the diodes are used, but basically the diodes connect one of the switch terminals to (typically) the common row wire.  And all of the diodes must be oriented the same way.

Does that help?

 - Ron | samwisekoi
Auto-typed by my GH-122 keyboard.

1. Good to know

2. Can't I just then center the mounting holes on the keycaps to get them where I want?

3.  That thread was excellent. The picture showing the diodes and wiring was exactly the ticket.

Thanks, that was a big help.

[seattle_ice]

OK, I am almost done wiring the switch matrix, and will be ready to wire it all to the teensy. Can someone point me towards a resource that shows how to wire up the teensy?

[dantan]

I don't know if this is intended, but I notice all your photos have disappeared from this thread.

Maybe upload them to geekhack instead of to your photo account; that way even when you lose interest in this project and delete your photos we will have photos to see.

[seattle_ice]

I don't know if this is intended, but I notice all your photos have disappeared from this thread.

Maybe upload them to geekhack instead of to your photo account; that way even when you lose interest in this project and delete your photos we will have photos to see.

That's weird - all the links still work fine. And the photos are on a web server that has been up and running for 12 years now and is not going away anytime soon.

I just checked - it is not just my threads, I found a number of other threads in here that look the same (https://geekhack.org/index.php?topic=20898.0) - they must have  a problem on the forum or something.
 

[vextanys]

I'd suggest adding 1 wire to each row & column that ends in a "pin" (solid core wire of the right thickness will do) that can be inserted into breadboard. Adding pins to the Teensy and experimenting with the firmware (I've got my rows/columns/diodes wrong before)
For the final, a bit of stripboard can join the Teensy pins to the wires, or add sockets (I'm convinced I'll fry a Teensy one day with my soldering skills)
It should be as simple as connect each row to a (output?) pin, and each column to a (input?) pin, tweak the TMK settings and layout, and off you go

[seattle_ice]

I'd suggest adding 1 wire to each row & column that ends in a "pin" (solid core wire of the right thickness will do) that can be inserted into breadboard. Adding pins to the Teensy and experimenting with the firmware (I've got my rows/columns/diodes wrong before)
For the final, a bit of stripboard can join the Teensy pins to the wires, or add sockets (I'm convinced I'll fry a Teensy one day with my soldering skills)
It should be as simple as connect each row to a (output?) pin, and each column to a (input?) pin, tweak the TMK settings and layout, and off you go

I had purchased two header pin rails and two sockets exactly for that reason. If I need to move wires or whatever, they are not soldered directly to the board.

What I am having trouble with right now is the actual pinouts of all the physical connections to the teensy 2.  I have searched and read a ton of threads on here, but have just made myself confused. Which pins for the columns and rows? Are there any other connections besides the key matrix and the USB? 

I have 8 columns, and 7 rows in my matrix.

[vextanys]

I dont think it matters which pins you choose on the Teensy - its all configured through the firmware, though some pins have extra uses. D6 has an onboard LED (best not used for rows or columns unless you cant avoid it), the PWM pins can be used for controllable LEDs, and SPI/I2C (if you really want complicated... but thats probably not needed)
I tend to group the rows and columns as much as possible on the same port or same locality (i.e. rows on left pins, columns on right pins)

From https://www.pjrc.com/teensy/pinout.html use the ports (eg PB0, PF4, PC7) designations when changing the TMK matrix.c and config.h code

[seattle_ice]

OK, I have the matrix all wired up:


Will this work?

[TalkingTree]

By the look of it, it should work just fine.

[dantan]

I had purchased two header pin rails and two sockets exactly for that reason. If I need to move wires or whatever, they are not soldered directly to the board.

Do you have details like the exact specs and the pictures? I found that googling header pin rails got a lot of different pictures.

I'm a noob at this. But you basically solder the header pin rails to the teensy, then plug the wires into the holes like a breadboard right? I think soldering individual wires to the teensy would be very hard.

[seattle_ice]

OK, I have it all physically put together, and the wiring all done.



Now I could really use some input. I read the thread about TMK and started to follow the instructions for doing the firmware stuff but I am lost, and don't understand what I am doing.

I installed Virtuabox, installed an ubuntu image, and can log into the virtual machine via putty on Windows 10.

Now I have no idea what to do from there. Is there a how-to somewhere? Like, copy these files to a directory, change these files to represent your keystrokes, then compile it like so, and burn the firmware by doing this.

[TalkingTree]

I installed Virtuabox, installed an ubuntu image, and can log into the virtual machine via putty on Windows 10.

Now I have no idea what to do from there. Is there a how-to somewhere? Like, copy these files to a directory, change these files to represent your keystrokes, then compile it like so, and burn the firmware by doing this.

Logging through putty is an extra hassle if you ask me. You might want to share a folder between the virtual machine and your Windows' drives, I did that and it works. Google has plenty of tutorials for that.

[vextanys]

Its been awhile (and a new PC) since I last compiled the source.
Extract the source to a folder,
Find tmk_core/doc/build.md (open in a text editor) to work out what else you need to install and have on your path.
Then go to keyboard/gh60 and run make to see if you can compile some firmware.
Make a copy of the keyboard/gh60 folder for your project

Now try to edit the config.h / matrix.* / keymap.* to get the rows/columns/keymap you want.
- lots of docs, examples and help on https://geekhack.org/index.php?topic=41989.0
- config.h - change MATRIX_ROWS and MATRIX_COLS to 8 and PRODUCT_ID, MANUFACTURER, PRODUCT and DESCRIPTION for clarity
- matrix.c - change init_cols, read_cols, unselect_rows and select_row to match your pins
- keymap(_common).h - change the KEYMAP macro to match your layout (at least in rows/columns)
- keymap(_plain).c - change the keymaps array to use your new KEYMAP macro and the key definitions you want.

[seattle_ice]

Thanks, guys, I will give this all a try and see what happens.

[seattle_ice]

Now try to edit the config.h / matrix.* / keymap.* to get the rows/columns/keymap you want.
- lots of docs, examples and help on https://geekhack.org/index.php?topic=41989.0
- config.h - change MATRIX_ROWS and MATRIX_COLS to 8 and PRODUCT_ID, MANUFACTURER, PRODUCT and DESCRIPTION for clarity
- matrix.c - change init_cols, read_cols, unselect_rows and select_row to match your pins
- keymap(_common).h - change the KEYMAP macro to match your layout (at least in rows/columns)
- keymap(_plain).c - change the keymaps array to use your new KEYMAP macro and the key definitions you want.

Ok. I shared a folder between the Ubuntu VM and Windows so I could work on the text files.

1. I got the source downloaded, extracted, copied the   ~/Keyboard/GH60 folder to my own.

2. config.h   

Code: [Select]

#define MATRIX_ROWS 7
#define MATRIX_COLS 8
3. matrix.c

For the columns:

Code: [Select]

/* Column pin configuration
 * col: 0   1   2   3   4   5   6   7 
 * pin: B2  B3  B7  D0  D1  D2  D3  C6
 */
static void  init_cols(void)
{
   
DDRF  &= ~(1<<7 | 1<<6 | 1<<5 | 1<<4 | 1<<1 | 1<<0);
    PORTF |=  (1<<7 | 1<<6 | 1<<5 | 1<<4 | 1<<1 | 1<<0);
DDRD  &= ~(1<<3 | 1<<2 | 1<<1 | 1<<0);
    PORTD |=  (1<<3 | 1<<2 | 1<<1 | 1<<0);
DDRC  &= ~(1<<6);
    PORTC |=  (1<<6);
DDRB  &= ~(1<<7 | 1<<6 | 1<<3 | 1<<2);
    PORTB |=  (1<<7 | 1<<6 | 1<<3 | 1<<2);


}

And

Code: [Select]

static matrix_row_t read_cols(void)
{
       
return (PINB&(1<<2) ? 0 : (1<<0)) |
           (PINB&(1<<3) ? 0 : (1<<1)) |
           (PINB&(1<<7) ? 0 : (1<<2)) |
           (PIND&(1<<0) ? 0 : (1<<3)) |
           (PIND&(1<<1) ? 0 : (1<<4)) |
           (PIND&(1<<2) ? 0 : (1<<5)) |
           (PIND&(1<<3) ? 0 : (1<<6)) |
           (PINC&(1<<6) ? 0 : (1<<7));    
   
   
   
}

For the rows:

Code: [Select]

/* Row pin configuration
 * row: 0   1   2   3   4 5 6
 * pin: F0  F1  F4  F5  F6  F7  B6
 */
static void select_row(uint8_t row)
{
    // Output low(DDR:1, PORT:0) to select
    switch (row) {
        case 0:
            DDRD  |= (1<<0);
            PORTF &= ~(1<<0);
            break;
        case 1:
            DDRD  |= (1<<1);
            PORTF &= ~(1<<1);
            break;
        case 2:
            DDRD  |= (1<<2);
            PORTF &= ~(1<<4);
            break;
        case 3:
            DDRD  |= (1<<3);
            PORTF &= ~(1<<5);
            break;
        case 4:
            DDRD  |= (1<<5);
            PORTF &= ~(1<<6);
            break;
case 5:
            DDRD  |= (1<<5);
            PORTF &= ~(1<<7);
            break;
case 6:
            DDRD  |= (1<<5);
            PORTB &= ~(1<<6);
            break;
}
}
I am not sure what to put in the "unselect_rows" for my row matrix. Bit shifting is definitely not my strong suit.

Code: [Select]

/* Row pin configuration
 * row: 0   1   2   3   4 5 6
 * pin: F0  F1  F4  F5  F6  F7  B6
 */
static void unselect_rows(void)
{
    // Hi-Z(DDR:0, PORT:0) to unselect
    DDRD  &= ~0b00101111;
    PORTD &= ~0b00101111;
}

[TalkingTree]

I am not sure what to put in the "unselect_rows" for my row matrix. Bit shifting is definitely not my strong suit.

You have to unselect all the rows you're using by setting them to 1. The code reads from right to left of ~0b (i.e. from pin 7 to 0).

It's easy, but if you're lazy, here's your code:

More

Code: [Select]

/* Row pin configuration
 * row: 0   1   2   3   4 5 6
 * pin: F0  F1  F4  F5  F6  F7  B6
 */
static void unselect_rows(void)
{
    // Hi-Z(DDR:0, PORT:0) to unselect
    DDRB  &= ~0b01000000;
    PORTB &= ~0b01000000;
    DDRF  &= ~0b11110011;
    PORTF &= ~0b11110011;
}

[seattle_ice]

I am not sure what to put in the "unselect_rows" for my row matrix. Bit shifting is definitely not my strong suit.

You have to unselect all the rows you're using by setting them to 1. The code reads from right to left of ~0b (i.e. from pin 7 to 0).

It's easy, but if you're lazy, here's your code:

More

Code: [Select]

/* Row pin configuration
 * row: 0   1   2   3   4 5 6
 * pin: F0  F1  F4  F5  F6  F7  B6
 */
static void unselect_rows(void)
{
    // Hi-Z(DDR:0, PORT:0) to unselect
    DDRB  &= ~0b01000000;
    PORTB &= ~0b01000000;
    DDRF  &= ~0b11110011;
    PORTF &= ~0b11110011;
}

Thanks, but what a totally uncalled for comment. I am certainly not lazy, and don't ask a question on here until I have read a bunch and looked at examples and tried to figure it out, but when you have never done it, it can be confusing.  You download the source, and there are hundreds of files with code that might as well be chinese for some people, and spend hours looking through it, then when you can't figure it out and ask a question, some douche with a patronizing attitude wants to slam you on a public forum. I am sure you have just learned everything ever all on your own, so good for you, but your skill set and mine obviously don't align.

As for all the other people on here that have taken the time to (graciously) answer questions, thank you very much, it is hugely appreciated.

And I still don't understand that code in the unselect. I see you added a row for the B ports, and the F ports, but what about the C port?

From the GH60 matrix.c, how does ~0b00101111 equate to 'D0  D1  D2  D3  D5'?

[TalkingTree]

Thanks, but what a totally uncalled for comment. I am certainly not lazy, and don't ask a question on here until I have read a bunch and looked at examples and tried to figure it out, but when you have never done it, it can be confusing.  You download the source, and there are hundreds of files with code that might as well be chinese for some people, and spend hours looking through it, then when you can't figure it out and ask a question, some douche with a patronizing attitude wants to slam you on a public forum. I am sure you have just learned everything ever all on your own, so good for you, but your skill set and mine obviously don't align.

Frankly, I didn't mean to make fun of you, my bad if it sounded like that.

I see you added a row for the B ports, and the F ports, but what about the C port?

You don't have rows on any C pin, only on B and F, by the look of the code you posted.

From the GH60 matrix.c, how does ~0b00101111 equate to 'D0  D1  D2  D3  D5'?

Focus on the bit to the right of ~0b, i.e. 00101111.

It goes from right to left, so the last number actually points to D0, which is shifted to 1, while the first one is D7, which is 0.

[seattle_ice]

Talking Tree:

Thank you for the apology, I probably went overboard in my response, and was talking as much from frustration at not "getting it" as anything.

And yes, the C pin is the column, not the row.

So it is not bit shifting, just a flag that increments from right to left?  So F0, F1, F5, F6 in an 8 row set would be ~0b00110011?

[TalkingTree]

Thank you for the apology, I probably went overboard in my response, and was talking as much from frustration at not "getting it" as anything.

It was a mere misunderstanding. It's ok.

So it is not bit shifting, just a flag that increments from right to left?

Correct.

So F0, F1, F5, F6 in an 8 row set would be ~0b00110011?

~0b01100011

[vextanys]

You could write your unselect_rows like this

    DDRF  &= ~(1<<7 | 1<<6 | 1<<5 | 1<<4 | 1<<1 | 1<<0);
    PORTF &= ~(1<<7 | 1<<6 | 1<<5 | 1<<4 | 1<<1 | 1<<0);
    DDRB  &= ~(1<<6);
    PORTB &= ~(1<<6);

If it makes more sense. I'm not sure why the original code uses different styles for unselect_rows and init_cols, but they are equivalent and the compiler should produce the same code from them, in the most efficient way possible, which is likely stored as just a number constant.

It does look like your setting port F and B6 unnecessarily in the init_cols call too. Though the values will be overridden later when the matrix is scanning, so it will only use a few more bytes of code space and not change how the firmware works

I hope this formats properly, port assignment mapping to binary number vertically.

Code: [Select]

   D7 D6 D5 D4 D3 D2 D1 D0
~0b0  0  1  0  1  1  1  1


[seattle_ice]

It does look like your setting port F and B6 unnecessarily in the init_cols call too...

Yes, I was. I removed those lines for clarity.  The conceptual problem I was having was my brain kept wanting to translate the bit shifting to binary flags, and I was stuck there wondering how 00100110 was not 19 or 38 something.


OK, here is my initial stab at the Keymap:

[ Specified attachment is not available ]

[vextanys]

Do you mean Right Alt and Right Shift? Conceptually they perform the same action, but report as different keys, so can be interpreted differently.
Some regional keyboard settings tend to treat RAlt differently (as AltGr https://en.wikipedia.org/wiki/AltGr_key), mainly producing accented letters in combinations.
Games may also treat this as different, but I'm not sure on examples and how they differ.

The keymap does look good, covers most of the keys commonly used, and has enough other keys for remapping if needed.

[seattle_ice]

Do you mean Right Alt and Right Shift? Conceptually they perform the same action, but report as different keys, so can be interpreted differently.
Some regional keyboard settings tend to treat RAlt differently (as AltGr https://en.wikipedia.org/wiki/AltGr_key), mainly producing accented letters in combinations.
Games may also treat this as different, but I'm not sure on examples and how they differ.

The keymap does look good, covers most of the keys commonly used, and has enough other keys for remapping if needed.

I included tab, shift and alt because they are all used for various gaming functions - 'shift + tab' is the default to bring up the Steam overlay, 'Tab' is the scoreboard, and I use 'Alt' + (various numbers) for things like toggling twitch streaming, fps counters, etc.

I used the right side since my normal gaming mode is using the arrow keys for movement, and these would involve the least remapping of my games. I was not aware there were any substantial differences between the left/right versions.