usbd-human-interface-device VS rp-hal

As someone who had only done embedded programming in the Arduino IDE, utilizing the defmt crate for logging with OpenOCD and GDB was an amazing experience. Although I still had no idea on to implement USB-HID for actually sending the key reports, until I discovered the usbd-human-interface-device crate and everything became so much easier. I just needed to create an iterator over Keyboard events and the crate would handle the rest as an added benefit the crate also supports multiple devices, so adding mouse support was as easy as creating a separate iterator over WheelMouseReport.

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