4 ms·

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

by mh7 4y ago

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.

nynx 4y ago
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 4y ago
  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.
  - nynx 4y ago
    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.
  - zozbot234 4y ago
    > 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 4y ago
      They certainly are when LTO and PGO are part of the picture.
nicoburns 4y ago
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
tlamponi 4y ago
> 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.html https://docs.rust-embedded.org/book/static-guarantees/index....

by mh7 4y ago

nynx 4y ago

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 4y ago
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.
- nynx 4y ago
  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.
- zozbot234 4y ago
  > 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 4y ago
    They certainly are when LTO and PGO are part of the picture.

nicoburns 4y ago

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

tlamponi 4y ago

> 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.html https://docs.rust-embedded.org/book/static-guarantees/index....