This is awesome! I've been developing firmware in Rust for a Hall Effect keyboard (with springless, magnetic separation switches!) I'm developing/inventing (just ordered the first PCBs!). I really wish we had something similar in the embedded Rust ecosystem as a lot of the crates mentioned don't support #![no_std] (declaration you make at the top of your Rust code to indicate that the compiler should not include the standard library).
The world of embedded Rust seems to be developing incredibly fast. Especially since there's so much hardware that you can use with it now and more is on the way (especially in the world of RISC-V... Holy crap there's a lot of interesting and exciting hardware coming!). As a result of that I seem to be regularly encountering situations where I try to do something basic but no one has "made a crate for that yet" (that works with #![no_std]).
Just the other day I found out just how difficult it is to benchmark something (i.e. grab the current time, do something, get the time again, then subtract the difference... It's really, really complicated! Way moreso than it should be). If someone wanted to make a name for themselves by developing widely-used software now is the time to make your mark! The world of embedded Rust is waiting for you!
FYI: I'm still a newbie when it comes to Rust but I was able to develop a universal driver (works with any hardware platform) for working with 74HC4067 and 74HC4051 analog multiplexers in just a few days... https://crates.io/crates/analog-multiplexer
There is a section called no-std crates which lists a couple of useful crates like bbqueue and heapless. I find it insightful to browse through the public repos of the authors of popular embedded rust crates and see what crates they use most often.
Yeah, magnetic levitation is the exact opposite of magnetic separation. Magnetic levitation switches are basically just linear switches that get harder to press the farther down they get.
Magnetic separation switches are the opposite: The force is strongest at the start but then gets weaker the farther down the key travel you go. Here's a force curve that I've measured for my 3D printable magnetic separation switch:
Yeah it's just the end of the road, as it were. At the end the keycap, stem, and switch body start to compress so there's some give before the super fun explosion.
In my little bit of searching, most people seem to be saying they like it (many a lot), and most of the dissenting opinions seem to be more about the very low key travel (0.7mm), which is merely something that the maglev keyboard made possible and more bearable, rather than something fundamental about magnetic switches or movements (whichever it is).
(I’ve never seen one of these keyboards or even heard of them before, and am thus speaking from an uninformed position.)
Sure, it's a 3D printable key switch design (yes, it's smooth--not scratchy). I've already made one hand-wired prototype and I posted about it on Reddit here:
I've also designed two keyboard stablizers: One that's "regular" (Cherry compatible) and one that's meant to work with my hall effect switch design that incorporates magnets to ensure it never rattles. I haven't released them yet though (Soon™).
My key switch design was created in OpenSCAD and is parametric. So if you want you can customize every little detail of the switch from the size of the magnets to the travel to the initial force required to depress a key (by controlling how close the magnets get at rest).
Once I have a working keyboard firmware I'll release the whole thing open source so everyone can play around with it.
Oh! I also made a keycap design library for OpenSCAD to go along with all of this called the "Keycap Playground"...
That video is so frustrating: I’m just trying to look at the thing, but your LEDs keep on cycling through annoying and distracting patterns that quite ruin the picture by throwing the camera’s light metering off and adding lens flare. I got about halfway through before it was altogether too much for me.
I would have really enjoyed watching the same video with the LEDs turned off.
Anyway, I’m going to look more closely into this now, because other that that it looks like a really interesting project! :-)
The world of embedded Rust seems to be developing incredibly fast. Especially since there's so much hardware that you can use with it now and more is on the way (especially in the world of RISC-V... Holy crap there's a lot of interesting and exciting hardware coming!). As a result of that I seem to be regularly encountering situations where I try to do something basic but no one has "made a crate for that yet" (that works with #![no_std]).
Just the other day I found out just how difficult it is to benchmark something (i.e. grab the current time, do something, get the time again, then subtract the difference... It's really, really complicated! Way moreso than it should be). If someone wanted to make a name for themselves by developing widely-used software now is the time to make your mark! The world of embedded Rust is waiting for you!
FYI: I'm still a newbie when it comes to Rust but I was able to develop a universal driver (works with any hardware platform) for working with 74HC4067 and 74HC4051 analog multiplexers in just a few days... https://crates.io/crates/analog-multiplexer