|
|
|
@ -133,21 +133,21 @@ Tools主要是提供一些三方的工具软件,比如**STM32 ST-LINK Utility*
|
|
|
|
|
|
|
|
|
|
为了充分发挥视频中提到的移位寄存器扫描方案的优势,固件代码中将PCB Layout走线和按键扫描顺序解耦,通过软件进行重映射。也就是说PCB中按键的连接可以是任意的,走完线之后可以在`hw_keyboard.h`文件中的`keyMap[KEYMAP_NUM][IO_NUMBER]`中指定映射方式。
|
|
|
|
|
|
|
|
|
|
> 这是一个二维数组,代表有**KEYMAP_NUM**层键位映射,每一层有`IO_NUMBER`个按键(也就是你的键盘按键数目);其中第0层是特殊的,负责映射PCB按键的随机布局到键盘标准按键布局,后续的1、2、3、4...层都是自定义的,负责映射标准按键布局到任意布局。
|
|
|
|
|
> 这是一个二维数组,代表有`KEYMAP_NUM`层键位映射,每一层有`IO_NUMBER`个按键(也就是你的键盘按键数目);其中第0层是特殊的,负责映射PCB按键的随机布局到键盘标准按键布局,后续的1、2、3、4...层都是自定义的,负责映射标准按键布局到任意布局。
|
|
|
|
|
|
|
|
|
|
**举个例子:**
|
|
|
|
|
|
|
|
|
|
考虑原理图中箭头指的那个按键,这个按键可以在PCB的任意位置,但我们可以看到它是从左到右(按74HC165的连接顺序,也即移位扫描顺序)的第9颗,因此它的编号为9.
|
|
|
|
|
考虑原理图中箭头指的那个按键,这个按键可以在PCB的任意位置,但是我们可以看到,它是从左到右(按74HC165的连接顺序,也即移位扫描顺序)的第10颗,因此它的编号为9(从0开始算).
|
|
|
|
|
|
|
|
|
|
![hw2](5.Docs/2.Images/hw5.jpg)
|
|
|
|
|
|
|
|
|
|
如果我们在实际的PCB板上把它放在了**右边Alt**的位置,那么参考在下图代码红色框中的第1层映射(也就是标准布局)中的**RIGHT_ALT**的序号是76,那么在第0层映射的76号变量就填入9(蓝色框).
|
|
|
|
|
如果我们在实际的PCB板上把它放在了**右边Alt**的位置,那么参考在下图代码**红色框**中的第1层映射(也就是标准布局)中的`RIGHT_ALT`的序号是76,那么在第0层映射的76号变量就填入9(蓝色框).
|
|
|
|
|
|
|
|
|
|
这样依次把你PCB上所有按键都填入0层映射,就得到了一个映射好的标准键盘了。后续2、3、4、5...层需要怎么映射就随意修改添加即可,也不需要再使用数字编号,而是可以直接用枚举的按键名称很方便。
|
|
|
|
|
|
|
|
|
|
> 所以对于想修改键盘配列的人,只需要再原理图上添加或删减几个串联的74HC165,然后PCB随意走线,再将代码中0层映射删减或增加一些数字即可(比如在下面的例子中我的键盘是83键的);后面几层的修改就以此类推了。
|
|
|
|
|
|
|
|
|
|
代码中通过`keyboard.Remap(2)`函数来映射不同层,比如这一句是使用第2层映射。
|
|
|
|
|
代码中通过`keyboard.Remap`函数来映射不同层,比如`keyboard.Remap(2)`这一句是使用第2层映射。
|
|
|
|
|
|
|
|
|
|
![hw2](5.Docs/2.Images/hw6.jpg)
|
|
|
|
|
|
|
|
|
@ -159,11 +159,11 @@ Tools主要是提供一些三方的工具软件,比如**STM32 ST-LINK Utility*
|
|
|
|
|
|
|
|
|
|
在QMK的[qmk_firmware/feature_debounce_type](https://github.com/qmk/qmk_firmware/blob/master/docs/feature_debounce_type.md)文档中描述了其使用的几种滤波方法,分为Eager和Defer、对称和非对称等,
|
|
|
|
|
|
|
|
|
|
默认是使用**对称延迟全局滤波**,也就是说是对所有按键进行同等的滤波,等所有的按键都稳定了不再,再提交扫描数据。
|
|
|
|
|
默认是使用**对称延迟全局滤波**,也就是说是对所有按键进行同等的滤波,等所有的按键都稳定了不再变化,再提交扫描数据。
|
|
|
|
|
|
|
|
|
|
> 与之对应的是激进滤波方法,也就是说一旦检测到按键变化就提交数据,但是在这之后的N毫秒时间内不再响应任何按键(也就避免了把不断抖动的按键提交上去)。但是这种方法对噪声很敏感,容易误触发。
|
|
|
|
|
> 与之对应的是激进滤波方法,也就是说一旦检测到按键变化就提交数据,但是在这之后的N毫秒时间内不再响应任何按键(也就避免了把不断抖动的按键提交上去)。这种方法触发延迟低,但是对噪声很敏感,容易误触发。
|
|
|
|
|
|
|
|
|
|
我在瀚文的固件中使用的是**对称延迟独立滤波**,也就是对每个按键进行两次检测,如果第一次检测到了按键变化,那么相隔N微秒(这个参数可以配置,大于按键典型抖动时间即可)再检测一次,如果两次检测结果一致,那么判断按键被按下,此时可以确保按键发生了变化,且不会重复触发按键。
|
|
|
|
|
我在瀚文的固件中使用的是**对称延迟独立滤波**,也就是对每个按键进行两次检测,如果第一次检测到了按键变化,那么相隔N微秒(这个参数可以配置,大于按键典型抖动时间即可)再检测一次,如果两次检测结果一致,那么判断按键被按下,此时可以确保按键发生了变化,且不会重复触发按键,兼顾延迟和稳定性。
|
|
|
|
|
|
|
|
|
|
这个过程是通过异或运算进行高效处理的,正好按键buffer由于是移位寄存器扫描得到的,本身就是每一位代表一个按键,所以滤波效率非常高,实测效果也挺好的。
|
|
|
|
|
|
|
|
|
@ -177,7 +177,7 @@ Tools主要是提供一些三方的工具软件,比如**STM32 ST-LINK Utility*
|
|
|
|
|
|
|
|
|
|
代码中使用的是单总线的ws2812b系列灯珠,一根线就可以串联一大堆RGB,而且代码中实现了SPI-DMA模拟时序,得到了超高的刷新率。
|
|
|
|
|
|
|
|
|
|
目前代码里只写了一个demo等效(非常简单就是轮询色彩),自己添加额外的灯效的话,通过`keyboard.SetRgbBuffer`函数设置RGB值,然后`SyncLights`把数据发送给LED即可:
|
|
|
|
|
目前代码里只写了一个demo灯效(非常简单就是轮询色彩),自己添加额外的灯效的话,通过`keyboard.SetRgbBuffer`函数设置RGB值,然后`SyncLights`把数据发送给LED即可:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
while (true)
|
|
|
|
|