News for hackers. Stuff that matters.
Re:Enabling Rust on Embedded Platforms – Linux, RTOS, Bare M... by th0br0 on Monday October 16, 2017 @06:54AM (#15482313)
I've been using japaric's awesome work on Xargo (for cross compiling the std lib) to target a variety of ARM Cortex'es. Sometimes doing all work in Rust, sometimes just for linking against Rust crates in a C program. It's a breeze and super fun.

This is, in my opinion, where Rust really shines: using one codebase - without installing any new tools - I can target pretty much all platforms from embedded to browser to mobile.

Re:Enabling Rust on Embedded Platforms – Linux, RTOS, Bare M... by samlittlewood on Monday October 16, 2017 @07:02AM (#15482348)
Also enjoying https://github.com/japaric/svd2rust - Generates simple uniform register mappings for various cortex-m and msp430 micros.
Re:Enabling Rust on Embedded Platforms – Linux, RTOS, Bare M... by yammajr on Monday October 16, 2017 @08:53AM (#15482820)
I was disappointed when I tried to use svd2rust for the atmel-provided svd's. They unfortunately do not provide reset values for some registers, which causes svd2rust to panic.
Re:Enabling Rust on Embedded Platforms – Linux, RTOS, Bare M... by doctor_stopsign on Monday October 16, 2017 @11:17AM (#15483776)
I was able to make a hacky fix for that. If you get the `svd2rust` source code and modify `generate.rs` on line 756 you can get it to generate a library file and not panic.

There are still a ton of warnings that pop up, and I haven't yet tested it on an MCU but in theory it should work.

Re:Enabling Rust on Embedded Platforms – Linux, RTOS, Bare M... by yammajr on Monday October 16, 2017 @12:28PM (#15484413)
I did exactly the same thing, but I'm not totally happy with it. Good for fooling around with, but not convinced I'd want to push something using it into production without a bit of further investigation.
Re:Enabling Rust on Embedded Platforms – Linux, RTOS, Bare M... by ehntoo on Monday October 16, 2017 @05:32PM (#15486786)
I think the standard approach for crates to work around problems like this is to patch the vendor's XML. Terrible that it's necessary, but workable. The "STM32F103xx.patch" in japaric's stm32f103 support crate [1] seems a decent example of the sort of hacks that are standard. [1] https://github.com/japaric/stm32f103xx/blob/master/STM32F103...