rp-hal VS qmk_firmware

probably, I didn't really check it, but I found [1]. Rust has a lot of support for embedded systems, even from the companies that provide the chips, like STM and Espressif.

[1] https://github.com/rp-rs/rp-hal

About the same time, I was learning Rust and discovered how it could be used on embedded targets from Low Level Learning on YouTube, the video introduced me to the amazing rp-hal crate that provides abstractions to talk to the Raspberry Pi Pico microcontroller. Getting used to the no_std mode took some time, the most challenging was not being able to collect an iterator to a container.

Well, just as I posted this, I came across the issue on Github: https://github.com/rp-rs/rp-hal/issues/525

Have a read of https://github.com/rp-rs/rp-hal/issues/257 for more info.

I've made an example for a RPI Pico (PR for the RP2040 HAL project here) .

Here's an example: https://github.com/rp-rs/rp-hal/blob/main/boards/rp-pico/examples/pico_usb_twitchy_mouse.rs

Embedded rust for the raspberry pi pico: https://github.com/rp-rs/rp-hal

What are you on about, can you clarify? Rust can compile in no-std/embedded style just as fine (or better) than C can for basically any ARM or RISCV based processor, and quick googling shows this hal for nearly all pi needs and even MEGA65 is "as supported" (read: not at all officially by anything, fan-only) as any current C compiler. Setting up rust for a new target, so long as the code-gen is supported somehow by LLVM, LLVM plugin, LLVM IR transpiler (and maybe libgcc-jit sort of soon) is just as painful or unpainful as setting up a whole team to work via C/C++ with comparable testing harnesses. This doesn't mean easy and is an area Rust is still improving rapidly by the various enterprise agencies (Ferrous systems, Oxide, more I can't remember...) who specifically want to bring rust to such low end hardware because frankly both C and C++ suck with vendor proprietary tool chains and quirks.

He says he can't find crate for 'bare_metal'. He was setting up and testing the HAL for the pico (https://github.com/rp-rs/rp-hal). While compiling it pulls down critical-section-0.2.7/src/lib.rs and bars on line 7

I agree that reduced finger movement is a crucial step in achieving typing efficiency. This is nicely solved by mod tap modifiers in QMK/ZMK[1] where key acts as a char when tapped and as a layer while pressed.

[1]: https://github.com/qmk/qmk_firmware/blob/master/docs/mod_tap...

Separate wireless controller, see the glue code at [0]

[0]: https://github.com/qmk/qmk_firmware/compare/master...nuphy-s...

If you have a keyboard that runs QMK firmware[0] with the VIA[1] feature enabled[2], then there is a convenient testing app available from the same place you customize your keys [3].

[0] https://qmk.fm/

I made a layout that I'm happy with. Spanish is my native language, so it has characters like the accents and 'ñ', but it's meant to be used for programming as well. Visual Studio uses a lot of Ctrl and Ctrl + Shift shortcuts, so I left them in the same place as the default Corne layout so I can press them both with my pinkie finger. Perhaps some of the ideas are useful to you.

Also, it would be possible to do this for the RP2040. However, it needs some work to get working. but for example: https://github.com/qmk/qmk_firmware/pull/20999

Ok, it's an ST7735, not too different from the ST7789. You should be able to get running by looking at their files in the QMK repo and going from there. You should also check their resources page.

UPDATE: after fluffing around a little bit, I have manged to fix this code: https://github.com/qmk/qmk_firmware/blob/master/keyboards/lily58/keymaps/bongocat_wpm_responsive/keymap.c and flash it successfully - it seems not to be working correctly as the cat is only hanging there and does not respond to the wmp count. If anybody spots anything wrong in the code please let me know!(C is not my language but I am a programmer, I am gonna get at it again over the weekend if I have time left)