See also the MCU docs
This crate re-export a entry
attribute macro to apply to the main
function, and a init()
function that should be called before creating the Slint UI.
In order to use this backend, the final program must depend on both slint
and mcu-board-support
.
The main.rs will look something like this
#![no_std]
#![cfg_attr(not(feature = "simulator"), no_main)]
slint::include_modules!();
#[mcu_board_support::entry]
fn main() -> ! {
mcu_board_support::init();
MainWindow::new().run();
panic!("The event loop should not return");
}
Since mcu-board-support is at the moment an internal crate not uploaded to crates.io, you must use the git version of slint, slint-build, and mcu-board-support
[dependencies]
slint = { git = "https://github.com/slint-ui/slint", default-features = false }
mcu-board-support = { git = "https://github.com/slint-ui/slint" }
# ...
[build-dependencies]
slint-build = { git = "https://github.com/slint-ui/slint" }
In your build.rs, you must include a call to slint_build::print_rustc_flags().unwrap()
to set some of the flags.
cargo run -p printerdemo_mcu --features=simulator --release
You need nightly rust because that's the only way to get an allocator.
Build the demo with:
cargo +nightly build -p printerdemo_mcu --no-default-features --features=mcu-board-support/pico-st7789 --target=thumbv6m-none-eabi --release
The resulting file can be flashed conveniently with elf2uf2-rs. Install it using cargo install
:
cargo install elf2uf2-rs
Then upload the demo to the Raspberry Pi Pico: push the "bootsel" white button on the device while connecting the micro-usb cable to the device, this connect some storage where you can store the binary.
Or from the command on linux: (connect the device while pressing the "bootsel" button.
# If you're on Linux: mount the device
udisksctl mount -b /dev/sda1
# upload
elf2uf2-rs -d target/thumbv6m-none-eabi/release/printerdemo_mcu
This require probe-run (cargo install probe-run
)
and to connect the pico via a probe (for example another pico running the probe)
Then you can simply run with cargo run
CARGO_TARGET_THUMBV6M_NONE_EABI_LINKER="flip-link" CARGO_TARGET_THUMBV6M_NONE_EABI_RUNNER="probe-run --chip RP2040" cargo +nightly run -p printerdemo_mcu --no-default-features --features=mcu-board-support/pico-st7789 --target=thumbv6m-none-eabi --release
Install probe-rs-debugger
and the VSCode plugin as described here.
Add this build task to your .vscode/tasks.json
:
{
"version": "2.0.0",
"tasks": [
{
"type": "cargo",
"command": "build",
"env": {
"RUSTUP_TOOLCHAIN": "nightly"
},
"args": [
"--package=printerdemo_mcu",
"--features=mcu-pico-st7789",
"--target=thumbv6m-none-eabi",
"--profile=release-with-debug"
],
"problemMatcher": [
"$rustc"
],
"group": "build",
"label": "build mcu demo for pico"
},
]
}
The release-with-debug
profile is needed, because the debug build does not fit into flash.
You can define it like this in your top level Cargo.toml
:
[profile.release-with-debug]
inherits = "release"
debug = true
Now you can add the launch configuration to .vscode/launch.json
:
{
"version": "0.2.0",
"configurations": [
{
"preLaunchTask": "build mcu demo for pico",
"type": "probe-rs-debug",
"request": "launch",
"name": "Flash and Debug MCU Demo",
"cwd": "${workspaceFolder}",
"connectUnderReset": false,
"chip": "RP2040",
"flashingConfig": {
"flashingEnabled": true,
"resetAfterFlashing": true,
"haltAfterReset": true
},
"coreConfigs": [
{
"coreIndex": 0,
"rttEnabled": true,
"programBinary": "./target/thumbv6m-none-eabi/release-with-debug/printerdemo_mcu"
}
]
},
]
}
This was tested using a second Raspberry Pi Pico programmed as a probe with DapperMime.
Using probe-run (cargo install probe-run
)
CARGO_TARGET_THUMBV7EM_NONE_EABIHF_RUNNER="probe-run --chip STM32H735IGKx" cargo +nightly run -p printerdemo_mcu --no-default-features --features=mcu-board-support/stm32h735g --target=thumbv7em-none-eabihf --release
- ESP Rust Toolchain: https://esp-rs.github.io/book/installation/installation.html
espflash
: Install viacargo install espflash
.
When flashing, with esplash
, you will be prompted to select a USB port. If this port is always the same, then you can also pass it as a parameter on the command line to avoid the prompt. For example if
/dev/ttyUSB1
is the device file for your port, the command line changes to espflash --monitor /dev/ttyUSB1 path/to/binary/to/flash_and_monitor
.
To compile and run the demo:
cargo +esp build -p printerdemo_mcu --target xtensa-esp32s2-none-elf --no-default-features --features=mcu-board-support/esp32-s2-kaluga-1 --release --config examples/mcu-board-support/esp32_s2_kaluga_1/cargo-config.toml
espflash --monitor target/xtensa-esp32s2-none-elf/release/printerdemo_mcu
The device needs to be connected with the two USB cables (one for power, one for data)
To compile and run the demo:
cargo +esp build -p printerdemo_mcu --target xtensa-esp32s3-none-elf --no-default-features --features=mcu-board-support/esp32-s3-box --release --config examples/mcu-board-support/esp32_s3_box/cargo-config.toml
espflash --monitor target/xtensa-esp32s3-none-elf/release/printerdemo_mcu