Posted 2018-01-12 23:23:07 +0100

blogs->all

Rust bindings to nrf52 series

In mid-2017, I came across this project by James Munns. It essentially wraps the C SDK for nRF52 development boards, and provides bindings that can be called from Rust. James gave a talk to the Rust DC Meetup, remotely over video conference. This talk inspired me to buy a couple of nRF52 dev boards.

I'd like to announce that here, in Nordic's official channels, because I'd like more embedded developers to become aware of it. Rust is a language that has the ability to compile down to native code with zero runtime, and no operating system. In other words, Rust can run on bare metal hardware. Today.

My ultimate dream is for hardware manufacturers themselves to provide official support. My understanding is that supporting Rust will be much more akin to supporting C, and not really like providing a special runtime for embedded Python or JavaScript.

Some challenges we will face (you can help!):

  1. We do not have a clear path for upgrading our Nordic SDK. We simply check in the C code, and there's some manual work around collecting all the headers for input to code generation.
  2. Speaking of code generation, bindgen, the tool that takes C header files and generates rust types, has been evolving rapidly. On one occasion the changes to generated code caused breaking changes in our nrf52 bindings library.
  3. We have a few examples to test blinking lights and connecting via bluetooth, but perhaps we might benefit from a more structured list of things to test to ensure we provide working bindings to the whole nrf52 dev kit.
  4. Related to 3, just kick the tires and open issues if you need help!

If you are interested, here are some links to learn more:

Here is a link to the GitHub repository

Here is a link to the full video recording of the DC Meetup talk. It offers a detailed overview of our embedded development workflow.

Finally, here is a recent talk about using "unsafe" code in Rust. This is relevant, because in the embedded context a lot of code involves usage of the unsafe keyword. This talk explains why that's necessary and not as scary as it sounds.

6 comments

MatthewLai gravatar image

Posted Jan. 12, 2018, 11:26 p.m.

What's the advantage of using Rust instead of C?

Posted Jan. 12, 2018, 11:34 p.m.

Why Rust? Language designers have learned a lot in 40 years. Rust has:

  • Built in tooling for compilation against different targets. Managing toolchains for different targets is officially supported
  • Built in, standard package manager
  • A type system that gives you abstraction without necessarily requiring indirection or additional memory cost. It's possible to get the compiler assurance of abstractions, but with zero-sized types.
  • compile time checking of race conditions and dangling pointers (although less important in single-threaded/no-heap environments).

It's true that C++ has most/all of the "features" Rust has, but there is a benefit to using a language with a design that feels modern, and with strong built in tooling.

MatthewLai gravatar image

Posted Jan. 14, 2018, 3:08 a.m.

In other words, yet another Java? Seriously, for a crotchety curmudgeon like yours truly who's a diehard C advocate (fyi, 30 yeras back would be c, and 40 years back would be Lisp & Fortran), why should I go through the pain of picking up another language that feels (<---- you do know this is a subjective judgement, don't you?) modern when there are tons of other modern languages to pick from, say Go for instance?

bootchk gravatar image

Posted Jan. 14, 2018, 4:04 p.m.

If you are interested in this topic, also search for japaric, svd2rust, "tock os", "embedded rust", and "open source bluetooth stack". If you are open to omitting the Nordic SDK entirely, and want the benefits of Rust in lower layers.

MatthewLai gravatar image

Posted Jan. 14, 2018, 6:06 p.m.

Is that the best 60-second pitch for rust that you can come up with?

hfchin gravatar image

Posted Jan. 17, 2018, 6:39 p.m.

Rust targets the LLVM, which is the compilation toolchain used for industry standard languages such as C++, Obj-C and Swift and is very mature + highly optimized at this point, with support from companies such as Microsoft, Apple, etc.

Rust ensures zero-cost abstractions, pattern matching, memory safety (no dangling pointers, etc), at compile time rather than at run-time.

Rust's procedural macro system is much more powerful than C macros, and enables you to create things like "futures" which can abstract away things like manually coded state machines. The closest thing in C I've found are "protothreads" which are still not "zero-cost".

If you need to drop down to manual memory manipulation and ignore Rust's safety guarantees around memory and data races, they provide an escape hatch keyword called "unsafe", which doesn't tend to need to be used.

I do agree, the tooling around Rust on the embedded side needs improvement, and James Munns's wrapper around the nRF52 SDK needs another layer to abstract the unsafe calls, but I'd be very happy to use Rust to create useful libraries which I'd call into from C at this point, just not as the application level code as well. I've been experimenting with calling into cbindgen to build a no-std library to integrate with C code as Rust has a very good FFI thanks to it's lack of a runtime.

Sign in to comment.

User menu

    or sign up

Recent questions

Related posts by tag

No results