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.
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.
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?
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.
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.
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...
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.
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.
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.
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.
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.
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.)
Readit News
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.
https://www.digikey.com/en/products/detail/lattice-semicondu...
Btw, that's a 256 pin BGA part, grandad's Weller cannot help.
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.
> 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.
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...
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.
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.
So you can do openscad (its weird language) or you can do python and use the STL lib.
Which do you like better?