I would rather see Atmel AVR or ARM Cortex M0 as targets. Also, would low voltage, low power 8-bit targets with under 512KB ram be impossible ?
On Fri, Jun 21, 2013 at 10:20 AM, Thomas Daede <daede...@umn.edu> wrote: > Hello, > > I'm relatively new to Rust, and this is the first time I've posted on > this list. For my senior honors thesis, I would like to improve Rust > so that it can be used on microcontrollers and other small embedded > systems. This is a sector dominated by C and has seen little change > for quite a while, due to most other languages not meeting the unique > requirements. Besides being constrained in RAM and CPU power, the > program binary also generally runs directly out of NOR Flash based > ROM, so that the binary code itself takes no RAM space. This precludes > most JIT based systems - interpreter based languages take less RAM, > but are also very slow. > > Rust is in many ways a very good fit for microcontrollers. Its memory > safety is very useful for many different applications, and helps > greatly for task isolation on systems without memory protection. In > addition, memory allocation is explicit so the programmer can choose > where best to allocate the RAM - important for things like avoiding > the GC in sensitive code regions. And of course, there are all the > other benefits that Rust has compared to C in general. > > However, Rust isn't ready for microcontrollers yet. Here's what I plan > to implement, in order: > - Static linking for runtime and Core crate > - Compiling runtime and Core without thread support > - Adding compatibility with the newlib C library > - Adding configurable stack allocation > - Adding arm-none-eabi target > - Wrappers around a native C peripheral library, such as libopencm3 > > This should be the bare minimum to get a demo up and running. I plan > to target the STM32F4 series of microcontrollers initially, using > libopencm3's linker scripts, and the C compiler and linker from > gnu-arm-embedded. I know there has been some work to remove the > dependency on the core and runtime libraries, however it seems > difficult to strip them out entirely, and I think they are useful > enough that I would rather port them instead. > > I would like to know if anyone else has tried this yet, or has > comments about how this should be implemented. > > - Thomas Daede > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > -- -Thad http://www.freebase.com/view/en/thad_guidry
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
