[mh7]

rust doesn't offer much value for embedded (mcu, bare metal, tiny stuff) imo.

No allocation = no leaks, no use after free, no dangling pointers.

No multi core = no atomics or concurrency to worry about.

Ring buffers solve 99% of my interrupt data sharing = no need to worry about synchronization.

Bounds/safety checks? Need to run and test release builds most of the time because of space/memory constraints.

[tlamponi]

> No allocation = no leaks, no use after free, no dangling pointers.

Often you don't allocate because it's not a necessity and a PITA due to C, but with rust I see no point in not using a tiny allocator if one has a few 100 KiB of RAM - totally depends on the project and target platform.

> No multi core = no atomics or concurrency to worry about.

There are interrupts though and those just need the same mechanisms than multicore and can be a PITA to manage in C. Besides that, there are quite a few cheap multicore embedded CPUs available now.

You can encode safety checks like pull-down/up clashes and the like nicely via the rust type system, that alone makes it a major benefit over C.

For example, from the rust embedded book:

    One can also statically check that operations, like setting a pin low,
    can only be performed on correctly configured peripherals.
    For example, trying to change the output state of a pin configured in
    floating input mode would raise a compile error.

-- https://docs.rust-embedded.org/book/static-guarantees/index....

[nicoburns]

It's a bit early, so there are currently lots of downsides, but some potential benefits:

- The package management is a nice. Install a generic ring buffer or a board support package for the hardware you are using.

- Async-await can be really nice for dealing with hardware peripherals.

- Don't interrupts constitute concurrency?

- Reduced UB and footguns compared to C

[nynx]

Rust absolutely benefits embedded software. A big reason is that the type system allows libraries to let you enforce invariants at compile time.

For example, your i2c controller only supports two specific pins and they have to be in a specific mode? That can be a compile error if you make a mistake.

[allanparthore]

Configuring pins and peripherals with code is a chore, I use graphical tools for that.

But C has no problems abstracting away peripherals, just hide the register bits in a private TU and expose i2c_init(), i2c_write(), etc.

[zozbot234]

> just hide the register bits in a private TU and expose i2c_init(), i2c_write(), etc.

That's not a zero cost abstraction, unless these "functions" are actually provided in an include file. Embedded programming is often performance sensitive, so this can matter.

[pjmlp]

They certainly are when LTO and PGO are part of the picture.

[nynx]

It’s a chore because the alternative in C is to do things perfectly without the machine doubling checking your work. That assumption does not hold with tools other than C.