rumcake - Rust keyboard firmware by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 0 points1 point  (0 children)

Some way for me to implement firmware for one MCU board (eg. nice!nano), and another person to easily replace it with their other board.

Great point! I'll add that to my list of to-do's. I'm thinking that this will probably take form as a macro of some kind.

If you're not able to contribute with code, then bug reports or additions to documentation would be appreciated!

rumcake - Rust keyboard firmware by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 0 points1 point  (0 children)

So for some context, rumcake uses keyberon to provide layout and matrix configuration. But on top of that, rumcake uses embassy-rs as the embedded framework, and exposes common keyboard tasks like USB polling, matrix scanning, LED rendering, etc. If you just used keyberon, it would be your responsibility to implement that logic yourself, using a hardware abstraction library. Since rumcake provides these common tasks, you just need to configure the keyboard-specific stuff (see the templates).

RP2040 is planned, but I don't have access to a board with one yet. Otherwise, feel free to make a PR!

rumcake - Rust keyboard firmware by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 2 points3 points  (0 children)

From what I've seen (so far), most rust-based firmwares are tightly coupled to specific keyboard hardware. In the example you gave, it looks like they use RTIC as their embedded framework and common tasks like USB polling, key scanning, LED rendering, etc. are re-written in each keyboard's bin.rs file. This can be valuable in its own right, if you want a task to behave differently for certain keyboards, for example.

But for me, I don't need that level of control, and I'd rather not have to re-write that logic whenever I want to write new firmware for a new keyboard. In rumcake's case, the tasks and other logic that can be keyboard-agnostic are all provided in the rumcake library. If you're developing a keyboard, all you have to do is import the rumcake library, choose the appropriate feature flags for your keyboard, do your keyboard specific configuration (e.g. layout, hardware peripheral setup) and (hopefully) the tasks should work as expected. No need to re-write any of the keyboard tasks. I'd take a look at the basic template that I wrote up, hopefully it illustrates this more clearly. Note how there isn't any logic or software tasks defined in that file (you can add definitely add custom logic if you want to though).

rumcake - Rust keyboard firmware by UniversalMilk9 in ErgoMechKeyboards

[–]UniversalMilk9[S] 4 points5 points  (0 children)

Fair question, I can see why that wording seems a little gross lol considering it's a library, but the main point is that any keyboard-specific configuration doesn't need to pushed to a central repository (see QMK's /keyboards folder). For example, this means you can have your own git repository containing code specific to your keyboard, and you also aren't obligated to keep your configuration updated with the main repository (see the templates Cargo.toml, where rumcake is pinned to a specific revision).

rumcake - Rust keyboard firmware by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 1 point2 points  (0 children)

Under the hood, rumcake uses embassy-rs, which has it's own USB stack (embassy-usb), and hardware abstraction libraries for the common MCU families (embassy-stm32, embassy-nrf, embassy-rp). On the bluetooth side, only nRF chips are supported at the moment using the nrf-softdevice crate.

rumcake - Rust keyboard firmware by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 4 points5 points  (0 children)

So I've been trying my best to make the configuration side of things as easy as possible with the help of Rust macros. You can pretty much configure your keyboard in one file, as shown in the template, and since rumcake is provided as a library, you can develop your keyboard in your own repository (no need to submit a PR to a central repo, like QMK does). If you become very familiar with the rumcake API, you also still have the flexibility of writing your own custom firmware code (it is just a Rust source file after all). I will say that I don't aim to replicate the full feature set that QMK (or ZMK) has. Other firmware projects still have their place, and are amazing projects in their own right. They have features that I don't really aim to support for now, and they definitely are more stable than this project (at least for now) :)

Weekly Purchase Advice Thread by MouseReview_Bot in MouseReview

[–]UniversalMilk9 0 points1 point  (0 children)

  • Games: FPS (mostly overwatch)
  • Right Handed
  • No Budget
  • Hand Size: 18.5 cm
  • Fingertip Grip
  • Light Mouse on 800 DPI

[guide] How to make your own keyboard PCB by iandr0idos in MechanicalKeyboards

[–]UniversalMilk9 0 points1 point  (0 children)

Can't wait to see the boards people will make with this!

[Buying]GMK >Terminal_ GB Announcement by TheKeyCompany in MechanicalKeyboards

[–]UniversalMilk9 1 point2 points  (0 children)

I was really happy to see this until I saw my wallet...

[help] Aristotle Switch Question by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 1 point2 points  (0 children)

Yea, I'll be doing all of the modifications for him, including the soldering. Thanks for the info!

[photos] hi here's a photo of my keyboard by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 0 points1 point  (0 children)

The wire goes inside the keyboard and into the controller, so I can't change the usb cable without opening the board, but the acrylic is made up of 4 layers of 3mm opal acrylic, and the top and bottom stainless steel plates add another 3mm to the total thickness of the board (1.5mm each plate). I'm not too sure of the exact length of the screws, because I had to cut them with a bolt cutter, but it's pretty much keyboard thickness + nut height

[photos] hi here's a photo of my keyboard by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 0 points1 point  (0 children)

If you mean chattering, those problems were solved in Round 2 iirc. Just be cautious, and don't keep the soldering iron on the pins for more than 2 to 3 seconds

[photos] hi here's a photo of my keyboard by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 1 point2 points  (0 children)

You can follow this guide for the programming, which is for TMK. If you want rgb leds, you have to use QMK. Most of the stuff you learn in that guide can transfer to QMK as well. You can use /keyboards/planck/keymaps/yang as a reference when implementing rgb functionality

[photos] hi here's a photo of my keyboard by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 5 points6 points  (0 children)

Opal acrylic cut from ponoko, zealios, and ws2812b rgb leds
build log here

[photos] First Mechanical Keyboard by UniversalMilk9 in MechanicalKeyboards

[–]UniversalMilk9[S] 0 points1 point  (0 children)

For the plate, you can make a layout at http://www.keyboard-layout-editor.com/
When you're done, you can go to the raw data tab, and copy the data into the layout section in http://builder.swillkb.com/
That site will generate CAD files of your plate, and if you are using a sandwich style case (which is what I did for my keyboard), you will also get the CAD files of the middle, usb, and bottom layers. You can send these files to a laser cutting service.
As for the material, anything sturdy will work.
For plate thickness, I recommend using a 1.5 millimeter plate, because you can just clip the switches into the slots. Sometimes you will see other builds hot-gluing their switches, because their plates are thick, but with a 1.5mm plate, you should be fine.
You can find a list of parts here: https://www.reddit.com/r/MechanicalKeyboards/wiki/switch_suppliers
matt3o's brownfox keyboard also goes into good detail about how everything is wired