Rust on Particle: development discussion

[mdma]

Hey there, you've heard that we're looking for help developing Rust on Particle?

Rust on Particle: call for contributors

Continuing the discussion from Will we one day see rust-lang support? : Hey all! @mdma has built a small proof-of-concept for using Rust to do firmware development on Particle devices. While the implementation so far is very minimal, I think there’s a big opportunity to build this out as a complete solution where Rust is an alternative to coding in “Arduino” (i.e. Wiring/C++/C). Given that we’re not Rust experts, we’d love to get help from the community pushing this forward. Thi…

Let's use this thread to discuss development of Rust on Particle! Excite!

[mdma]

Let’s get going! Here’s a summary of our discussion so far from the PR conversation:

• The user-facing API will be idiomatic rust, making effective use of traits. Traits will allow the capabilities of the system resources to be described and checked at compile time. For example, not all pins support PWM - traits will capture this information so attempts to use PWM on a pin that doesn’t support it would result in a compiler error.

• we’ll consider using parts of zinc.rs that allow bare metal interaction with the MCU, to provide an equivalent of the CMSIS API that C++ developers have access to on our platform.

• for discussion: will the user API be object-oriented (OO), functional, procedural? Wiring++ and original Wiring are examples of OO and procedural API paradigms.

[zach]

I’m not a Rust expert but I’ve played with it a bit, and am reading up on Rust idioms while I type some thoughts here.

• I think we should keep the fn main() {} standard basic Rust application format rather than replicating the whole setup() and loop() thing from Arduino. I see that Rust has a loop keyword so perhaps a template Rust app looks like this:

fn main() {
  // setup-y things
  loop {
    // loop-y things
  }
}

• I’m really excited to use Cargo and have a real package management system. We should lean on Cargo heavily, which will hopefully give us some nice modularity. That also suggests that an empty template app should begin with importing the Particle crate, and then maybe the board definitions are modules? Something like this:

extern crate particle;

use particle::photon as board;

fn main() {
  board::pin_mode(D7, OUTPUT);

  particle::publish("Photon is initialized!");

  loop {
    board::digital_write(D7, HIGH);
    delay(1000);
    board::digital_write(D7, HIGH);
    delay(1000);
  }
}

• Regarding OO vs. functional, my gut says functional, but at the same time I’m struggling to imagine what the syntax for each would look like, and in particular what an easy-to-use functional programming API would look like, since functional programming can often be scary for n00bs.

[zach]

Another thought - since Rust is all about safety, it’d be great to utilize that safety to ensure that boards and their peripherals are properly initialized. for instance, if you try to digital_write a pin that has not been initialized as an OUTPUT, it should fail on compile (with beautiful, easy-to-understand compile errors). similarly, if you try to initialize two peripherals that utilize the same pins, it should also fail on compile, perhaps unless you de-initialize the first peripheral before initializing the second?

[zach]

Also, here’s somebody else’s attempt at mashing up Rust and Arduino:

jensnockert/dueboot

Not my favorite, as it uses Arduino’s camelCase syntax, but there might be some interesting learnings in there regardless

[zach]

Rust just announced 1.6, which is an important milestone for using Rust on embedded systems because libcore is now stable:

Announcing Rust 1.6 - The Rust Programming Language Blog

[tjp]

@zach

I think we should keep the fn main() {} standard basic Rust application format rather than replicating the whole setup() and loop() thing from Arduino. I see that Rust has a loop keyword so perhaps a template Rust app looks like this:

Is that possible? How would the system firmware support that? I'm sure this is among the things you're discussing internally. I would imagine that main is already an unmangled symbol in system firmware, but perhaps another symbol could be used? I'm really eager to help this move forward.

[mdma]

It’s possible to have main as the main entrypoint. With dynamic linking of the application code, ultimately it’s boils down to a function address in a table - the name isn’t significant. This would replace what we normally use for setup(), and loop() could be a call to System.reset() , an infinite loop or some other appropriate action.

[dbrgn]

I left some comments on Github: https://github.com/zsup/firmware-rust/issues/2

[LukeUSMC]

Until we have a maintainer who will be organizing the effort? I would be more than happy to jump in today but not sure who is doing what and the priorities should be. Not to over manage something like this but I would participate in a Trello board to keep focus on priorities and who is working on what.

[zach]

I’ll do my best to keep it organized, but the best place to dig in is on Github Issues, and we can use that to manage and prioritize efforts:

zsup/firmware-rust

[fbeachler]

Does Rust’s use of the GCC ARM toolchain mean no runtime-type-inference (RTTI) on ARM, just like C++ on ARM?

[japaric]

Rust only uses arm-none-eabi-gcc for linking, whereas the LLVM backend is used for code generation. Also, there is no 1 to 1 equivalent to C++ RTTI in Rust. But, depending on what you want to do, generics, traits and/or enums may cover your use. There is also the Any trait and the TypeId struct for dynamic typing and downcasting.

Disclaimer: I have limited experience with dynamic typing in Rust, but I’m sure the folks in Mozilla’s IRC channels like #rust can answer any questions you have about dynamic typing idioms in Rust.

[mdma]

If rust needs RTTI for dynamic typing, we can enable that for the application firmware. It’s been disabled by default simply because of the increased size of the binaries produced. If there’s a way to only add this to the build conditionally upon the use of dynamic typing operators that would be ideal.

[Tycheon]

Is there anything that can be done on this project without actually having a board on hand?

[mdma]

Yes, lots! We can discuss the design of the api, implementation choices, build systems. There’s much that can be done without having the hardware.

[Tycheon]

Perfect!

Although, impatience kicked in, and I ordered a couple of kits yesterday, which will hopefully be here in a few days.

I’m still relatively new to rust (only started looking at it just before Christmas, and didn’t have much time in there), so I’m still a bit wobbly on some of the higher level constructs. That being said, I’d like it if we could keep things as close to idiomatic-rust as possible; I’ve a feeling that doing so will keep us from having to fight with the language as we go, and what I’ve learned so far is that rust fights you back when you fight it… hard. Also, the more idiomatic it is, the easier it’ll be for those with rust experience to pick up and use the api.

I don’t believe it’ll need RTTI, as there’s no dynamic typing in rust… at all. Even a single generic function (generics are rust’s way of handling polymorphism) which is called by multiple different types, is turned into a separate “monomorphic” function for each of those types at compile time. My understanding is that only those types that actually call that generic function will have a monomorphic function created for them at compile time … so the binary won’t bloat more than it absolutely has to.

[tjp]

That seems to be the consensus among those who want to participate, we all seem to want to maintain idiomacy for all the reasons you mentioned. @Tycheon, have you checked out the issues on @zach’s repo? There’s been some discussion there as well.

[Tycheon]

@tjp I did take a peak, yeah. Being relatively new to rust, and completely new to Particle (as well as not having anything to test on), I figured I’d come here to ask the newbie questions, rather than cluttering up an issue thread.

Also, I wasn’t entirely sure that that was the consensus; There were a number of people in favour, but no “Perfect! Let’s do it this way!”, so I figured I’d add another voice to the consensus, just in case.

Either I’m looking in the wrong spot (incredibly likely), or it’s all still very very nascent. So I’m left not really knowing where best to try and help out; Completely as a result of my own inexperience, without question.

[Tycheon]

Just saw /zsup/firmware-rust/issues/2 on GitHub (this portal won’t let me link it, as more than 4 links show up in the preview pane)

… Clearly I need more coffee >_<

Sorry for tanking the S:N ratio