geekhack
geekhack Projects => Making Stuff Together! => Topic started by: yui on Wed, 09 December 2020, 07:53:03
-
Hi,
I have been trying with very little success to adapt an Opensource QMK macro-pad to VIA, i am using the YamPad but to be honest i'd like for this to be a bit more generic and maybe be able to serve as a resource later on.
So far i have tried to follow the instruction on via's website but i end up with a firmware that compiles but never sends anything to the computer (not even detected as a usb device...), i am guessing that the main problem here is my lack of understanding of QMK and VIA so this is why i ask for help.
I have included my work so far. i may have made very little modifications to the layouts and makefile and got very inspired from doddle60's via json file
thanks
-
I've setup a couple boards to be via compatible (even a split handwire board I was helping a fellow forum member with). Your num pad shouldn't be a problem.
I'll look at it a little later & show you how to do it.
Via is just a front end for qmk
- Qmk has to be on the device with the couple extra settings to enable via to write to the eeprom. (Via does not actually overwrite the firmware that's flashed to the device, just adds alternate kaymap, etc in eeprom)
- you also have to create a json layout for via
- mech merlin has done a number of "porting with port" videos, that he goes through the steps needed. Check him out if you're not familiar with him. Great guy.
-
ok. here try this. hex, json & full keyboard folder for qmk (attached)
added a via keymap folder, so the via info is constrained to that folder and you can still build the default.
i built the json & flashed the hex to a spare promicro and everything populated correctly.
flash the new hex as usual
for via:
- go to settings tab
- slide the button to "show design tab"
- go to design tab
- load the definition json
- plug your yampad in with the firmware flashed & have fun.
- now, i did not check the product or vendor ids against any others, so there may be conflict if you have another device with the same (i believe generic) product & vendor ids. (we can look into that further if there's issues)
more info:
- KLE base to create json file for via. (doesn't work straight from KLE, there are a couple other variables you have to specify)
http://www.keyboard-layout-editor.com/#/gists/63e2e8b95904520d6088130dc76b6c84 (use as you like)
- VIA does not actually overwrite the firmware that was flashed, it just writes an alternate keymap to the eeprom
- mechmerlin's video i was referencing in previous post. via stuff starts 57:30 in (has a bunch of others too)
some via screenshots (working)
[attach=1]
[attach=2]
[attach=3]
[attachurl=4]
[attachurl=5]
[attachurl=6]
check out the files in the zip to see what was added. again, all in the via folder, and watch merlin's video for great explanations.
- here's another one: via stuff starts at 54:00
-
was skipping the via folder the whole reason my version failed?
from what you write i had done pretty much everything else, just thought that as did not want to build the non via firmware i could just change the main files...
i may have been wrong.
and sorry for not answering earlier i did not had time too look up mech merlin or work on it at all, maybe not even going to be able today.
and from what i have read yes the yampad uses generic ids but i only have one other via device that is not using generic ids and the others i plan to gift them to do not even have any mechs and even less via enabled mechs :)
Thanks for the help though
-
no, the via folder is not necessary, what IS necessary is the special tags in the rules.mk and the keymap to fulfill a couple preferences.
- keymap should have at least 4 layers
- needed in rules.mk
VIA_ENABLE = yes
LTO_ENABLE = yesthis can be done in the keymap folder, separate from the keyboards main rules.mk file.
also the .json file was not correct. and this is probably the trickiest part of via support.
- the json tells via how the matrix is wired (the numbers in top left of the KLE are row,column) as well as what size position the keys are at (the visual layout)
[attach=1]
you will need to load the json definition every time you open via because this board is not in the main repository yet.
feel free to ask any other questions on how it's done
definitely take some time to watch merlin's explanations too
also, the via firmware will function as normal even without using via.
via is just a way to change the keymap or change other settings without reflashing.
-
i need to try an other controller... i flashed mine using your firmware and json and still nothing, no output and not recognized in via... so i was right in doubting my skills in via but i maybe should also have doubted the controller... still thanks, hope not all 10 are non working...
-
Just flashing the promicro, even before it's soldered to the pcb should show up when connected.
to flash
-Open qmk toolbox
-select firmware to flash
-short rst to ground (tweesers or similar)
-soon as you see the port # open up on the qmk toolbox screen hit flash
-when flashing/programming is complete unplug & re plug in the promicro. Should show up as a device.
[attach=1]
Also, you don't have the 3.3v 8mhz version of the pro micro do you?
There are two variants
- 5v 16mhz
- 3.3v 8mhz
You want the 5v 16mhz one.
-
well the thing is it is not written which version it is, but the crystal is 16MHz so i guess 5V and yeah i am flashing with QMK but after the 2nd flash the controller do not want to stay in bootloader mode... it stays for maybe 3 to 5 seconds and so when windows react it is already too late, and as far as i know qmk toolbox does not work yet on linux.
-
yes, you only get 8 seconds to catch the bootloader with promicros or clones. so, i always have my file prepped/opened so all i have to do it hit "flash" as soon as the port opens up.
to flash
- plug in the promicro
-Open qmk toolbox
-select firmware to flash
-short rst to ground twice (tweesers or similar)
-soon as you see the port # open up on the qmk toolbox screen hit flash
-when flashing/programming is complete unplug & re plug in the promicro. Should show up as a device.
(you should be able to get it flashed following this order, basically, just be ready to hit flash as soon as the port opens up)
there's also the auto-flash checkbox that will automatically try to flash as soon as the port opens up. i haven't used it yet but some have reported better success using that.
also look at sparkfun's page about flashing & trouble shooting:
https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/troubleshooting-and-faq
there are other available flashing tools for promicros (caterina botloader), check the list and info on QMK docs
https://beta.docs.qmk.fm/using-qmk/guides/flashing/flashing#caterina
QMK toolbox just rolls a bunch of flashers for a bunch of different bootloaders into one interface.
side note: most dfu devices stay in bootloader mode until they are power cycled (unplugged/replugged)
so, as long as you already have the device in bootloader mode, you can roll the flash command in with the build command when you call the "make" action when compiling the firmware.
it all depends on which controller it is and what bootloader they use as to which flashing method you have to use.