Micro Mechanical Keyboard (uMK) firmware

[marcv81]

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.

[OldIsNew]

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.

[kriminal]

I'll check it out also, will learn a thing or two

Sent from my Moto G (4) using Tapatalk

[marcv81]

Thanks for the interest!

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!

[algernon]

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.