std-training: embedded Rust on the Espressif ESP32-C3

A course for the ESP32-C3, published as a book you can read online

std-training holds training material for learning to use embedded Rust with the Espressif ESP32-C3, and the readme tells you how to start: read the book.

The book exists in two forms, the Markdown source in the book directory of the repository and the rendered version published at esp-rs.github.io/std-training. It is the central artefact, and the examples sit around it rather than replacing it.

The microcontroller is a specific one. It is a specific part from Espressif, and the choice matters for a course, because the examples that run on it are examples of a real target with real peripherals rather than a generic embedded target. The content was created by Ferrous Systems GmbH and Espressif Systems, and the project home page points at the published book.

The repository layout matches the course structure. There is a book directory, an intro directory for the first examples, an advanced directory for the later ones and a common directory for the shared crates, plus a.devcontainer directory for a reproducible development environment. Every commit to the main branch is published to the site automatically, and the readme says plainly that this work is continually updated and as such there are no releases.

The introductory examples start by proving the board works

The first set of examples is where a beginner is supposed to get confidence, and the selection explains the philosophy.

The first is a basic hardware check, which is the traditional first program in embedded and the one that tells you whether your flashing setup, your toolchain and your board are alive before you write anything interesting. It comes first for a reason.

Then come two HTTP examples, a client and a server. Putting both in the introductory set says something about the target of the course: a microcontroller that can serve HTTP and speak it as a client is the shape of the connected device most people want to build, and a network stack on a microcontroller is exactly where the interesting configuration lives, so the examples deal with it early rather than late.

An MQTT client completes the introductory set, which gives the course three network protocols at the beginner level, HTTP in both directions and MQTT as a client. That is a lot of connectivity for a first pass, and it is a deliberate choice for a course aimed at connected embedded devices rather than at bare metal fundamentals.

All four are separate crates with their own source, and each one is built in the usual way, so a reader can compile, flash and run them individually rather than assembling a single large program.

The advanced examples go down to pins, interrupts and buses

The second group changes level, and the topics are the ones that separate a toy from a working device.

There is low-level GPIO, which is direct pin control rather than the abstracted helpers, and interrupts in general, which covers the mechanism rather than a single device. Then two I2C examples, an I2C driver and an I2C sensor reading, which is the right pair to have next to each other because the first is the bus and the second is a device on it.

A GPIO and button interrupt example follows, and then driving an RGB LED.

The RGB LED example is the one that quietly needs the most, because an addressable LED such as the WS2812 is not a simple output. It has its own timing protocol, and the helper crate for it appears in the common directory, which means the course teaches the abstraction before it teaches the fiddly part. The button interrupt example is the counterpart, and the pairing with the low-level GPIO work is what makes the interrupt material concrete.

Taken together, the advanced set covers the four things an embedded developer touches first, digital output, digital input with interrupts, a serial bus, and a device that needs precise timing. The readme lists the sources for the I2C driver, the I2C sensor reading and the button interrupt example, so those three can be read directly, while the low-level GPIO, the general interrupts and the RGB LED entries are named without a link in the part of the readme quoted here.

Four helper crates carry the code the examples would otherwise repeat

The common directory holds the crates that the examples share, and looking at them explains a lot about how the course is structured.

get-uuid provides a compile-time generated UUID. That is an interesting choice for an embedded target, because generating a UUID at build time removes a runtime cost and a source of nondeterminism, and it means an example that needs an identifier does not have to teach randomness first.

mqtt-messages holds MQTT helper functions, so the MQTT client example is about connecting and publishing rather than about assembling packets by hand.

rgb-led provides support for the RGB LED, specifically the WS2812, and as noted above it carries the timing protocol so that both the introductory and the advanced material can treat the LED as a device rather than as a timing exercise.

wifi holds the wifi helper functions, which is the fourth of the pieces that every network example needs and that no beginner wants to write twice.

That division is the pedagogically interesting part. The course can afford to put the tedious parts in a shared crate, because the crate is part of the same repository and can be read, modified and reused, so a learner who wants to know what is under a helper can go and read it in one place. It also means the examples are short, and short examples are the ones people actually build.

The book is mdbook, and a local server is one command away

The book is written in Markdown and rendered with mdbook, and the readme gives the local loop in full:

~ $ cargo install mdbook
~ $ git clone https://github.com/esp-rs/std-training.git
~ $ cd std-training/book
~/std-training/book $ mdbook serve

The result is a local web server on http://127.0.0.1:3000 that renders the book and updates automatically as you modify the Markdown pages on disk. That last point is what makes this a working method rather than a reading exercise, because a learner can correct a page, add a note or write their own chapter and see it immediately in the rendered output.

For the examples themselves, the readme points to the Embedded Rust Bookshelf for general details on building embedded Rust, and to the readme file of each individual crate for the specifics. That two-level documentation is a deliberate choice, since the bookshelf covers the shared mechanics of building and flashing and the crate readme covers the one project at hand.

There is also a devcontainer directory, which means a learner who does not want to install the whole embedded toolchain by hand can work inside a prepared container. The continuous integration badge points at a ci.yml workflow, so the examples are built by the project's own pipeline rather than only on individual laptops.

Two licences for the content and the code, and no releases at all

The licensing is unusual and deserves understanding before you reuse any of it.

The written content is licensed under Creative Commons Attribution-ShareAlike 4.0, with all of it Copyright 2022 Ferrous Systems GmbH unless otherwise stated, and the readme states the obligation plainly: you are free to share and adapt but you must give attribution and share alike. The licence field on the repository says Apache-2.0, which covers the repository as a whole, while the readme splits it in two.

The code is the second layer. The source code in the repository, whether it is inside the book or in the separate examples, is available under either the MIT licence or Apache 2.0 at your option, with the two licence files in the root of the repository. So a reader can take the code into a proprietary project under MIT, while a chapter of the book that they adapt has to be republished under the same terms.

Contributions are handled the same way, with anything submitted for inclusion licensed as above unless stated otherwise, in the terms of the Apache 2.0 definition of a contribution.

The publishing model completes the picture. There are no releases, every commit to main goes live on the site automatically, and contributors are told not to push to main but to work in a branch, in the repository or in a fork, and to open a pull request. The code of conduct is the Rust one, and the readme says the maintainers promise to intervene to uphold it. The last push to the repository was on 2026-06-22.

Editorial conclusion

std-training fits a developer moving from desktop Rust to a microcontroller who wants a path that ends in running firmware rather than in reading about timers, because every chapter is paired with a crate you can build and flash and the peripheral work is split into examples small enough to read in one sitting. It is the wrong choice if you need a reference manual rather than a course, since it is organised as a learning path with a book rather than as a set of documented APIs, and it is the wrong choice if you want tagged releases, because there are none and the site is rebuilt from every commit to main. Before you start, install mdbook and render the book locally so you can edit the Markdown as you learn, and read the licence section carefully, because the written content is share-alike while the code in the examples is offered under either MIT or Apache 2.0 at your option.

Frequently asked questions

Official sources

1. esp-rs/std-training on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README