Let's work on embedded stuff during the novemb.rs code sprint!


#1

novemb.rs is an offline/online Rust code sprint happening this November 19/20 and it’s also a great opportunity for all the embedded Rust enthusiasts to get together and advance the state of Rust on embedded systems.

Several members of the #rust-embedded community will be participating. Join us!

It doesn’t matter whether you are experienced or not. We have documentation and mentors to get beginners up to speed. And have plenty of fun stuff for people that have previous experience with embedded stuff to work on.

To join you must only be able to use IRC as our online meeting point will be the #rust-embedded channel on Mozilla’s network. There may be some locations for face to face meetings near your location as well, check the novemb.rs site for a list of such locations. Note that the list will likely continue to grow as more locations are being proposed/organized

However, for the full experience you must have access (*) to a development board with a Cortex-M microcontroller in it plus a “programmer/debugger” (either “on-board” or as another board) where both, ideally, are supported by the OpenOCD project (or you won’t be able to use GDB to debug your program or, worst, you won’t be able to get a program into the board in the first place). There are lot of boards that fit this description but here’s a list of boards that Rustaceans have worked with before:

  • STM32F3DISCOVERY. Recommended if you are a beginner as we have beginner friendly documentation tailored for this specific board. (Details: On-board programmer/debugger. Has OpenOCD and GDB support)

  • The DISCOVERY boards. (Details: On-board programmer/debbuger. Have OpenOCD and GDB support)

  • Teensy. (Details: No GDB/debug support AFAIK (SWD pins are not exposed). Uses a bootloader to flash the program into the board)

  • Tiva-C Launchpad. (Details: On-board programmer/debugger. Has OpenOCD and GDB support)

  • Stellaris Launchpad. (Details: On-board programmer/debugger. Has OpenOCD and GDB support)

  • Arduino Due & Zero. (Details: Uses a bootloader for flashing. Supported by OpenOCD but debugging requires an external debugger (hardware))

So, what are we going to do? Right now, the following “focus areas” has been proposed:

  • Onboarding. Getting “embedded beginners” and people familiar with embedded C development but not with Rust’s up to speed with the embedded Rust development process, its tooling and its ecosystem.

  • API design. We’ll be designing APIs (traits) for common functionality (Serial, I2C, GPIO, PWM, etc) making sure that the API can be implemented for as many different hardware as possible. We’ll start with a blocking IO API and then tackle async IO.

  • Tackling “open ended”/unsolved problems. Figuring out how to safely deal with interrupts, developing a PoC preemptive scheduler, developing dynamic allocation strategies that don’t involve the heap, etc.

This etherpad has more details about these areas. Feel free to add other focus areas if you can commit your time to them.

The etherpad also contains a list of participants. Please add yourself to it if you intent to participate. The list is more intended as a survey of the different hardware that people may bring to the event and as way to gauge interest. It will also give us an idea of at what time most people will be online.

We are discussing further details in this issue and on the #rust-embedded IRC channel.

See you in novemb.rs!

(*) @skade might be able to get kits for people that will meet in person at some novemb.rs location. I don’t know what restrictions apply (@skade is in Germany, AFAIK). Contact @skade for details!


#2

I’ll be there!


#3

This looks like loads of fun, but I don’t think I’ll have the time to participate. Will this be the only one?


#4

I have a Stellaris launchpad! I might be participating remotely.


#5

The restrictions are:

  • I know nothing about embedded development, so I’d need a detailed order list
  • I need to convince someone to foot the bill (so, there’s no fixed budget, but also not infinite :slight_smile: )
  • I’d need a contact willing to care for the devices after the event
  • It needs to be early enough to ship the devices

Best,
Florian


#6

Will this be the only one?

Certainly not! If the rust-community team organizes another code sprint we’ll (#rust-embedded) probably participate again. I certainly would participate in future code sprints.


#7

Depending on the success, but yes, this will definitely not be the last.

I’m in favor of running regular and uniform things anyways, as this makes the burden of regular explaining and planning easier.


#8

I’d love to participate, but I only have access to MSP430 boards at the moment.


#9

Where are you based?


#10

Right, MSP430. So, rustc doesn’t have a built-in target for this architecture but LLVM does seem to support the MSP430 though I have no idea of what’s the state of the MSP430 backend.

I can mentor you in adding a msp430-*-* target to rustc during novemb.rs (or we could start right now) but consider that (a) this is not really embedded stuff but rather compiler hacking, (b) it’s tedious work (long compile/test cycles), © you may hit, early on, some LLVM blocker and (d) you need low level knowledge about the MSP430 (how the processor boots, where are the Flash/RAM memory regions, how to flash a program without/overriding the bootloader, etc). I’m not saying this to demotivate you but to let you know what would you be signing up for, if you decide to tackle this.


#11

I have 4 STM32F4DISCOVERY boards. Will those work?

I’ll probably bring them to the Mozilla SF office for these events (cc @Manishearth you may be in the office too)


#12

I will be, but I only have an old Pi.


#13

@jck

So, I got some of compiler hacking required to support the MSP430 done. PR #37672 has my work and it will probably land before novemb.rs but there’s still experimentation to do to be able to write a “blinky” program in Rust. Want to take it from there? I can’t push this forward anymore because I’m not actually familiar with MSP430 micros (i.e. I don’t even know how to flash a program into it).

@brson

I have 4 STM32F4DISCOVERY boards. Will those work?

Yes, all the DISCOVERY boards work.

I’ll probably bring them to the Mozilla SF office for these events

Any chance the Mozilla SF office could turn into a novemb.rs location? I know a person in the Bay area that will participate in the event and that has lots of Cortex-M based dev boards. Maybe they can meet you and @Manishearth at the Mozilla office and share some dev boards :wink:.


#14

I have some MSP430 launchpads too (from the $4.30 promotion way back when)! Can I help?


#15

Yes! I’ve opened an issue with details about what needs to be done next after the MSP430 PR lands. We can work on that during novemb.rs or if you can, we can work on it before novemb.rs, to get MSP430 support in a better shape for novemb.rs.


#16

This sounds really great, I’ll be logged in.


#17

I’m moderately familiar with MSP430 internals. I was able to get blink working a few months ago by getting rust to generate assembly and then compiling that using GCC.