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!