We really need a less ambiguous phrase than bare metal for this, because searching for "Bare Metal Rust" really isn't going to get you the results you want here.
There already is a term: freestanding. A program that can be executed without a runtime or an operating system present. Bare metal refers to software that runs natively on the "bare metal", as opposed to with an interpreter.
I think Google partitions people into categories, so if you have searched a bunch of programming related stuff previously, it changes the weighting for the rust programming language.
Yes: I work in an industrial plant, mostly doing numerical simulation work. I work at the smelting end rather than the "real" metallurgy part.
My day to day work largely involves maintaining and improving various process models (largely written in C or Fortran) which feed into our operating guidance systems.
I tried a Google search in an incog tab as an experiment, most of the first page results were relevant. Seems like reasonable terminology given that test.
Very cool, thanks for sharing the info on using rust bare metal!
I'm really curious to try running rust code on the popular ESP8266 module (http://makezine.com/2015/04/01/esp8266-5-microcontroller-wi-... and http://www.esp8266.com/), but I think the board's xtensa architecture and LLVM's lack of support for it means its a non-starter. If anyone is a LLVM guru, is there any hope of compiling code for xtensa architecture and ABI? Or is there any crazy way to get LLVM to compile rust into plain old C code that can then be compiled with the modified GCC toolchain that supports the ESP8266's xtensa architecture?
This is awesome, surprised the author isn't using libopencm3[1] rather than ST Micro's pretty horrendous library. But the awesome thing is that between this and Zinc I expect there will be a lot of interest in Rust on "high end" embedded platforms.
[1] Disclosure I contribute to that repo when allowed to :-)
This is great! I've been thinking about doing something like this with Rust for a while. Anybody have experience using Zinc.rs[0] in a similar capacity?
That is the hope, since master is currently out of date.
I have been working with Matt Coffin some on getting this working. Feel free to increase its chances of merging by helping us test any of the supported boards (Freescale K20, NXP LPC17xx, SAM3x (on a branch), STM32F4, STM32l1, TI Tiva C).
I plan on putting together an RFC for how we can modify zinc (or provide documentation) to make it easier for individuals to create both libraries and projects that work well with zinc, but do not require modifying zinc itself.
Yes, I believe so. The binaries I have built so far have been very small (<2KB for a blink example). mcoffin has a branch with SAM3x support, which appears to be the processor on the Due: https://github.com/mcoffin/zinc/tree/sam3x
The Due has 512KB of room for code which is quite a lot (for microcontrollers).
* Assuming the code size overhead does not continue to bloat after some initial overhead, I think rust can still be very competitive. Although modern embedded systems are still very constrained, the days of 8-bit micros are basically over. You can buy a 32-bit ARM micro for nearly the same cost with sufficient RAM/Flash to run rust well.
* Looking back, I think the size of blink should actually be closer to 600 bytes. Will need to investigate: http://zinc.rs/stats/
That depends on what's in there. My understanding is that that 2Kb is not so much overhead as required dependencies. Dependencies that most real applications would probably end up pulling in anyway, like a dynamic memory allocator.
The end of the market with tiny micros and extremely simple applications (like just blinking LEDs) is likely to never be well suited to Rust, but doesn't gain much from it anyway.
> Some utility to assist bulk conversion from C to Rust would be nice
One of the problems with this is that Rust's guarnatees usually really affect your design. I'd imagine that a bulk C -> Rust translator would have to use `unsafe` all over the place.
Doesn't mean that it wouldn't be useful, but I wonder if slowly replacing APIs bit by bit isn't a better approach overall.
Yeah, the ease and mostly-cost-free nature of C-Rust interop is a really big selling point, as you can pretty much just drop Rust in piecemeal to replace your legacy libraries.
I think the better approach here is to phase out existing applications in chunks. You can link call rust code from C (when externed and rustc is told not to mangle) and C code from rust (via ffi).
My experience with code automatically converted has not been good.
