Author Topic: Micro Mechanical Keyboard (uMK) firmware  (Read 1188 times)

0 Members and 1 Guest are viewing this topic.

Offline marcv81

  • Thread Starter
  • Posts: 2
Micro Mechanical Keyboard (uMK) firmware
« on: Wed, 10 October 2018, 06:53:48 »
Hi all,

I made a custom firmware for ATmega32U4-based keyboards. https://github.com/marcv81/umk.

The features set is minimal: anything you can do with a regular keyboard + remapping keys + layers. On the bright side it takes less than 3kb and the matrix poll rate is close to 2kHz.

Although it is my daily driver casual users would be better off with a mainstream firmware and a strong community.

I'm sharing in case some of the tinkerers here find it worth having a look at. The code should be simple enough for any developer to understand and experiment with, which I believe is the main strength of the project.

By the way, I'm not looking for contributors: the firmware has all the features I want already. I'm unlikely to accept PRs other than bug fixes. This said feel free to fork or reach out with questions and comments!

Cheers,
Marc.

Offline OldIsNew

  • Posts: 118
Re: Micro Mechanical Keyboard (uMK) firmware
« Reply #1 on: Wed, 10 October 2018, 12:07:38 »
Cool! I'll definitely give the code a look over. I've been dabbling in Arduino C code for my boards,  but am always interested  in seeing how someone  who knows C well approaches things.

Offline kriminal

  • Posts: 424
Re: Micro Mechanical Keyboard (uMK) firmware
« Reply #2 on: Wed, 10 October 2018, 21:54:29 »
I'll check it out also, will learn a thing or two

Sent from my Moto G (4) using Tapatalk

Geekhacked Filco FKBN87M/EB modified with Brown, black and blue cherries, doubleshot keycaps
Deck KBA-BL82 with Black cherries
Cherry G84-4100LCMDK-0 Cherry ML switches
Cherry G80-8200hpdus-2 Brown cherries
IBM Lexmark 51G8572 Model M Keyboard
Geekhacked Siig Minitouch KB1948
IBM Model M Mini 1397681

Offline marcv81

  • Thread Starter
  • Posts: 2
Re: Micro Mechanical Keyboard (uMK) firmware
« Reply #3 on: Fri, 12 October 2018, 06:23:30 »
Thanks for the interest!

Quote
someone  who knows C well

I might not know C as well as you think. I made some potentially controversial design decisions. For instance each translation unit statically allocates the resources it needs. So for instance there can only ever be one report_builder. It goes against the usual good practices, but given the resources constraints it is a reasonable compromise which avoids heap allocation and reduces complexity. This said I still chose to decouple the translation units, which is generally a good idea but results in a slight performance impact.

Any specific question feel free to ask!

Online algernon

  • Posts: 287
  • A tiny mouse, a hacker.
    • Diaries of a Madman
Re: Micro Mechanical Keyboard (uMK) firmware
« Reply #4 on: Fri, 12 October 2018, 07:07:21 »
For instance each translation unit statically allocates the resources it needs.

That's pretty much what every other keyboard firmware does. The usual best practices for embedded development are sometimes very different than the traditional best practices.