@whitequark

I know, futures and stuff, but honestly I find Rust’s futures impenetrable.

I was wondering what about futures you don’t like? The excessive use of

closures and adapters, that you have pass everything by value to not get

yelled at by the borrow checker, or something else?

What approach would you prefer to use for cooperative multitasking? Something

more like coroutines / generators ( yield )?

BTW, will you continue working on your port of libfringe to ARM? I’m looking

forward to trying it out on ARM Cortex microcontrollers.

@rayman22201

I’m a hobbyist and a Rust beginner, so probably ignore me

No, no. I listen to everyone who’s interested in embedded systems and Rust.

I have a bunch of old esp8266’s lying around that I would LOVE to Rustify…

Sadly we can’t do much if there’s no support for that architecture in LLVM

:-(. Let’s hope that it will happen someday.

@jeko

Thank you!

What I like is to have a minimal environment (vim, cli) to write, compile,

test and load my apps.

You are covered; that’s how I like to do my development.

@SimonSapin

I think the lesson is that panics in embedded contexts are much more

problematic than in other contexts

nods I routinely check that the generated code (when compiled in release mode)

is free of calls to rust_begin_unwind , and thus free of panics. If not I trace

it down and see what’s causing it. I sometimes find contract violations

( assert! s hit due to programmer error), and sometimes LLVM needs some help to

optimize away panics.

Perhaps another library could provide something like …

Yeah that sounds reasonable. I didn’t realize you could create trait objects in

static context. Nice! We could use a symbol to achieve dependency inversion:

// in e.g. cortex-m crate macro_rules! eprint { (..) => { extern "C" { __STDERR__: Mutex<Option<&'static fmt::Write>>; } unsafe { /* use __STDERR__ here */ } } } macro_rules! set_stderr { ($STDERR:expr) => { #[used] #[no_mangle] static __STDERR__: Mutex<Option<&'static fmt::Write>> = Mutex::new(Some(&$STDERR)) } }

then in the application crate:

struct Serial { .. } impl fmt::Write for Serial { .. } static SERIAL: Serial = Serial::new(); set_stderr!(SERIAL); do_thing().unwrap_or_else(|| eprintln!("something went wrong"));

The set_stderr! macro is there to make sure that what will become the

__STDERR__ symbol has the right type. Perhaps the type of __STDERR__ can

just be Option<&'static fmt::Write + Sync> ? I think that could also work and

wouldn’t need to depend on the Mutex type.

But please if we do this let’s make it clear that libraries should not

implicitly be using eprint! in their implementation, unless they do that in a

way that can be disabled via some Cargo feature. Some applications are time

critical and can’t afford this kind of logging. Libraries should be returning

Result s to indicate error conditions.

@therealjpster (Sorry, I think I cc-ed the fake @thejpster )

in the form of discrete crates, like embedded-serial with Windows/Linux/Mac

support

With Linux support; that’s an interesting requirement. You want to be able to

test the logic of embedded applications on Linux?

You can add the TI Stellaris Launchpad / Tiva-C Launchpad to your list of

supported hardware

Sorry, I forgot about that one. I think we should have a list of supported

hardware in the rust-embedded/rfcs issue tracker. At least until we get a proper

website.

@Razican

Amazing to see money invested in embedded Rust development, that’s why I’m

also a patron

If I have a Rpi, what do I need to create a target specification?

You can start from the ARM Linux one: rustc -Z unstable-options --print target-spec-json --target armv7-unknown-linux-gnueabihf (needs nightly). I

don’t think you’ll have to change too many things: probably just set os to

none and env to eabihf

I want bare metal

The RPi, having a Cortex-A processor, is a very different animal from Cortex-M

microcontrollers. The boot process is more complicated; you’ll have to deal with

the MMU; etc. I can’t give you too many pointers; the folks at #rust-osdev

probably know the processor better than I as some of them probably have

developed general purpose OSes for ARM.

but the main problem I see is that all embedded tools/tutorials assume you

know about embedded development

I hope the Discovery book helps you with that

@Michael-F-Bryan

I want to use Rust as a component of a C/C++ application.

We don’t have many examples of that I think. Less so in the embedded space.

TL; DR: …

I agree. Documentation is key.

@jolson

Rust doesn’t support my target device architectures, in my case AVR and older

ARM (pre Cortex).

AVR support is on the works. I hope to produce material on that once the AVR backend is

merged into rustc because, currently, the entry bar (a custom rustc) is too high

for all of us.

By pre Cortex ARM do you mean ARMv5 processors that run embedded Linux? I got an

e-mail asking about support for that this week. I should probably an issue about

that if there’s more than one person interested in it.

@creationix

The Padi board has a RTL8710 chip in it, right? I think I have one of those

chips sitting in my drawer.

I could then help write the docs and IDEs, libraries, etc to build a rust

maker community to rival esp8266.

Are you volunteering? (I already wrote down your name)

What I find frustrating about the RTL chip is that there seems to be zero

documentation about it: No description of the registers, no SVD files, no

reference manual, no open source code. You have no choice but to use their SDK.