Survey: Frequently Asked Questions about wg HOT 12 CLOSED

Another from Reddit:

• Why would you run embedded then if you can get a full os at the same form factor, Is it for power usage or custom hardware interactions?

from wg.

CC @ratkins @alevy - I would love for you both to weigh in here: #56 - we are working on determining what should be in the "Embedded Rust Book", and I think you would have valuable input.

from wg.

A question I see (and attempt to answer) on most /r/rust embedded threads is, "Can I run Rust on my ESP-8266/32?". Which then inevitably leads to, "How does one write an LLVM backend?" and several other related questions.

In addition to a stock explanation to those questions, I think maybe a simple grid of common chipsets (hobbiest to prosumer), their architecture, and a red/yellow/green color code on a "are we embedded/IoT yet?" site would go a long way.

from wg.

A question I see often on IRC, and I also get private e-mails about, is e.g. "My Rusty binary file is 200KB in size but my microcontroller only has 64 KB of Flash. How will this work? On Arduino I get files of 2KB in size. Am I doing something wrong?".

The issue is that people are looking at the output of running ls on an ELF file, when they should instead by using the size program. On Arduino land ls works OK-ish because they are using it on a binary file.

cc @jamesmunns this definitively should be in the book

from wg.

A question I have is how do I go from knowing about the existence of embedded-hal, to running Rust code using those APIs on the microcontroller I have in front of me—whatever that happens to be.

(What I mean is, I as far as I understand there needs to be an implementation of embedded-hal for a particular microcontroller/board, what is the canonical source for those? Where do I start if one is not available and I want to start writing one?)

from wg.

I think this can be closed, as this info has been captured by the "new-book".

Marking this for a cleanup sweep. If we would like this to stay open, please provide an update to what this issue should be focused on.

from wg.

Why would you run embedded then if you can get a full os at the same form factor, Is it for power usage or custom hardware interactions?

This is a really important one, I think, especially as far as motivating why a language community ought to care about supporting that sort of development.

Some arguments I've been collecting:

• ~3 orders-of-magnitude difference in sleep power consumption. This is partially due to the hardware actually focusing on sleep current, but also to do with fundamental differences between SRAM and DRAM.
• Many orders of magnitude less complex, so doing things like hardening a microcontroller against timing attacks is feasible, while doing it for an application processor is just not.
• Microcontroller SoCs can be fabbed for as little as $10k (minus licensing ARM, but RISC-V will eventually solve that too), so custom hardware is totally plausible. This, of course, also effects cost

from wg.

• What's the overhead of using Rust vs. C for embedded?
• What's the benefit of using Rust for embedded?
• Can I compile Rust for XYZ-obscure ISA?

from wg.

what is the status of zinc?

Asked twice in the lapse of 24 hours on the #rust-embedded IRC channel.

from wg.

@alevy agree with your points, to add some further reasons we don't use linux everywhere.

• you can't get a full os in the same form factor
• order of magnitude difference in price (and power consumption, both running and sleeping)
• you need predictable execution / actual real time
• you're building anything against a safety standard (complexity directly corresponds to difficulty and cost)

from wg.

One of the things I am not sure clear on is what's ok / not ok in the no_std context, might be a good addition to the faq / book.

from wg.

I am closing this issue, please feel free to open another issue if you would like this discussed further.

from wg.