Survey: Frequently Asked Questions
Closed this issue · 12 comments
Let's start collecting questions for the FAQ!
What people usually ask about when they think/read/talk about Rust and embedded systems?
Post those questions here. It's OK if you post a question that seems similar or related to a question someone else already posted. I'll collect all the questions up here and then we can derive a smaller set of more general questions from this bigger pool.
Here's a good example from Reddit:
- How is Zinc.rs going?
- Is there an updated tutorial to deploy Rust into an Arduino and other small devices?
- Is there already an 'Are We IoT Yet' website?
- Where could I direct people that are interested to talk about IoT and Rust?
Another type of question I often hear is the one that involves the words Rust and Arduino:
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?
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
- 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?
what is the status of zinc?
Asked twice in the lapse of 24 hours on the #rust-embedded IRC channel.
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?)
@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)
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.
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.
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
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.
I am closing this issue, please feel free to open another issue if you would like this discussed further.