rtic VS rp-hal

There's also RTIC which is another framework that makes concurrency trivial.

Github here: https://github.com/rtic-rs/rtic

At Telecom Paris, one of the top engineering schools in France, we teach Rust to undergraduate and graduate students who specialize in Embedded Systems. They get to use Rust and RTIC on STM32 based boards, and they also use Embassy for some projects.

If you want something more cutting edge. Try embedded Rust and checkout RTIC. I don't know if it's the real next thing. But i guess it could be fun to try.

RTIC is still going strong, they are working on a 2.0 release at the moment :). There's also now embassy which provides an async runtime (and a ton of other nice things) for embedded as well :)

RTIC - RTOS and task scheduling

That's completely incorrect. The existing ecosystem focuses on web/IO because that's were Async/Await is already being used in other languages so everyone started there. There is significant interest in writing frameworks using async rust in embedded, but the required compiler features for it are still not stable. Check out embassy. Even RTIC has experiments with async.

But neither of them might be usable in you case. Since it looks like you're running bare-metal, a framework like RTIC can give you a initialization function and then pass "static" data to a struct that is shared between all tasks.

FYI, RTFM has been renamed to RTIC

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