rtic VS bflat

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

The sibling pretty much sums it up. But if you want more detail, read on:

Generally, there are three publishing options that each make sense depending on scenario:

JIT + host runtime: by definition portable, includes slim launcher executable for convenience, the platform for which can be specified with e.g. -r osx-arm64[0].

JIT + self-contained runtime: this includes IL assemblies and runtime together, either within a single file or otherwise (so it looks like AOT, just one bin/exe). These requires specifying RID, like in the previous option.

AOT: statically linked native binary, cross-OS compilation is not supported officially[1] because macOS is painful in general, and Windows<->Linux/FreeBSD is a configuration nightmare - IL AOT Compiler depends on Clang or MSVC and a native linker so it is subject to restrictions of those as a start. But it can be done and there are alternate, more focused toolchains, that offer it, like Bflat[1].

If you just want a hello world AOT application, then the shortest path to that is `dotnet new console --aot && dotnet publish -o {folder}`.

[0] https://learn.microsoft.com/en-us/dotnet/core/rid-catalog

[1] https://github.com/bflattened/bflat (can also build UEFI binaries, lol)

See here

See B flat

I've been wondering how to integrate modern .NET Core into a custom build system (buck2) and was wondering similar things. There's this project I think is cool called bflat[1] that basically makes the C# compiler more like the Go compiler in the sense it's a one-shot single-use tool that can cross compile binaries natively. It's done by one of the people on the .NET Runtime team as a side project, but quite neat.

I think in practice you're supposed to compile whole .dll's or assemblies all at once, which acts as the unit of compilation; I don't think the csharp compiler generates native object-files-for-every-.cs, the kind of approach you'd expect from javac or g++. Someone please correct me if I'm wrong though! I'd like to learn more about this.

[1] https://github.com/bflattened/bflat

You can compile without a GC using https://github.com/bflattened/bflat

nice. have you tried compile it using https://github.com/bflattened/bflat to have native executable? as long as you don't have PackgeReference it can be compiled using bflat instead of full dotnet

The creator actually addresses this issue: