forked from mirrors/qmk_firmware
update readme
This commit is contained in:
parent
468e855207
commit
0f06e94d5d
1 changed files with 8 additions and 6 deletions
|
@ -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/`
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue