Do you like the ortholinear keyboards, but are you not so enthusiastic to empty your wallet? This is could be an affordable solution 😎 In other words, the world's first 40% keyboard based on the Raspberry Pi Pico.
Some advice for you:
- This project needs a 3D Printer for the chassis, if you have no 3D Printer, you can use an Online Service, but remember that all STL files are at your disposal under Patreon, so, take into account this additional expense.
- The actual code over GitHub is a fork of a previous version of the KMK project, so it could not work without properly updating to the brand new version. Take into account only my fork on my GitHub if you want to add other features.
- I'll not publish any detail about the schematic, there are lots of documentations online, see refer to the pictures if you want to follow my steps, or moreover, follows the code if you want to accomplish the same schematic.
- Last suggestion. If you want a Bluetooth Keyboard (that's not for me for several reasons), you only need an ESP32. Please, not be seen or heard to make a bunch of low-level hardware with Raspberry Pi Pico and Esp32 together and only just to add the radio function to your keyboard! An Esp32 with micro-python onboard is the cheap way for a keyboard with radio features, with low effort and expenses. In this context, I rather concur with the opinion of Sachin Soni (alias techiesms) in his video "Watch it before buying Raspberry Pi Pico", so please "stay in the ranks" and "keep calm with raspberry pi hip".
The new hip isn't the brand new square, paraphrasing "hip to be square". So, right now, that I have made a lot of friends among Upton's enthusiasts we can start.
There is just one thing for which I think the new Raspberry Pi Pico could be a cheap solution compared to all others hardware on the market, that is the USB HID interface (leave a comment if you want to change my mind...). The cost for a development board like this is affordable. It is possible to simulate several human interfaces like a mouse, joypad, keyboard and so on, but what most interest us right now is the keyboard simulation.
There are several methods to achieve our goal, but a good (not the best) solution right now is to use the KMK firmware library for micro-python. It's a porting of the most famous QMK firmware for micro-python, do not include all features of the old one, but it's enough for our purpose. Sometimes you could get some issues from KMK firmware, it's quite normal because it's under development and I also had to solve several problems, but I think the state-of-the-art is acceptable, and... anyway... I think you can approve some features I added on.
A small disclaimer: All features could not work on the new version of KMK firmware without modifications (as anticipated in the advice). For example, I connected the behaviour of RGB LED Matrix to the internal State Machine and I have already seen that's changed in the last version, so pay attention!
The Raspberry Pi Pico pinout allows us to make a standard keyboard, but in my opinion, a 40% Keyboard is a right tradeoff between usability and features. Moreover, the components are not too much to allow us to keep costs low.
The pinout I have chosen for the columns is:
This one for the rows:
GPIO14, GPIO15, GPIO16, GPIO17
The pin connection follows the picture below.
The transfer frequency with these diodes (tested on Pico without KMM firmware and with an oscilloscope) is acceptable until 4ms, this transfer is enough for programming and gaming, in my opinion.
The sample code to test this characteristic is the one below:
import time
import board
import digitalio
pin_out = digitalio.DigitalInOut(board.GP1)
pin_out.direction = digitalio.Direction.OUTPUT
pin_in = digitalio.DigitalInOut(board.GP10)
pin_in.direction = digitalio.Direction.INPUT
while True:
if pin_in.value:
pin_out.value = False
time.sleep(0.002)
else:
pin_out.value = True
time.sleep(0.002)
I started from this code to confirm the wanted performance from my keyboard, at least theoretical performance. These performances must be confirmed on the KMK firmware side, which is not trivial, because with the firmware we have to work with a state machine, without mention the matrix led via WS2812B for the colour visual effect.
About the matrix led. There is also this time several solutions, usually are used addressed LEDs, like WS2812B. In my opinion, better than a standard RGB led strip are the WS2812B on PIXEL PCBs (100 pcs WS2812B addressed boards cost 16 euros on Amazon Italy), just because all PCB boards can be connected with low elastic strength by some simple wires. Have to be made 4 rows for every keyboard row, connected following a zigzag pattern row by row to cover all the keyboard.
The Adafruit library to control by software these addressed pixels is integrated into the adafruit circuitpython .uf2 file, you don't need more, it's supported natively by KMK firmware and the advantage of this design is to use just only one gpio, in my design the GPIO28. If you want to improve the pixel LEDs refresh rate, you can change the design and made a direct matrix by connecting any single led row to a separate gpio. Of course, in this case, the software animations have to be modded for this kind of configuration.
About the chassis. Based on VOID40, I just made 4 different frames inspired by this project.
The TOP GRID stl was separated into two pieces, a simple frame printed in gold PLA and the internal grid to connect the switches in transparent PETG, in this way the RGB light made a glowing light around every keycap and the PETG material of the grid makes it more solid for typing. Frame in gold PLA and grid in transparent PETG can be glued together in one piece with simple cyanoacrylate glue. The BOTTOM side was printed in marble PLA, nice to see and solid, just added some new pin design to make it easy for the object printing the instead of the old pins. The last piece is a LED GRID, to connect all the WS2812B in the right decentred way. This solution could seem strange, but in reality, it was made to align the RGB pixel with the position on keycaps and switches, in this way, you can take advantage of the three led holes on the switches to enlighten the backside of characters opened on the keycaps with the pixels. You can made some switches mod to emphasize this effect if you want. All the printed parts were made with a 0.8 nozzle on a standard Ender 3, in a day you can print all the parts and they fit on the bed plate.
All the STL will be on my Patreon.
About the software. As said, KMK firmware is the base, I made a fork far ago, so the two versions (on the fork and the new one of KMK firmware) are pretty different, but in poor words could be aligned in future.
from keymap_italian import *
I'm Italian, so I made a keymap_italian configuration and import it into the main file, but you can make your language configuration and add a new one. If you are English this change is pretty simple, but the keycaps functions probably will change, so pay attention. To make other language configurations, you can make a porting starting from these .h files of QMK.
After the KMKKeyboard class configuration, you can find the RGB configuration of the class. The base colour is white (configurable) in static mode and set the maximum library speed to 10. Some minor settings occur before the animation level functions. There are two Functions and a Class that control the animation execution associated with keyboard level activation.
class StateControll
def Led_Array(keycaps)
def Level_Animation(self)
The trick has been to connect the animation directly with the internal state machine, there is a functionality called ".before_press_handler" explained into keys.md help, but it never worked for me.
Instead, the connection to the internal state machine has several advantages. First, every time you'll change a layer, the handler "Level_Animation" will change the RGB pixel state animation automatically; at this moment all animations are static because my intention was to visualize the layer change and the configuration of keycaps too just in one time. It's useful if you change the layer and you looking for visual feedback from the keyboard.
Then, the colour of the keycaps are associated with the typing keys, in this way, you know what you can type or not, just looking at the colour. Sure, it would be nice to have a mention of the keys, but maybe this could become a future update.
The Led_Array function simple translate the keys in its typing type defining two lists (leds_on, leds_off) and the class StateControll it was used just to define a static variable about the pre-state of the state machine. Following the configuration of user animation.
keyboard.rgb_config['animation_mode'] = 'user'
keyboard.rgb_config['user_animation'] = Level_Animation
The script ends with the keyboard.keymap that I choose to make my personal 40% development layout. This development layout is under development, sorry for the pun, and it can change depending on my typing experience. So stay tuned if you want to discover all the future updates.
I think that's enough for now, if you got any questions about the keyboard, info or suggestions, please let me a comment below.
Refer to my Github page for the software updates.
No comments:
Post a Comment
Hi at all, leave me a feedback for this post. Thx