Vladimir Pouzanov <[email protected]> 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 issues. Cheers, - 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
pgpbYswF8mBLr.pgp
Description: PGP signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
