kbfirmware.com has been my go-to tool for creating initial firmware for custom keyboards and macro pads. After creating the firmware it’s copied to a Linux system in the already installed and working QMK software. Then I can flash the firmware with a terminal alias command without touching an online GUI tool.
None of my custom devices are supported with any, that I know of, pre-configured QMK firmwares.
kbfirmware gone soon?
After learning that kbfirmware.com is at end-of-life I’m worried that if the tool goes away tomorrow, I won’t be able to create initial firmware for future devices (designing and converting a Kinesis Gaming keyboard now).
Does anyone know of a similar tool for creating QMK firmware from scratch for people building custom keyboards?
This is something I’ve been wondering about as well. Something more up to date and compatible with current QMK would be nice, though I imagine that would take a bit of work. There is also https://builder.mrkeebs.com/ which seems to be a fork(?) of kbfirmware, as well as instructions on the kbfirmware github page on how to setup a local instance of kbfirmware. I haven’t tried compiling and deploying it yet myself, but thats my back up plan in the event that kbfirmware decides to shutdown.
Hello @huhsh. Here’s a great video series by (mechmerlin#2999 at Discord.com) that helped me. I don’t think he’s on Keebtalk.
This is a 6 part Youtube video series on porting a keyboard to QMK. Watch it all…it’s great. He explains the relationshipt between physical and electrical matrix configuration and answered questions I didn’t even know I had.
More importantly, after watching the series I’m confident I can figure out how to build a QMK firmware for a custom board with or without kbfirmware.com.
Did you know there’s an internal QMK shell script that builds a new firmware (general file creation for getting a new/custom firmware built)? I didn’t. Video 3 at 0:37 mark. The script and instructions from mechmerlin are very helpful.
I didn’t know about the QMK shell scripts, and I’m surprised I didn’t come across mechmerlin’s videos in my research leading up to my hand wired build. I’ll certainly be watching that 6 part series. I’ve been looking for a guide of sorts on building firmware from scratch manually, this looks to be that. Thank you for letting me know about it! I kind of trial and errored my way from kbfirmware to a modern QMK, then ported to VIA and finally Vial. I have built a couple led cubes so I have a basic working knowledge of electrical matrix wizardry. No prior experience with the C programming language (thats what QMK uses, right?) though, so its been a learning experience.
I just finished watching those videos. Theres a lot of really good info in there. I didn’t know about that KLEtoQMK either, that will come in handy next time I build a keyboard. Thanks again!
You’re welcome. Thanks for the notes on VIA and Vial…hadn’t heard of either before. How do you like Vial? What do you mean when you say “modern QMK”? Once I got my boards working I didn’t update my QMK environment. I was afraid to break it.
That’s for sure…much to learn. And KLEtoQMK was new to me as well. mechmerlin responded to me yesterday on Discord and mentioned he plans on releasing more videos in that series so that should help too.
“Modern QMK” in the sense that KBFirmware is based on a version of QMK from 2017, and I had to make changes to the source files (config.h, kb.h and kb.c)from my KBFirmware .zip in order for a fresh setup of QMK to be able to compile a hex from those. Sorry, I’m new to this stuff so some of my terminology might be wrong. There were a handfull of changes I had to make aside from the one that the QMK Hand Wire guide mentions. Luckily QMK has very helpful error messages that tell you which line in which file is causing the problem. Like the change from “KEYMAP” to “LAYOUT” in the kb.h file, adding “#pragma once” at the top of one of the files, etc. Making one change at a time and then attempting to compile and addressing whichever error came up next. The documention was helpful, as well as just looking at other peoples sources in QMK repos and modifying mine accordingly. I only used VIA long enough to make sure my firmware worked before porting to Vial, so I can’t say much about it but it seems to work well. VIA, from what I understand, doesn’t have all the QMK features that Vial does. And Vial, at the expense of a larger firmware size, stores the .json keymap on the board so you don’t have to sideload it each time you want to make changes. This is the thread I learned about Vial on, VIAL Configuration Software . Its nice being able to make changes without re-compiling and flashing each time and I’ve been able to play around with TapDance, which I’m still trying to understand the code aspect of but the Vial gui makes implementing really beginner friendly. And I know what you mean about not wanting to break your QMK environment, I have mine set up on a raspberry pi so its safe from my bumbling about.
Got it. I’ve been trying to convert a kbfirmware.com firware working keyboard to a new install of QMK on another computer and it’s been painful. First to compile because there are mistakes in my files…probably just punctuation mistakes. I’m not a programmer and don’t touch the C language outside QMK (you asked before about the language and I think it’s C) so basic stuff takes me a while to figure out.
The error location is helpful but I find the messaging confusing. Have you come across a page or article that outlines all code differences between previous QMK versions and current? That would help but haven’t found it yet.
So all your keymap/QMK edits take place on the pi and QMK isn’t on your workstation? Very interesting.
Unfortunately I haven’t been able to find a list of the changes to QMK, Mechmerlin mentions a few of the changes in video 3 or 4 of that playlist on Porting. I think we’re in similar positions in regards to programming experience. I spent a bit of time looking at other peoples keyboard sources and just changing necessary parts of my kb.h, kb.c and config.h accordingly. I probably should have kept track of changes, but I still have my original kbfirmware sources so at some point I’ll compare them and try to make a list. I have the Vial GUI app on all my computers now, so I can make changes to my keymap on a whim. But yes, my QMK and Vial build/compile environment is on a Raspberry Pi 4 running Raspberry Pi OS. I use it over SSH and use Filezilla from my workstation to grab the compiled .hex files. Mainly because I keep getting a compiler error on my workstation that I have yet to solve, and is stopping me from compiling stuff on there, but also because I’m just comfortable enough in the linux command line that I find it easier to work with for this sort of thing. I’ve heard of other people using Virtual Machines similar to how I use my Pi, for the sake of using a clean linux environment for building firmware. Luckily QMKToolbox works on my workstation so flashing is still convenient.
Trying to convert an out of date QMK keyboard keymap (on computer A which is working fine) to a new up to date QMK environment (computer B) turned out to a poor approach. So I started fresh on computer B by creating a new keyboard using the QMK shell script by running this command: ./new_keyboard.sh while in the ~/qmk_firmware/util directory. The command is the same as long as the user is in their QMK environment directory.
Then I just took the old settings and configs from (keyboard.h and config.h) and plugged them into the new environment and got the board to flash. Along the way I learned some things that could be helpful.
QMK Environment Update
I came across some posts and this talks about an out of date QMK environment and the frustration the user had. I could relate. In it he talks about confusion over updating the environment in general and also how to do it depending on how the environment was installed initially, via Git or PIP. Inside this page is a link that helps explain how to update the QMK environment whether it was installed using PIP or Git. After reading a book worth of posts on QMK this is the first time I read how to update the environment.
QMK Edit, Compile, Flash via GUI or Terminal?
I’m going to try to get Vial setup to see what it’s like to edit, compile and flash via a GUI out of curiosity. Right now I edit my keymap.c in a text editor and compile and flash in one step using the terminal. This video series, QMK Firmware Tutorial by Chokkan walks through a workflow to edit keymap, compile and flash the keyboard process from the terminal. Once you get past the MSYS2 Windows info you’ll feel right at home being a Linux user.
QMK Strategy
Learning that kbfirmware.com may be gone soon and not knowing how to create a new board without it inspired me to get a better understanding of QMK overall so I could build a board without it. I’m going to see if I can convert a split retail board (remove printed circuit boards, install controller and hand wire) using nothing but the QMK environment. No keyboard layout editor, kbfirmware.com, mrkeebs etc. Great tools but want to know how to get it done with a minimal toolset and dependency list.
Maybe I’ll document the process to answer questions or clear up any confusion I had (or still have) about the QMK environment. This is a tangent but worthwhile page that has a very large keyboard reference list.
Thank you for your input and help @huhsh . Inspecting other keyboards settings like you mentioned has been helpful.
That shell script is handy. Poking around the different directories in qmk_firmware, now that I’m starting to understand how the .c and .h files work together, I see there are a number of layouts/templates/examples. I do still make changes to config.h and rules.mk, as well as compiling, in the command line. I just use QMKToolbox for flashing, which isn’t necessary but is easy. Vial is just for changing keymap settings from what I understand. There are still settings that require re-compiling and re-flashing, but not every little change to my keymap which is nice for experimenting with different ModTaps and TapDance without having to commit. Good luck with the retrofitting your split retail board, and please document and share the process if you can! I essentially did a similar thing to a prebuilt TKL, gutted and QMK’d with handwired, and there isn’t much for recent documentation on the process.
Sounds like a good workflow @huhsh. I wish there was a QMKToolbox for Linux.
Yeah thanks. Waiting for some supplies to come in. Did the same thing with a 25.00 Dragon keyboard and still use it sometimes.
Update QMK Environment (much easier than expected)
This information is in parts of the previous posts but you mentioned your reluctance to mess with your QMK environment to avoid breaking it. Mine was so out of date I decided to do it and it was much easier (luckily nothing went wrong) than I thought it would be.
Navigate to ~/qmk_firmware (or top level QMK install directory).
Run git pull
Run make git-submodule
These two commands updated QMK and it’s sub modules.
Compile & Flash in 1 Step (results in an error)
make split2:default:teensy
Error Message (Python out of date)
QMK Firmware 0.14.20 Your MILC library is too old! Please upgrade: python3 -m pip install -U -r /home/brett/qmk_firmware/requirements.txt
Your MILC library is too old! Please upgrade: python3 -m pip install -U -r /home/brett/qmk_firmware/requirements.txt
ERROR: Cannot run “qmk hello”!
Please run qmk setup to install all the dependencies QMK requires.
make: *** [Makefile:492: split2:default:teensy] Error 1
I think that ‘make git-submodule’ was actually mentioned in the Vial porting documentation. Learning how to use git has been an adventure as well! That compile and flash in one command is really slick too, I’m going to have to try that next time I flash a board.