Introduction to Embedded Rust

Welcome to the world of Embedded Rust! This lesson will kickstart your journey into programming microcontrollers and other resource-constrained devices with Rust.

We'll explore why Rust is a fantastic choice for embedded systems and what makes this domain unique compared to traditional desktop or web development.

When you program for embedded systems, you're often working without an operating system. This means you interact directly with the hardware.

• No OS: No Linux, Windows, or macOS.
• Resource Constraints: Limited memory (RAM) and storage (Flash).
• Direct Hardware: You control peripherals like GPIOs, timers, and communication interfaces directly.

Getting started requires a slightly different setup than standard Rust. You'll typically use rustup to install specific components:

• Target Support: For example, rust-std-arm-none-eabi for ARM Cortex-M microcontrollers.
• cargo-generate: A tool to create new projects from templates, common for embedded setups.
• Debugging Tools: Like probe-rs for flashing and debugging your device.

Embedded development often involves cross-compilation. This means compiling your code on one type of computer (e.g., your laptop's x86 CPU) to run on another (e.g., an ARM Cortex-M microcontroller).

Rust uses target triples (e.g., thumbv7em-none-eabihf) to specify the architecture, vendor, OS (or lack thereof), and ABI of the target device.

You'll encounter various microcontrollers (MCUs) in embedded Rust. Popular choices include:

• STM32 series: Versatile and widely used in industry.
• ESP32: Known for Wi-Fi and Bluetooth capabilities.
• nRF52 series: Excellent for Bluetooth Low Energy (BLE) applications.

These boards provide the physical hardware for your Rust code to run on.

Bare-metal programming means your code runs directly on the hardware, with no underlying operating system managing resources or providing abstractions.

You are responsible for everything: initializing memory, setting up the clock, configuring peripherals, and handling interrupts. It's low-level, but gives you complete control.

An embedded Rust program looks different from a standard one. Here's a basic structure:

• #![no_std]: Don't link the standard library.
• #![no_main]: Don't use the default main entry point.
• #[cortex_m_rt::entry]: Specifies the actual entry point for Cortex-M devices.

This minimal program would compile for an embedded target, but requires a panic handler and a runtime crate.

Since there's no console to print to, the classic "Hello, World!" for embedded systems is typically blinking an LED.

This simple act demonstrates that you have successfully:

• Compiled your code for the target.
• Flashed it onto the device.
• Gained control over a basic hardware peripheral (a General Purpose Input/Output pin).

In bare-metal programming, you need to understand how your program's compiled code and data are arranged in the microcontroller's memory.

Linker scripts (often provided by board support packages) define this memory layout, specifying where different sections of your program (e.g., code, static data, heap, stack) reside in the device's Flash (read-only) and RAM (read-write) memory.

Let's check your understanding of Embedded Rust fundamentals.

In this lesson, we introduced Embedded Rust, highlighting its unique challenges like bare-metal programming and cross-compilation. We covered the essential toolchain components, common development boards, and the fundamental structure of a no_std program.

You also learned that blinking an LED is the embedded equivalent of "Hello, World!" and got a glimpse into linker scripts. You're now ready to delve deeper into writing code for the real world!