probe-rs: Making Embedded Development Feel Like Userspace Programming

Without proper tooling, embedded testing looks like this:

// Traditional approach - manual test runner
#![no_std]
#![no_main]

fn test_sensor_reading() {
    // Test code here
    // Results communicated via LEDs or UART
}

fn test_motor_control() {
    // Another test
    // No isolation between tests
}

#[entry]
fn main() -> ! {
    // Manually call each test
    test_sensor_reading();
    test_motor_control();
    // Hope nothing interferes between tests
    loop {}
}

This approach has numerous problems:

• No isolation between tests
• Manual test orchestration
• Difficult result reporting
• No support for test attributes like #[should_panic] or #[ignore]
• Time-consuming manual process for each test run

With embedded-test and probe-rs, the same tests become:

#![no_std]
#![no_main]

#[cfg(test)]
#[embedded_test::tests]
mod tests {
    use stm32f7xx_hal::pac::Peripherals;

    // Optional init function called before each test
    #[init]
    fn init() -> Peripherals {
        Peripherals::take().unwrap()
    }

    // Tests receive the state from init
    #[test]
    fn test_sensor_reading(peripherals: Peripherals) {
        let sensor = setup_sensor(&peripherals);
        let reading = sensor.read();
        assert!(reading > 0);
    }

    #[test]
    #[should_panic]
    fn test_invalid_config(peripherals: Peripherals) {
        // This test expects a panic
        configure_invalid_setting(&peripherals);
    }

    #[test]
    #[ignore]
    fn test_long_running_operation(peripherals: Peripherals) {
        // Skipped by default, run with --ignored
        perform_calibration(&peripherals);
    }

    #[test]
    #[timeout(10)]
    fn test_with_timeout(peripherals: Peripherals) {
        // Fails if takes longer than 10 seconds
        quick_operation(&peripherals);
    }
}

Running these tests is identical to any Rust project:

# Run all tests
cargo test

# Run specific test
cargo test test_sensor_reading

# Run ignored tests
cargo test -- --ignored

# Filter tests by name
cargo test sensor

The embedded-test framework provides sophisticated test orchestration through probe-rs:

1. Single Flash: All tests are compiled into one binary and flashed once
2. Test Discovery: probe-rs queries the device for available tests via semihosting

3. Individual Execution: For each test:

   • Device is reset to ensure clean state
   • Specific test is selected via semihosting commands
   • Test runs with optional timeout
   • Results reported back via semihosting
4. Result Aggregation: All results collected and presented in familiar cargo test format

This approach provides true test isolation - each test runs on a freshly reset device with clean hardware state, eliminating issues with shared global state or hardware configuration conflicts.

embedded-test supports sophisticated testing patterns:

#[embedded_test::tests]
mod advanced_tests {
    // Async tests (with embassy feature)
    #[test]
    async fn test_async_operation() {
        let result = async_sensor_read().await;
        assert_eq!(result, 42);
    }

    // Tests that return Results for better error reporting
    #[test]
    fn test_with_error_context() -> Result<(), &'static str> {
        let config = load_config()
            .ok_or("Failed to load configuration")?;
        
        validate_config(&config)
            .ok_or("Configuration validation failed")?;
            
        Ok(())
    }

    // Conditional compilation of tests
    #[test]
    #[cfg(feature = "debug-mode")]
    fn test_debug_features() {
        // Only compiled when debug-mode feature is enabled
    }
}

Since embedded-test is libtest compatible, it integrates seamlessly with development environments:

• VSCode: Click the "Run Test" button next to any test function
• IntelliJ/CLion: Individual test execution through the gutter icons
• Command Line: Standard cargo test filtering and options work identically

This integration means embedded developers get the same productive testing workflow as userspace developers, with instant feedback and easy test isolation.

The combination of probe-rs and embedded-test transforms embedded testing from a manual, error-prone process into an automated, reliable development practice that feels exactly like testing any other Rust code.

The remote server functionality requires enabling the `remote` feature during compilation:

cargo install probe-rs-tools --features remote

This feature is currently behind a feature flag as it adds additional dependencies for the web server and RPC functionality.

Setting up the remote server requires creating a configuration file at `~/.probe-rs.toml` that defines user tokens:

[[server.users]]
name = "alice"
token = "alice-secret-token"

[[server.users]]
name = "bob"
token = "bob-different-token"

The authentication system uses a challenge-response mechanism where the server generates a random string, and the client must hash it with their token. This prevents tokens from being transmitted in plaintext while keeping the implementation simple.

Start the server with:

probe-rs serve

This starts both the RPC server and a web interface at `http://localhost:3000` that shows connected probes and basic status information.

Once the server is running, clients can connect from anywhere on the network:

# Flash firmware to remote hardware
cargo run --host ws://localhost:3000 --token alice-secret-token

# List remote probes
probe-rs list --host ws://localhost:3000 --token alice-secret-token

# Get chip information from remote target
probe-rs chip --host ws://localhost:3000 --token alice-secret-token

The remote functionality currently supports most probe-rs commands including:

• info - Discover and identify connected devices
• list - Show available debug probes
• download - Flash binaries to targets
• run - Flash and execute programs with RTT output
• attach - Connect to running targets
• read/write - Memory operations
• reset - Target reset operations
• erase - Flash memory erasure
• verify - Verify flash contents

From the developer's perspective, using remote hardware is nearly transparent. The same cargo run command that works locally will work with remote hardware by simply adding the host and token parameters. RTT output, error messages, and progress indicators all function identically whether the hardware is local or remote.

This approach provides several advantages over traditional solutions:

• No SSH required: Users don't need shell access to the hardware server
• Fine-grained access control: Tokens can be per-user and easily revoked
• Web monitoring: The built-in web interface provides visibility into hardware usage
• Native integration: No need for VPNs or complex network configuration

The remote server represents probe-rs's philosophy of making embedded development as friction-free as possible, extending that philosophy to distributed development scenarios.