[LeifCarrotson]

Yes, that's "bare metal" as opposed to programming in MicroPython, Javascript with Espruino, Lua/NodeMCU, Rust, or adding your C application on top of an off-the-shelf RTOS.

C support is basically universal these days, very few chips require you to program in only assembly anymore.

[kawogi]

I had no troubles targeting an ATTiny13A with Rust.

(had to disable debug symbols, though)

Why should that be any harder than C?

[daveguy]

Rust compiles to bare metal (assembly aka machine instruction code), just like C does.

[chlorion]

It also supports running in freestanding setups without an OS, and quite a lot of the language's features still work.

I was extremely surprised by how much functionality is packed into "core", and runs without an OS when using freestanding rust. Even stuff that requires an allocator can run provided you provide your own heap!

A cool example of this was implementing fmt::Write for a memory mapped uart console thing. Then implementing a kprintln! macro that supports all of the formatting machinery that you are use to. This worked without even a heap available.

[supertroop]

Bare metal refers to not using an rtos. I know that sounds weird but it is an industry convention. It does not refer to the language.

[daveguy]

That's exactly what I said. Rust compiles to binary opcodes. Assembly is not an rtos, and does not require one. ASM isn't a standard "language". It's literally a fancy display of opcodes and registers that the CPU reads to execute operations. C does the exact same thing, ie compile to opcodes. You can convert binary back and forth from ASM to opcodes with a lookup table. At its core, ASM is just a convenient way to read and write cpu opcodes. I misspoke saying "to assembly" when I meant "to binary opcodes", but such a minor pedantic misspeak I didn't think anyone who understood embedded systems would not understand the meaning. Sorry about that.

[dcrazy]

Whether the code compiles to assembly is orthogonal to whether the program can function without runtime support.

Compiled Rust code that relies on syscalls will not function on a “bare metal” microcontroller.

[daveguy]

Oh, thank you. I didn't know that. Sorry about my ignorance. Really thought that it defaulted to a direct machine code without library assistance.

[lights0123]

Rust does not rely on syscalls or libraries on embedded targets, which is what the #![no_std] marker at the top of the project indicates. On some platforms, like ESP32, Rust can make calls into the RTOS and don't need that marker, but other embedded targets don't provide access to the std crate and you need to interact with peripherals from Rust or by interfacing with C or assembly.

Rust's only requirement is that memcpy, memmove, memset, memcmp, bcmp, and strlen are available, and it can provide them if needed: https://github.com/rust-lang/compiler-builtins

[mrheosuper]

In Embedded, it's usually agreed that "Bare Metal" means using no OS, not meaning using low level languages.

[daveguy]

Either you do not understand what assembly is, or you are being pedantic about the very thin abstraction between assembly and opcodes. Just in case you didn't know, assembly is a convenient way to read the binary opcodes that the cou uses to move data between registers and execute logic.

Yes, I should have said binary opcodes instead of assembly. I just assumed anyone discussing embedded systems would know they are practically interchangeable.

[ahazred8ta]

The other commenters are referring to bare metal interpreted Forth with no OS, or bare metal ROM Basic with no OS, as opposed to machine code with no OS.

[kridsdale1]

Check out the video introducing Swift for Embedded. Seems like a really nice devX for this kind of thing.