Clavier: An FPGA-based mechanical keyboard with USB hub and comms interfaces | Hacker News Reader

Clavier: An FPGA-based mechanical keyboard with USB hub and comms interfaces

github.com

106 pointszdw38 comments

As somebody who regularly tinkers, debugs, and programs microcontrollers at my desk. I just realized how handy having UART/SPI/I2C headers right there would be. Obviously I already have them like right there but to have them right there there would be great.

After a few dumb accidents involving header pins, I've come to the conclusion that exposed male header pins on my desk are a hazard.

I've learned to be wary, too. Most desktop motherboard these days have several fan headers just above the memory slots. They also frequently use DIMM slots that only have one latching lever, usually at the top of the slot near the fan headers. So when you're trying to remove a memory module, if you use slightly too much force and your finger keeps moving after the latch opens up all the way, you get a deep puncture wound.

The headers on the keyboard look like they'd be easier to hit accidentally, but probably not with enough force to cause a serious injury. I'd still prefer having some covers over them.

I would perhaps put pin receptacles / sockets there instead.

Shrouded headers are also available.

How about the risk of frying the MCU?

You can always put some extra protection on the external interfaces. Won't make it impossible to fry if you really do something stupid but would reduce the risk significantly.

Risk? Ain't no risk to it, it's an established fact! What's a good electronics hobby without an assortment of dead MCUs, melted wires, and exploded probe tips?

The FPGA is a Lattice LFE5U-25F, about $20

https://www.digikey.com/en/products/detail/lattice-semicondu...

Or about $5 on LCSC.

Thank you for surfacing that info, was wondering if I seriously had to go start opening files to find out.

Btw, that's a 256 pin BGA part, grandad's Weller cannot help.

Curious why they didn't use the LFE5U-12F, I can't imagine this project maxing out even the smallest modern FPGA.

Even better. The LFE5U-12F is just a 25F in terms of resources you can full utilize it with nextpnr. I expect lattice didn't find it economical to have a truly separate production process for it.

Is the benefit of the FPGA here that you can program the whole stack? Like a kind of super-charged QMK based board?

Because you can? It looks like a great project for getting started with nontrivial FPGA design.

Programming-wise I'd say full FPGA is less useful than QMK. Doing a direct 1:1 mapping from key inputs to USB HID report isn't too bad to do in an FPGA, but dynamic behavior like macros, layers, leader keys, mod tap, auto shift, and so on are significantly easier to implement in a regular programming language. If you want flexibility you're basically forced to have your FPGA run a soft core, so at that point why not go for a regular MCU?

In theory you could make an argument for lower latency, but that doesn't really apply when you're limited by USB 2's 1000Hz polling rate while some off-the-shelf MCU-based keyboards use USB 3 for 8000Hz polling.

Yea. Fun, but not optimal for a product. 1000Hz is already comically faster than any human muscle reaction.

With regards to latency: reaction time is the wrong thing to compare against, since input latency can be noticeable even when it is much smaller than a human's reaction time. And wanting to have your keyboard latency be no worse than 1ms can make sense given that it's only one of many components of the total input latency of a computer. Reducing mouse or keyboard latency from 8ms (125Hz) to 1ms (1000Hz) is pretty much the low-hanging fruit; it's not as cheap or easy to squeeze 7ms out of the other parts of the chain.

Well the project description seems to hint at to their motivation:

> 1000 Hz polling rate

> No multiplexing, no ghosting

> FPGA-based, VHDL only, no ALU

It looks like a pure HW 'described' keyboard with no running software meaning it is fully parallel (plus some serialization when reaching the USB device/interface).

So arguably on top of true parallelism the only ceiling for the latency of the whole thing will be the clock period configured in the design and the physics and electrical behaviour of the switches themselves + circuitry.

Probably someone who enjoys working close to hardware and wants to optimize performance.

Most MCU-based keyboards have a 1000Hz polling rate - and some mainstream gamer-focused keyboards are even going for 8000Hz these days.

Getting rid of multiplexing is a result of having a high number of IO pins: an MCU like the STM32F429BE also has enough pin for direct-attach switches. Ghosting hasn't been an issue for ages, even with a traditional keyboard matrix it's just a matter of adding per-key diodes.

In theory it has a sliiightly lower latency than an MCU-based keyboard using the same USB interface, but I doubt the difference is big enough to even be measurable in real-world scenarios. We're talking about, at most, a few thousand cycles of an MCU running at a few hundred megahertz - and that's only relevant when you press the key right before a polling request arrives. That's the difference between an average input latency of 0.500 ms and 0.505 ms. Meanwhile on the output side, your fancy 480Hz monitor is only showing one frame every 2.1 milliseconds...

The optimization here is somewhat theoretically specially when you take into account the USB bottleneck as well as real-world Human reaction times and Perception.

But it appears from the project description that the author's motivation was indeed performance (irrespective of merit). A neat VHDL + HW project nevertheless.

In that light, it's odd that they specify a polling rate at all, since they use direct-attached key pins linked to an 48MHz clock. There is no grid/matrix sensing period, which is usually what is meant by polling rate. And the claimed value of 1kHz is doubly weird since the debouncing logic uses a period of 5ms, which means they can at most mimic a 200Hz polling rate:

  entity Debouncer is
    generic (
      FILTER_DURATION: delay_length := 5 ms
    );

edit: looked up what the typical bounce time is for a keyboard switch, and 5ms seems to be pretty standard. It's also the default that QMK uses. It seems quite excessive to me, I'd have expected bouncing times to be closer to tens of microseconds than multiple milliseconds.

I think the main motivation was the ability to assign each key to a separate pin (fpgas can have lots) so no multiplexing is needed.

If you think about it, it's not really mechanical if it has an FPGA. It should be made of gears or something.

If you're not familiar with how teletype machines worked you might enjoy it. There were early units that were purely electromechanical. It's really cool.

Usagi Electric did a nice video if that's your kind of thing: https://youtube.com/watch?v=sSiVYgot9SI

I think the video does a nice job of showing the mechanical components that encode the keypresses and generate the 45.5 baud serial output. The printing side isn't given quite as much coverage but you do get to see close-up views of it in operation.

I wonder if something mechanical could ever talk even USB 1.1 at 12 Mbps. Perhaps if it was small enough...?

I'm curious as to why it doesn't have USB 3.0 ports. Do they take too much power? Too much space?

USB 3 is significantly more complicated to implement, and the hub chips are quite a bit more expensive. Hardware-wise it would've become by far the hardest part of this board.

USB 2, on the other hand, is fairly trivial. You almost have to try to get it wrong - especially when you are not concerned about certification.

Going by the task at hand, registering keystrokes pressed by a human, USB 3 is also not quite needed.

PS/2 is far more trivial and low-latency than USB.

I'll remember that next time I'm developing an FPGA keyboard for my Gateway computer.

Many of the latest gaming mobos still have PS/2 exactly because of the low latency.

Designed in OPENSCAD!

So you can do openscad (its weird language) or you can do python and use the STL lib.

Which do you like better?

After making one medium complexity design in openscad over the course of weeks I am pretty confident in saying there is no use case for openscad that isn't better served by freecad.

Basically, only variable adapable designs are suited for OpenSCAD - because those can be trivially regenerated in web applications.

I came to the conclusion that if I need to do that -- webapp-regenerated, parametric variable stuff -- I would either hook up headless FreeCAD in containers (which is now potentially a bit easier, because the work Ondsel did is open source), or set up replicad, e.g. https://replicad.xyz/docs/examples/gridfinity

OpenSCAD is simply not worth the pain unless you're using it to demonstrate abstract geometry.

Build123D or CadQuery could well be viable, though IMO both have slightly frustrating dependencies. But since they can both load STEP files then customisations can be applied to designs built mostly elsewhere.

This seems like a great place for a Cypress (Infineon) PSOC. A while back, I interfaced one to a linear CCD and it was a great experience. They also have USB HID support on chip.

I used a PSOC (4) for a project once, and while the chip itself was awesome the software was so bad that attempting to use the next version of the software "bricked" the devboard I was using. (Something to do with the new serial bootloader being a different size. "Bricked" in quotes, because with the right kind of expensive programming cable it could have been resurrected - but the whole point of the devboard in question was that it was cheap and self-contained, not needing an external programmer.)

Very cool project.

Reply on news.ycombinator.com