Author Topic: A couple of QMK questions  (Read 3126 times)

0 Members and 1 Guest are viewing this topic.

Offline mayrose

  • Thread Starter
  • Posts: 2
A couple of QMK questions
« on: Thu, 05 March 2020, 15:09:48 »
I am super new to this, so thanks for taking a look at a newbie's series of questions!

I am interested in using QMK, but was a little confused on how the firmware actually works with each chip. I'm no programmer, so I'm having some trouble wrapping my head around it.

As long as the chip is listed as being compatible with QMK on Github, especially if it's listed in the Toolbox, I should be able to flash my layout without any trouble, correct?

Also, QMK firmware isn't naturally included on a chip, but is just something that has been built that can communicate with different AVR and ARM chips during the flashing process, correct? I guess I'm confused when I see 'powered by QMK' a la Massdrops' Ctrl board, for example. Does this mean it's integrated into the chip?

For older chips, like the atmega32u4, is the firmware loaded onto the chip during the initial connection with your PC and then remains on the microcontroller for future flashing communication?


Offline Shikada

  • Posts: 43
  • Location: Serbia
Re: A couple of QMK questions
« Reply #1 on: Sun, 08 March 2020, 06:20:28 »
So, all firmware is something included in the actual hardware. It's either in read only memory, or rewritable flash memory. The later is the case here, since you're meant to change it.

Your keyboard should always come with some firmware for it to actually work, if it doesn't you'll have to write a firmware for it to function.

The internal chips are build in a way to rely on this firmware to perform the various tasks they need to do, so changing the firmware allows you to reinterpret their actions. That's how you are able to change the layout of your keyboard. Your common keyboard outputs the same scancode (the ID of a key being pressed), but by controlling the firmware you can instruct your keyboard to output a different scancode of your choice for each physical key on the keyboard. The microcontroller, in tandem with the current firmware in flash memory, makes the choice which scancode to output.

Hope this was clear for you :)

Offline tex_live_utility

  • Posts: 990
  • MX brown apologist
    • twitch.tv/salt_rock_lamp
Re: A couple of QMK questions
« Reply #2 on: Sun, 08 March 2020, 11:17:13 »
Quote
As long as the chip is listed as being compatible with QMK on Github, especially if it's listed in the Toolbox, I should be able to flash my layout without any trouble, correct?

Yes. Every chip (more commonly called a microcontroller or MCU) is unique in its own way, so the chip must be specifically supported by QMK.

Quote
Also, QMK firmware isn't naturally included on a chip, but is just something that has been built that can communicate with different AVR and ARM chips during the flashing process, correct? I guess I'm confused when I see 'powered by QMK' a la Massdrops' Ctrl board, for example. Does this mean it's integrated into the chip?

For older chips, like the atmega32u4, is the firmware loaded onto the chip during the initial connection with your PC and then remains on the microcontroller for future flashing communication?

"Flashing" is just jargon for "loading a program" onto a microcontroller.

Typically a microcontroller only keeps one program in its memory at a time. Controllers like the ATMega (technically "megaAVR") series have two sections of writeable memory: 1) the bootloader, and 2) the user-loaded program. The ATMega can be run in either "bootloader mode", when the bootloader runs on startup, and its regular mode, when the user-loaded program runs on startup.

The bootloader should come pre-installed from the factory. This program communicates with your computer and is able to "self-program", by writing data of your choice to the user-loaded program section of memory.

Once the program has been written to the user area of memory, the bootloader can "reset" the controller back to its regular user-program mode, and execute the program as normal.

So the flashing process works like this:

  • Start the controller in bootloader mode
  • Use the bootloader to write a new program to the user area of memory
  • Either turn the controller off and start again in regular mode, or use the bootloader to switch modes

As long as you don't mess up the bootloader, you should always be able to repeat this process, no matter how screwed up the user program gets.

Typically when a custom keyboard says it runs QMK, this means that you can flash QMK onto it, using the above process. Most keyboards nowadays come pre-flashed, meaning you (the end user) doesn't have to flash anything in order to use QMK right out of the box.

As for keyboards sold by Drop, it's not obvious what they will do. It might come with some kind of proprietary firmware pre-flashed, or it might come with QMK pre-flashed. But as long as they provide instructions for flashing, and as long as the keyboard is already available in the QMK repo (you can check on e.g. https://config.qmk.fm), you should be able to flash QMK on it after you receive it.
Discord: salt rock lamp#0679 | Reddit: /u/nerdponx | Deskthority: autoload -Uz | Keebtalk: salt_rock_lamp
Twitch: salt_rock_lamp | YouTube: https://www.youtube.com/channel/UCd7YXZjilUutJ6ShZWrvQtg | Instagram: @salt_rock_keyboards


Offline mayrose

  • Thread Starter
  • Posts: 2
Re: A couple of QMK questions
« Reply #3 on: Tue, 10 March 2020, 10:31:28 »
Thank you both so much! :) Definitely cleared things up for me.

Offline typo

  • Posts: 1676
Re: A couple of QMK questions
« Reply #4 on: Sat, 14 March 2020, 07:25:49 »
I have a brand new controller and cannot even get it to upload. It keeps saying compiler failure? Any help please? The thing is it says choose board and my board is not on there. It is Korean. I suppose I need to figure out which board has this controller?