summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJames Young <xxiinophobia@yahoo.com>2020-02-26 14:02:03 -0800
committerskullydazed <skullydazed@users.noreply.github.com>2020-03-05 16:00:10 -0800
commit906bdce6cee512e73faa527f01019addf8db6acc (patch)
treeaff7aa4609a1fa2cd8f3ae95e7154ca8639d344e
parent3bd65d2173e8f8d136cb159eb980941479ab5906 (diff)
split Hand Wire Preamble to a separate doc
-rw-r--r--docs/_summary.md1
-rw-r--r--docs/hand_wire.md109
-rw-r--r--docs/how_a_matrix_works.md107
3 files changed, 108 insertions, 109 deletions
diff --git a/docs/_summary.md b/docs/_summary.md
index 9e80825f62..0aadb15480 100644
--- a/docs/_summary.md
+++ b/docs/_summary.md
@@ -148,6 +148,7 @@
* For a Deeper Understanding
* [How Keyboards Work](how_keyboards_work.md)
+ * [How a Matrix Works](how_a_matrix_works.md)
* [Understanding QMK](understanding_qmk.md)
* QMK Internals (In Progress)
diff --git a/docs/hand_wire.md b/docs/hand_wire.md
index 0e750f160a..3ca6f242dc 100644
--- a/docs/hand_wire.md
+++ b/docs/hand_wire.md
@@ -1,114 +1,5 @@
# Hand-Wiring Guide
-## Preamble: How a Keyboard Matrix Works (and why we need diodes)
-
-The collapsible section below covers why keyboards are wired the way they are, as outlined in this guide. It isn't required reading to make your own hand wired keyboard, but provides background information.
-
-<details>
-
-<summary>Click for details</summary>
-
-Without a matrix circuit each switch would require its own wire directly to the controller.
-
-Simply put, when the circuit is arranged in rows and columns, if a key is pressed, a column wire makes contact with a row wire and completes a circuit. The keyboard controller detects this closed circuit and registers it as a key press.
-
-The microcontroller will be setup up via the firmware to send a logical 1 to the columns, one at a time, and read from the rows, all at once - this process is called matrix scanning. The matrix is a bunch of open switches that, by default, don't allow any current to pass through - the firmware will read this as no keys being pressed. As soon as you press one key down, the logical 1 that was coming from the column the keyswitch is attached to gets passed through the switch and to the corresponding row - check out the following 2x2 example:
-
- Column 0 being scanned Column 1 being scanned
- x x
- col0 col1 col0 col1
- | | | |
- row0 ---(key0)---(key1) row0 ---(key0)---(key1)
- | | | |
- row1 ---(key2)---(key3) row1 ---(key2)---(key3)
-
-The `x` represents that the column/row associated has a value of 1, or is HIGH. Here, we see that no keys are being pressed, so no rows get an `x`. For one keyswitch, keep in mind that one side of the contacts is connected to its row, and the other, its column.
-
-When we press `key0`, `col0` gets connected to `row0`, so the values that the firmware receives for that row is `0b01` (the `0b` here means that this is a bit value, meaning all of the following digits are bits - 0 or 1 - and represent the keys in that column). We'll use this notation to show when a keyswitch has been pressed, to show that the column and row are being connected:
-
- Column 0 being scanned Column 1 being scanned
- x x
- col0 col1 col0 col1
- | | | |
- x row0 ---(-+-0)---(key1) row0 ---(-+-0)---(key1)
- | | | |
- row1 ---(key2)---(key3) row1 ---(key2)---(key3)
-
-We can now see that `row0` has an `x`, so has the value of 1. As a whole, the data the firmware receives when `key0` is pressed is
-
- col0: 0b01
- col1: 0b00
- │└row0
- └row1
-
-A problem arises when you start pressing more than one key at a time. Looking at our matrix again, it should become pretty obvious:
-
- Column 0 being scanned Column 1 being scanned
- x x
- col0 col1 col0 col1
- | | | |
- x row0 ---(-+-0)---(-+-1) x row0 ---(-+-0)---(-+-1)
- | | | |
- x row1 ---(key2)---(-+-3) x row1 ---(key2)---(-+-3)
-
- Remember that this ^ is still connected to row1
-
-The data we get from that is:
-
- col0: 0b11
- col1: 0b11
- │└row0
- └row1
-
-Which isn't accurate, since we only have 3 keys pressed down, not all 4. This behavior is called ghosting, and only happens in odd scenarios like this, but can be much more common on a bigger keyboard. The way we can get around this is by placing a diode after the keyswitch, but before it connects to its row. A diode only allows current to pass through one way, which will protect our other columns/rows from being activated in the previous example. We'll represent a dioded matrix like this;
-
- Column 0 being scanned Column 1 being scanned
- x x
- col0 col1 col0 col1
- │ │ | │
- (key0) (key1) (key0) (key1)
- ! │ ! │ ! | ! │
- row0 ─────┴────────┘ │ row0 ─────┴────────┘ │
- │ │ | │
- (key2) (key3) (key2) (key3)
- ! ! ! !
- row1 ─────┴────────┘ row1 ─────┴────────┘
-
-In practical applications, the black line of the diode will be placed facing the row, and away from the keyswitch - the `!` in this case is the diode, where the gap represents the black line. A good way to remember this is to think of this symbol: `>|`
-
-Now when we press the three keys, invoking what would be a ghosting scenario:
-
- Column 0 being scanned Column 1 being scanned
- x x
- col0 col1 col0 col1
- │ │ │ │
- (┌─┤0) (┌─┤1) (┌─┤0) (┌─┤1)
- ! │ ! │ ! │ ! │
- x row0 ─────┴────────┘ │ x row0 ─────┴────────┘ │
- │ │ │ │
- (key2) (┌─┘3) (key2) (┌─┘3)
- ! ! ! !
- row1 ─────┴────────┘ x row1 ─────┴────────┘
-
-Things act as they should! Which will get us the following data:
-
- col0: 0b01
- col1: 0b11
- │└row0
- └row1
-
-The firmware can then use this correct data to detect what it should do, and eventually, what signals it needs to send to the OS.
-
-Further reading:
-- [Wikipedia article](https://en.wikipedia.org/wiki/Keyboard_matrix_circuit)
-- [Deskthority article](https://deskthority.net/wiki/Keyboard_matrix)
-- [Keyboard Matrix Help by Dave Dribin (2000)](https://www.dribin.org/dave/keyboard/one_html/)
-- [How Key Matrices Works by PCBheaven](http://pcbheaven.com/wikipages/How_Key_Matrices_Works/) (animated examples)
-- [How keyboards work - QMK documentation](how_keyboards_work.md)
-
-</details>
-
-
## Parts list
You will need: (where *x* is the number of keys on your planned keyboard)
diff --git a/docs/how_a_matrix_works.md b/docs/how_a_matrix_works.md
new file mode 100644
index 0000000000..bc31bb877c
--- /dev/null
+++ b/docs/how_a_matrix_works.md
@@ -0,0 +1,107 @@
+## Preamble: How a Keyboard Matrix Works (and why we need diodes)
+
+The collapsible section below covers why keyboards are wired the way they are, as outlined in this guide. It isn't required reading to make your own hand wired keyboard, but provides background information.
+
+<details>
+
+<summary>Click for details</summary>
+
+Without a matrix circuit each switch would require its own wire directly to the controller.
+
+Simply put, when the circuit is arranged in rows and columns, if a key is pressed, a column wire makes contact with a row wire and completes a circuit. The keyboard controller detects this closed circuit and registers it as a key press.
+
+The microcontroller will be setup up via the firmware to send a logical 1 to the columns, one at a time, and read from the rows, all at once - this process is called matrix scanning. The matrix is a bunch of open switches that, by default, don't allow any current to pass through - the firmware will read this as no keys being pressed. As soon as you press one key down, the logical 1 that was coming from the column the keyswitch is attached to gets passed through the switch and to the corresponding row - check out the following 2x2 example:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ | | | |
+ row0 ---(key0)---(key1) row0 ---(key0)---(key1)
+ | | | |
+ row1 ---(key2)---(key3) row1 ---(key2)---(key3)
+
+The `x` represents that the column/row associated has a value of 1, or is HIGH. Here, we see that no keys are being pressed, so no rows get an `x`. For one keyswitch, keep in mind that one side of the contacts is connected to its row, and the other, its column.
+
+When we press `key0`, `col0` gets connected to `row0`, so the values that the firmware receives for that row is `0b01` (the `0b` here means that this is a bit value, meaning all of the following digits are bits - 0 or 1 - and represent the keys in that column). We'll use this notation to show when a keyswitch has been pressed, to show that the column and row are being connected:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ | | | |
+ x row0 ---(-+-0)---(key1) row0 ---(-+-0)---(key1)
+ | | | |
+ row1 ---(key2)---(key3) row1 ---(key2)---(key3)
+
+We can now see that `row0` has an `x`, so has the value of 1. As a whole, the data the firmware receives when `key0` is pressed is
+
+ col0: 0b01
+ col1: 0b00
+ │└row0
+ └row1
+
+A problem arises when you start pressing more than one key at a time. Looking at our matrix again, it should become pretty obvious:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ | | | |
+ x row0 ---(-+-0)---(-+-1) x row0 ---(-+-0)---(-+-1)
+ | | | |
+ x row1 ---(key2)---(-+-3) x row1 ---(key2)---(-+-3)
+
+ Remember that this ^ is still connected to row1
+
+The data we get from that is:
+
+ col0: 0b11
+ col1: 0b11
+ │└row0
+ └row1
+
+Which isn't accurate, since we only have 3 keys pressed down, not all 4. This behavior is called ghosting, and only happens in odd scenarios like this, but can be much more common on a bigger keyboard. The way we can get around this is by placing a diode after the keyswitch, but before it connects to its row. A diode only allows current to pass through one way, which will protect our other columns/rows from being activated in the previous example. We'll represent a dioded matrix like this;
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ │ │ | │
+ (key0) (key1) (key0) (key1)
+ ! │ ! │ ! | ! │
+ row0 ─────┴────────┘ │ row0 ─────┴────────┘ │
+ │ │ | │
+ (key2) (key3) (key2) (key3)
+ ! ! ! !
+ row1 ─────┴────────┘ row1 ─────┴────────┘
+
+In practical applications, the black line of the diode will be placed facing the row, and away from the keyswitch - the `!` in this case is the diode, where the gap represents the black line. A good way to remember this is to think of this symbol: `>|`
+
+Now when we press the three keys, invoking what would be a ghosting scenario:
+
+ Column 0 being scanned Column 1 being scanned
+ x x
+ col0 col1 col0 col1
+ │ │ │ │
+ (┌─┤0) (┌─┤1) (┌─┤0) (┌─┤1)
+ ! │ ! │ ! │ ! │
+ x row0 ─────┴────────┘ │ x row0 ─────┴────────┘ │
+ │ │ │ │
+ (key2) (┌─┘3) (key2) (┌─┘3)
+ ! ! ! !
+ row1 ─────┴────────┘ x row1 ─────┴────────┘
+
+Things act as they should! Which will get us the following data:
+
+ col0: 0b01
+ col1: 0b11
+ │└row0
+ └row1
+
+The firmware can then use this correct data to detect what it should do, and eventually, what signals it needs to send to the OS.
+
+Further reading:
+- [Wikipedia article](https://en.wikipedia.org/wiki/Keyboard_matrix_circuit)
+- [Deskthority article](https://deskthority.net/wiki/Keyboard_matrix)
+- [Keyboard Matrix Help by Dave Dribin (2000)](https://www.dribin.org/dave/keyboard/one_html/)
+- [How Key Matrices Works by PCBheaven](http://pcbheaven.com/wikipages/How_Key_Matrices_Works/) (animated examples)
+- [How keyboards work - QMK documentation](how_keyboards_work.md)
+
+</details>