diff options
author | SethSenpai <pimwing@gmail.com> | 2016-10-03 09:07:37 +0000 |
---|---|---|
committer | SethSenpai <pimwing@gmail.com> | 2016-10-03 09:07:37 +0000 |
commit | 0f06e94d5d8a07d0d896bf2cc72058ae11d17450 (patch) | |
tree | f562b67c6ddf385701119ed6556b405ffc132c6e /keyboards/handwired | |
parent | 468e8552072971c773ec166844d179089c544dc5 (diff) |
update readme
Diffstat (limited to 'keyboards/handwired')
-rw-r--r-- | keyboards/handwired/gamenum/README.md | 14 |
1 files changed, 8 insertions, 6 deletions
diff --git a/keyboards/handwired/gamenum/README.md b/keyboards/handwired/gamenum/README.md index 22f67ee61e..9e22ff2fcb 100644 --- a/keyboards/handwired/gamenum/README.md +++ b/keyboards/handwired/gamenum/README.md @@ -2,14 +2,14 @@ GameNum firmware ====================== ## Board overview -The GameNum was designed to facilitate the use of mechanical keys for gameing even when your packing space is limited. +The GameNum was designed to facilitate the use of mechanical keys for gaming even when your packing space is limited. It uses a standard numpad layout replacing the NumLock key with a layer toggle that allows you to cycle through the different layers. The standard layout features a default layer that acts as a standard numpad, a layer that was meant for simple WASD based games and a layer that was designed to be used for MOBA/RTS related games. The RTS layer is meant to be used rotating the device 90 degrees counterclockwise. The README.MD for this board is reasonably extensive and in-depth because the build is quite small and covers a lot of things that I feel that it would be a good starting point for getting into QMK. -## Build conciderations +## Build considerations Since the GameNum is handwired and uses 2 of its pins to toggle indicator lights there are some things to keep in mind. Firmware was build for use with a Pro Micro based on a ATMEGA32u4 at 16mHz. @@ -20,7 +20,7 @@ Schematic of the build is coming soon. ## Adding more layers -Adding aditional layers is pretty straight foreward. Look in `keymaps/default/keymap.c` and find `#define OSY 2` add a new definition for the layer you are going to add. This can be named pretty much anything. Example: `#define NAMEHERE 3`. +Adding additional layers is pretty straight forward. Look in `keymaps/default/keymap.c` and find `#define OSY 2` add a new definition for the layer you are going to add. This can be named pretty much anything. Example: `#define NAMEHERE 3`. Keep in mind here that the number after the name should correspond with the number that the layer has in the stack of layers. Next thing to do is to add the actual layer for the keymap. @@ -50,9 +50,9 @@ Look for this piece of code: PORTD &= ~(1<<4); ``` -Copy it and change the letter after DDR and PORT to the letter of your pin. Change the 4 to the number of your pin. `DDRx |= (1<<y);` defines that pin as an ouput. `PORTx &= ~(1<<y);` sets the pin to LOW turning off the LED. +Copy it and change the letter after DDR and PORT to the letter of your pin. Change the 4 to the number of your pin. `DDRx |= (1<<y);` defines that pin as an output. `PORTx &= ~(1<<y);` sets the pin to LOW turning off the LED. -Now go back to `keymap.c` and look for the `process_record_user` function. The function is basicly a switch case that checks if you pushed one of the defined layer-switch buttons. When it sees that you pushed one of them it sets the pins of the LED's either low or high. +Now go back to `keymap.c` and look for the `process_record_user` function. The function is basically a switch case that checks if you pushed one of the defined layer-switch buttons. When it sees that you pushed one of them it sets the pins of the LED's either low or high. ``` case KC_FN1: @@ -75,7 +75,7 @@ For the full Quantum feature list, see [the parent readme.md](/doc/readme.md). Download or clone the whole firmware and navigate to the keyboards/handwired/gamenum folder. Read the README.md for the qmk repository on how to set up your developer enviroment to build your firmware with. Building firmware on Windows can be a bit of a hassle. Linux is a lot easier to use if you have some experience with it. A raspberry pi will already be able to build the firmware for you. -Once your dev env is setup, you'll be able to type `make` to generate your .hex - you can then use AVRDudess to program your .hex file. +Once your dev env is set up, you'll be able to type `make` to generate your .hex - you can then use AVRDudess to program your .hex file. ### Default @@ -90,3 +90,5 @@ $ make keymap=[default|jack|<name>] ``` Keymaps follow the format **__keymap.c__** and are stored in folders in the `keymaps` folder, eg `keymaps/my_keymap/` + + |