There is a number of options on the memory side of things. I feel that stack usage could be estimated a bit more simply with rust and it's __morestack support, so that it would be possible to run a few threads with preemptive scheduling (__morestack also guarantees that no memory corruption would occur due to stack overflow).
I'm totally against "unmanaged" heap support and ~T on embedded, that just doesn't work. It's a very big burden to support that reasonably in existing C/C++ RTOSes out there, so I don't want to spend lots of time trying to solve the same problems. Still, heap is really useful in some cases (as I've figured out while working on 802.15.4 stack for zinc). My current idea is to make dedicated pools that could hold a compile-time configurable number of objects of same size, e.g. an IncomingPacketPool that can hold up to 3 frames where one frame is 128 bytes long. This way no other running process can interfere with code that processes incoming packets and that code can offload incoming packets into the pool for later processing, but up to three, and it will act in user-defined fashion (drop packets) if the pool is full. The implementation of that would be quite simple, and I think that it might be possible to extend ~T ownership for something like that. On Wed, Apr 23, 2014 at 3:47 PM, Ben Gamari <bgam...@gmail.com> wrote: > Vladimir Pouzanov <farcal...@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 > 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 > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
