Comment by LeifCarrotson
7 days ago
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.
I had no troubles targeting an ATTiny13A with Rust.
(had to disable debug symbols, though)
Why should that be any harder than C?
Rust compiles to bare metal (assembly aka machine instruction code), just like C does.
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.
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.
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.
3 replies →
In Embedded, it's usually agreed that "Bare Metal" means using no OS, not meaning using low level languages.
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.
1 reply →
Check out the video introducing Swift for Embedded. Seems like a really nice devX for this kind of thing.