[rust-dev] A small announcement for zinc, the bare metal rust stack

Ben Gamari bgamari at gmail.com
Wed Apr 23 07:47:33 PDT 2014

Vladimir Pouzanov <farcaller at gmail.com> writes:

> This is the project I've been tinkering with for a good number of
> weekends zinc, the bare metal stack for rust is available at
> https://github.com/hackndev/zinc.
> I've just finished a major refactoring work for LPC1768 code, so
> STM32F4 is kind of broken yet, and LPC1114 is totally dropped, but
> I'll fix that soon.
> The current code supports GPIO operations, UART and SSP in SPI mode
> for NXP LPC1768, also featuring a driver for
> http://mbed.org/cookbook/mbed-application-board TFT LCD and for
> ILI9341-based TFT LCDs commonly found on ebay.
> My plan is to fix support for STM32F4, bring it to the level of NXP
> part and try to expand this to a small RTOS, which would be a nice
> demo of rust capabilities for embedded development.
> The code is licensed under Apache-2.0.
> There's no readme yet, but you can see the demo applications written
> with zinc here: https://github.com/hackndev/zinc/tree/master/apps.
Thanks for the release! I've been looking forward to seeing this ever
since your Reddit post a few weeks back as I too have been recently
thinking about how Rust might be used in an embedded environment.

Lately I've been contributing to the mchck[1] project, its associated
library, and a project I've built on top of it[2]. One of the things
that I feel the mchck library gets right is the ubiquitous use of
asynchronous completion notification (e.g. [3]) instead of polling. In
my experience asynchronous code both maps onto hardware more naturally
and produces more composable user code. Unfortunately, C makes
continuation passing very painful due to the broken up flow of control
that results from the sea of callbacks and the boilerplate (e.g. passing
and casting of `void*` pointers to structs of intermediate state)
necessary for propagation of state between callbacks.

As far as I can tell, there are two paths by which Rust might improve
this situation. The most straightforward approach would be to implement
continuation passing directly by passing around continuation
`procs`. While this approach reduces the amount of boilerplate due to
state propagation, it does not really resolve the broken flow of control
due to explicit continuations.

Another approach which addresses this latter issue is to use Rust's
native tasks, allowing requests to peripherals to be treated as
blocking. While this seems like this could be very convenient, I am a bit
concerned that the memory footprint of multiple stacks and associated
bookkeeping data structures might be asking too much of the typical
MCU (the devices I work with typically have 16kByte of SRAM).

This memory footprint issue is especially concerning due to Rust's[4]
heavy dependence on stack allocation. I am very much accustomed to
avoiding dynamic allocation at all costs on embedded platforms; I
appreciate knowing at compile time whether my program will fit on my
device (up to stack allocations, which in my C code are intentionally
minimal). With the uncertainty of dynamic allocation against the stack
and dynamic task creation, it seems one literally has no idea whether a
program will fit without either static analysis, simulation, or trial on
real hardware. However, it seems that one loses a great deal by
reverting to static allocation in Rust (e.g. losing safety of ownership,
memory model becomes burdensome), so perhaps dynamic allocation coupled
with robust allocation analysis tools is a reasonable trade-off.

I'd be very interested to hear what others have to say about these


 - Ben

[1] http://github.com/mchck/mchck
[3] http://github.com/bgamari/data-logger
[3] https://github.com/mchck/mchck/blob/master/toolchain/lib/mchck/spi.h
[4] or rather, ideomatic Rust code's
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140423/d9a9ef6a/attachment.sig>

More information about the Rust-dev mailing list