key-ripper VS ghidra

Nice - a friend and I worked on my keyboard's debouncer and call it "eager debouncing", not sure if there's an official term for it. I agree that it's much better for latency.

Awhile ago I made an remote infrared sending tool so a raspberry pi can control my A/C unit

https://blog.bschwind.com/2016/05/29/sending-infrared-comman...

Since then I made a much slimmer, cheaper, more efficient version based on the ESP32 but I haven't written up much about that.

I also created my own keyboard with firmware in Rust

https://github.com/bschwind/key-ripper

I've done a bunch of other small one-off projects too.

Good luck! I have an open source keyboard project in KiCad as well, feel free to reference or use anything from it.

Not sure if the author of the post is around, but I guess this is a question for anyone who has designed keyboards: have you ever tried using shift registers for reading all the keyswitch inputs, and is it worth it? Does it mean you don't have to use a diode per switch?

I've designed my own as well but just went with the traditional key matrix with a diode per switch. Works well enough for the current size.

https://github.com/bschwind/key-ripper

All the source files can be found here

I made my own keyboard layout just the way I want so I would put these caps on that, or replace the stock caps that came with my Filco board.

Twist looks awesome, I'd put it on my key-ripper

You can absolutely run Rust on the pico - I designed a keyboard with Rust firmware which runs on an RP2040. That being said, wireless functionality might not be existent yet in the Rust world for the Pico W, but I'm sure it won't take long to get added.

I looked at the schematic and it seems reasonable. I just completed an RP2040 project with USB C and it works correctly. You can see the project files here

Let's see what our beloved software reverse engineering framework Ghidra has to show.

Define war machinery. Contributing to Ghidra?

https://github.com/NationalSecurityAgency/ghidra

Binary Ninja likewise is empty and keeps up just fine as well. It's not a coincidence that the two commercial products that are funding it are both confident enough to put their stuff online like this.

And it's no conspiracy theory or intentional sandbagging, you can see the implementation: https://github.com/decompiler-explorer/decompiler-explorer

and if anyone can improve the other tools performance we'd be happy to accept it. We reached out to the Ghidra devs: https://github.com/NationalSecurityAgency/ghidra/issues/5228 but they didn't have any silver bullets for us either.

Nice, I'll give it a closer look. My only concern so far is memory hooking (still needed for hardware registers), which on Java side was called by FilteredMemoryState [1]. In memstate.cc it looks like just the simpler MemoryState is implemented [2], and there's no equivalent to MemoryAccessFilter. But it might not be that complicated to add...

[1]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...

[2]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...