Speaking as someone who writes firmware for a living, Rust will never be a replacement for C in its current state. C has one property that sets it apart from every other language that is higher level than assembly. It is possible to write a C program that does not need *ANY* C run-time library support. Our firmware runs on the bare metal without any OS whatsoever, so running Rust in firmware requires building all the services that the Rust run-time requires (heap, threads, etc.) and porting the Rust run-time to it.
So unless we want to write heap, threads, etc. in assembly... C is our only option for bootstrapping Rust. Since we are using C for that part of our code base... why not use it for all? The firmware I work on doesn't do a bunch of string manipulation of other things that makes a higher level language like Rust nice. Why add all that additional complexity to support Rust? By the way, anyone writing an operating system kernel is going to run in to the same thing with Rust.
It would be possible to bootstrap Rust on top of a basic kernel written in C and maybe even use it for some of the kernel code (drivers for example, like how OSX uses C++ for I/O Kit drivers), but Rust will never replace C. It would be nice if someone designed a new **Systems Programming Language** that can run without a run-time and had some of the features that newer languages do... but it seems the only thing people think about when designing new languages these days is the web and/or cloud computing.
Despite what the Rust developers claim, Rust is not a real Systems Programming Language in its current state since it requires a run-time. Its OK to have an optional run-time and for some features to stop working when its not there... but it must be optional not required.