esp-rs / esp-template Goto Github PK

As suggested by @georgik, when using devcontainers we could add the Wokwi extension and include the necessary files (wokwi.toml and diagram.json) to allow user simulating the project with no extra work needed

I have generated a esp32 project with the esp32s3 model.

peter:/media/peter/data/code$ cargo generate esp-rs/esp-template ⚠️ Favoriteesp-rs/esp-templatenot found in config, using it as a git repository: https://github.com/esp-rs/esp-template.git 🤷 Project Name: esp32s3-rust-test 🔧 Destination: /media/peter/data/code/esp32s3-rust-test ... 🔧 project-name: esp32s3-rust-test ... 🔧 Generating template ... ✔ 🤷 Configure advanced template options? · false ✔ 🤷 Which MCU to target? · esp32s3 🔧 Moving generated files into:/media/peter/data/code/esp32s3-rust-test... Initializing a fresh Git repository ✨ Done! New project created /media/peter/data/code/esp32s3-rust-test

When i try to build it it fails:

peter:/media/peter/data/code/esp32s3-rust-test$ cargo build Updating crates.io index Compiling compiler_builtins v0.1.92 Compiling core v0.0.0 (/home/peter/.rustup/toolchains/esp/lib/rustlib/src/rust/library/core) Compiling proc-macro2 v1.0.66 Compiling unicode-ident v1.0.11 Compiling syn v1.0.109 Compiling serde v1.0.183 Compiling memchr v2.5.0 Compiling rustversion v1.0.14 Compiling serde_derive v1.0.183 Compiling heck v0.4.1 Compiling version_check v0.9.4 Compiling autocfg v1.1.0 Compiling anyhow v1.0.72 Compiling quote v1.0.32 Compiling aho-corasick v1.0.2 Compiling regex-syntax v0.7.4 Compiling lock_api v0.4.10 Compiling xtensa-lx v0.8.0 Compiling syn v2.0.28 Compiling proc-macro-error-attr v1.0.4 Compiling strsim v0.10.0 Compiling fnv v1.0.7 Compiling hashbrown v0.14.0 Compiling strum v0.24.1 Compiling ident_case v1.0.1 Compiling equivalent v1.0.1 Compiling proc-macro-error v1.0.4 Compiling indexmap v2.0.0 Compiling toml_datetime v0.6.3 Compiling regex-automata v0.3.6 Compiling winnow v0.5.4 Compiling minijinja v0.15.0 Compiling basic-toml v0.1.4 Compiling regex v1.9.3 Compiling darling_core v0.20.3 Compiling toml_edit v0.19.14 Compiling paste v1.0.14 Compiling esp-synopsys-usb-otg v0.3.2 Compiling log v0.4.18 Compiling esp32s3 v0.19.0 Compiling once_cell v1.18.0 Compiling proc-macro-crate v1.3.1 error[E0463]: can't find crate for unicode_identwhichproc_macro2` depends on
--> /home/peter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro-error-1.0.4/src/lib.rs:495:5
|
495 | pub extern crate proc_macro2;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for proc_macro2
--> /home/peter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro-error-1.0.4/src/lib.rs:497:9
|
497 | use proc_macro2::Span;
| ^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for proc_macro2
--> /home/peter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro-error-1.0.4/src/lib.rs:286:5
|
286 | use proc_macro2::Span;
| ^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for quote
--> /home/peter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro-error-1.0.4/src/lib.rs:287:5
|
287 | use quote::{quote, ToTokens};
| ^^^^^ can't find crate

error[E0463]: can't find crate for proc_macro2
--> /home/peter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro-error-1.0.4/src/dummy.rs:116:5
|
116 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for proc_macro2
--> /home/peter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro-error-1.0.4/src/diagnostic.rs:2:5
|
2 | use proc_macro2::Span;
| ^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for proc_macro2
--> /home/peter/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro-error-1.0.4/src/diagnostic.rs:3:5
|
3 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for quote
`

It works fine if I try to generate and build for the C3 model

Hi there,
When generating a project I'm getting the following errors in VSCode from rust-analyzer:

I couldn't find a solution to make them go away, is this supposed to be the case or am I missing something there?

I installed the toolchain via espup and also tried a bunch of settings in .vscode/settings.json, like:

{
    "rust-analyzer.server.extraEnv": { "RUSTUP_TOOLCHAIN": "esp"},
    "rust-analyzer.cargo.target": "xtensa-esp32-none-elf",
    "rust-analyzer.checkOnSave": false,
    "rust-analyzer.check.allTargets": false,
    "rust-analyzer.check.overrideCommand": [
        "cargo",
        "clippy",
        "--message-format=json",
        "--bins",
        "--all-features",
        "--target",
        "xtensa-esp32-none-elf",
    ],
    "rust-analyzer.check.targets": "xtensa-esp32-none-elf",
}

Currently, we have 0.14.0 as minimum version and some users in Matrix reported having issues with 0.16.0

Current questions: Use template default values? true/false

The question not provide insight into what is the user selecting.

Recommended change: Use minimalist project profile? yes/no
In case of no, continue with configuration options.

Why is the "default" question not good? Because "default" can mean something else to different people. Default in my case would mean full-blown project with all the bells and whistles, so that I can easily integrate it with all the things used by app developers including CI with containers, Simulation and Debugging.

Hi,

This may be self-evident, and if it is I apologise. It appears that one cannot use cargo test using a fresh cargo generated project based on this template:

$ cargo generate --git https://github.com/esp-rs/esp-template
[...]
🔧   Generating template ...
✔ 🤷   Enable allocations via the esp-alloc crate? · true
✔ 🤷   Which MCU to target? · esp32
✔ 🤷   Configure project to use Dev Containers (VS Code, GitHub Codespaces and Gitpod)? · false
[...]
$ cd foo
$ cargo test
[...]
   Compiling foo v0.1.0 (/Users/slau/src/unticks/foo)
error[E0463]: can't find crate for `test`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `foo` due to previous error

Not sure if this is expected, intended, or unfixable.

I've started a project based on generating from this template, and setting up CI would be made easier if the generated files included some CI. This is what I've put together for my project:

name: check

on:
  pull_request:
    branches:
      - main


jobs:
  lint:
    name: Lint
    runs-on: ubuntu-22.04
    env:
      CARGO_TERM_COLOR: always

    steps:
      - uses: actions/checkout@v3
      - uses: esp-rs/[email protected]
      - uses: Swatinem/rust-cache@v2

      - name: check rustfmt
        run: cargo fmt -- --check --color always

      - name: clippy
        run: cargo clippy -- -D warnings

the steps were partially based on the CI files for this repo.

If there's a way to bring in the right toolchain in a way that is nice and quick, and only sets things up for the appropriate platform (I'm using S3, but I notice work is being done to setup for non S3 platforms), that would probably be ideal.

Hi,
I'm trying to build a library (no_std) for the ESP32-S2 (thus no IC crates needed, just architecture needed) using:
cargo +esp build --target esp32s2-none-elf --release

However, I get the following mistake.. How can I avoid it:

error[E0463]: can't find crate for `core`
  |
  = note: the `xtensa-esp32s2-none-elf` target may not be installed
  = help: consider downloading the target with `rustup target add xtensa-esp32s2-none-elf`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

Dear all,

I'm trying to build a hello world project derived from this template on Windows 10 in a MSVC environment.
It was set up the following way:

1. Install rustup-msvc via scoop
2. Install microsoft command line compiler (like the scoop package suggested)
3. Install nightly rust via rustup
4. Install espup and cargo-generate via cargo
5. Run espup install according to documentation

After that I generated the project for esp32 via this git repo

cargo build compiles everything but linking fails with:

C:\Users\Olaf\scoop\persist\rustup-msvc\.rustup\toolchains\esp\xtensa-esp-elf\esp-13.2.0_20230928\xtensa-esp-elf\bin/xtensa-esp-elf-ld.exe: 
          cannot open linker script file linkall.x: No such file or directory
          collect2.exe: error: ld returned 1 exit status

EDIT: It would appear that there is a linkall.x in cargo's crate registry below esp32-hal-0.16.0/ld/.
But that folder is not among the linker search directories.

Any idea what might be wrong here or any pointers how to debug this?

Thanks a lot,
Olaf

Hi, I'm trying to use cargo generate, but it throw this error:

cargo generate https://github.com/esp-rs/esp-template          
error: Found argument 'https://github.com/esp-rs/esp-template' which wasn't expected, or isn't valid in this context

USAGE:
    cargo generate [FLAGS] [OPTIONS] --git <git>

For more information try --help

when I use --git:

cargo generate --git=https://github.com/esp-rs/esp-template
 Project Name: test-esp8266
 Creating project called `test-esp8266`...
Error:  Git Error: failed to clone into: /home/samuel/Downloads/test-esp8266IXEFXF

Have I did something wrong ?

why there is no esp8266 template ?

We should briefly describe each prompt, its options, and why you may or may not want to use any given feature.

@SergioGasquez maybe if you had some time (this is low priority) you could look into this? If not I can do it at some point. If you're interested please just assign yourself to the issue!

The CI is pretty slow and there is no benefit from running the docker-checks for PRs. One possible solution would be to move it to a separate yaml file and run the docker-checks only for PRs/push that modify anything related to containers or in scheduled runs.

https://github.com/MabezDev/xtensa-atomic-emulation-trap

Hi, any way I can use env var in config.toml?

linker = "/home/ci/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc"

and I have export CROSS_CIMPILE=/home/ci/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-

I tryied linker = "${CROSS_COMPILE}gcc" but didn't work? Any adea about how to fix it?

Example run: https://github.com/bugadani/esp32s3-defmt-example/actions/runs/6576956219

I had my hands on a ESP32-Pico-Kit lately. I wanted to develop no_std apps on it. I am using Visual Studio Code with the rust-analyzer extension.

Firstly, auto completion is basically unusable. For example, peripherals.DPORT.split(), I would get nothing after I typed peripherals.DPORT. and hovering also doesn't show anything. I was wondering if it has anything to do with proc macro expansion (see below).

Secondly, rust-analyzer also pops an error stating that the #[entry] macro cannot be expanded. At first, it is rust-analyzer-proc-macro-srv not found, so I compiled one myself using esp-rs's toolchain (to eliminate any issues caused by incompatible toolchain versions). Then it show unsupported ABI: ..., I then "solved" it by compiling proc-macro-srv-cli with the sysroot-abi feature enabled (although I'm not so sure if this is really the solution). However, I notice that recent Rust toolchains ship with a rust-analyzer-proc-macro-srv to solve the ABI issue when the rust-analyzer client itself is not built under the same version of toolchain, maybe I should file an issue over esp-rs/rust?

Even after there is no errors or whatsoever, auto completion and most language features are basically unusable.

I want to know if this is a common experience or not. I tried my best to solve it myself but I am basically stuck now...

After following the instructions for setting up the environment, I created a new project from this template.
Without modifying anything, I got the following error:``
error: linker xtensa-esp32-elf-gcc not found
|
= note: No such file or directory (os error 2)

error: could not compile no_std_project_template (bin "no_std_project_template") due to previous error``
I am trying to build this for the Adafruit ESP32 Feather which uses a 240 MHz dual core Tensilica LX6 microcontroller with 600 DMIPS.
Which according to cargo espflash board-info is an "esp32 (revision v3.0)".
How could I fix this?
There is an Arch package for the required linker, but I want to make sure it won't come with a future update with espup.

https://github.com/esp-rs/esp-template/blob/main/scripts/flash.sh#L21 can be replaced by rust_target value of https://github.com/esp-rs/esp-template/blob/main/pre-script.rhai

I tried to generate a new project according to the README but it fails:

$ cargo generate -a esp-rs/esp-template
⚠️   Favorite `esp-rs/esp-template` not found in config, using it as a git repository: https://github.com/esp-rs/esp-template.git
🤷   Project Name: no_std_test
⚠️   Renaming project called `no_std_test` to `no-std-test`...
🔧   Destination: /home/user/no-std-test ...
🔧   project-name: no-std-test ...
🔧   Generating template ...
✔ 🤷   Which MCU to target? · esp32
✔ 🤷   Enable allocations via the esp-alloc crate? · true
✔ 🤷   Configure project to use Dev Containers (VS Code, GitHub Codespaces and Gitpod)? · true
[ 1/27]   Done: .cargo/config.toml                                                                                                                                
[ 2/27]   Done: .cargo                                                                                                                                            
[ 3/27]   Done: .devcontainer/Dockerfile                                                                                                                          
[ 4/27]   Done: .devcontainer/devcontainer.json                                                                                                                   
[ 5/27]   Done: .devcontainer                                                                                                                                     
[ 6/27]   Done: .dockerignore                                                                                                                                     
[ 7/27]   Done: .gitignore                                                                                                                                        
[ 8/27]   Done: .gitpod.Dockerfile                                                                                                                                
[ 9/27]   Done: .gitpod.yml                                                                                                                                       
[10/27]   Done: .vscode/launch.json                                                                                                                               
[11/27]   Done: .vscode/settings.json                                                                                                                             
[12/27]   Done: .vscode/tasks.json                                                                                                                                
[13/27]   Done: .vscode                                                                                                                                           
[14/27]   Done: Cargo.toml                                                                                                                                        
[15/27]   Done: LICENSE-APACHE                                                                                                                                    
[16/27]   Done: LICENSE-MIT                                                                                                                                       
[17/27]   Done: docs/README.md                                                                                                                                    
[18/27]   Done: docs                                                                                                                                              
[19/27]   Ignored: post-script.rhai                                                                                                                               
[20/27]   Ignored: pre-script.rhai                                                                                                                                
[21/27]   Done: rust-toolchain.toml                                                                                                                               
[22/27]   Done: scripts/build.sh                                                                                                                                  
[23/27]   Done: scripts/flash.sh                                                                                                                                  
[24/27]   Done: scripts/run-wokwi.sh                                                                                                                              
[25/27]   Done: scripts                                                                                                                                           
[26/27]   Done: src/main.rs                                                                                                                                       
[27/27]   Done: src                                                                                                                                               
Error: ⛔   Failed executing script: post-script.rhai

Caused by:
    Runtime error: System command `cargo fmt` returned non-zero status: exit status: 1

Rust version:

$ cargo --version
cargo 1.70.0-nightly (7d3033d2e 2023-03-08)
$ rustc --version
rustc 1.70.0-nightly (7b4f48927 2023-03-12)
$ rustup --version
rustup 1.25.2 (17db695f1 2023-02-01)

When I cargo run this template, it successfully uploads the image but the chip fails to boot up.

~/devel/turingatemyhamster/scratch/cam32-baremetal-blink$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `espflash --monitor target/xtensa-esp32-none-elf/debug/cam32_baremetal_blink`
New version of espflash is available: v2.0.0-rc.3

Serial port: /dev/ttyUSB0
Connecting...

Chip type:         ESP32 (revision 3)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, Coding Scheme None
MAC address:       c8:f0:9e:4d:4c:34
App/part. size:    150224/4128768 bytes, 3.64%
[00:00:01] ########################################      16/16      segment 0x1000                                  [00:00:00] ########################################       1/1       segment 0x8000                                  [00:00:05] ########################################      55/55      segment 0x10000                                 
Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0048,len:12
ho 0 tail 12 room 4
load:0x3fff0054,len:4800
load:0x40078000,len:17448
0x40078000 - ets_delay_us
    at ??:??
load:0x4007c428,len:4840
0x4007c428 - ets_delay_us
    at ??:??
entry 0x4007c6a0
0x4007c6a0 - ets_delay_us
    at ??:??
ets Jul 29 2019 12:21:46
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0048,len:12
ho 0 tail 12 room 4
load:0x3fff0054,len:4800
load:0x40078000,len:17448
0x40078000 - ets_delay_us
    at ??:??
load:0x4007c428,len:4840
0x4007c428 - ets_delay_us
    at ??:??
entry 0x4007c6a0
0x4007c6a0 - ets_delay_us
    at ??:??
<loops for ever>

The esp-idf-template project runs out of the box. The output is below for comparison.

~/devel/turingatemyhamster/scratch/cam32-idf-blink$ cargo run
    Finished dev [optimized + debuginfo] target(s) in 0.12s
     Running `espflash --monitor target/xtensa-esp32-espidf/debug/cam32-idf-blink`
New version of espflash is available: v2.0.0-rc.3

Serial port: /dev/ttyUSB0
Connecting...

Chip type:         ESP32 (revision 3)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, Coding Scheme None
MAC address:       c8:f0:9e:4d:4c:34
App/part. size:    449296/4128768 bytes, 10.88%
[00:00:01] ########################################      16/16      segment 0x1000                                  [00:00:00] ########################################       1/1       segment 0x8000                                  [00:00:23] ########################################     228/228     segment 0x10000                                 
Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0048,len:12
ho 0 tail 12 room 4
load:0x3fff0054,len:4800
load:0x40078000,len:17448
0x40078000 - __udivmoddi4                                                                                           
    at ??:??                                                                                                        
load:0x4007c428,len:4840
0x4007c428 - __udivmoddi4                                                                                           
    at ??:??                                                                                                        
entry 0x4007c6a0
0x4007c6a0 - __udivmoddi4                                                                                           
    at ??:??                                                                                                        
I (227) cpu_start: Pro cpu up.
I (227) cpu_start: Starting app cpu, entry point is 0x40081164
0x40081164 - call_start_cpu1                                                                                        
    at /home/nmrp3/devel/turingatemyhamster/scratch/cam32-idf-blink/.embuild/espressif/esp-idf/release-v4.4/components/esp_system/port/cpu_start.c:148                                                                                  
I (0) cpu_start: App cpu up.
I (241) cpu_start: Pro cpu start user code
I (241) cpu_start: cpu freq: 160000000
I (241) cpu_start: Application information:
I (246) cpu_start: Project name:     libespidf
I (251) cpu_start: App version:      1
I (255) cpu_start: Compile time:     Mar 13 2023 14:24:44
I (261) cpu_start: ELF file SHA256:  0000000000000000...
I (267) cpu_start: ESP-IDF:          fee50c2-dirty
I (273) cpu_start: Min chip rev:     v0.0
I (277) cpu_start: Max chip rev:     v3.99 
I (282) cpu_start: Chip rev:         v3.0
I (287) heap_init: Initializing. RAM available for dynamic allocation:
I (294) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (300) heap_init: At 3FFB23A8 len 0002DC58 (183 KiB): DRAM
I (306) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (313) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (319) heap_init: At 4008AB20 len 000154E0 (85 KiB): IRAM
I (327) spi_flash: detected chip: generic
I (330) spi_flash: flash io: dio
I (335) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Hello, world!

Got my hands on an ESP32-C6 and want to try rust on it. I am able to run the esp-idf examples (hello_world and blink) using idf.py to build and flash: I can see the hello world in my terminal or the del flash.

I'm having trouble running this template though.

I use cargo generate esp-rs/esp-template to generate a bare bone project:

❯ cargo generate esp-rs/esp-template
⚠️   Favorite `esp-rs/esp-template` not found in config, using it as a git repository: https://github.com/esp-rs/esp-template.git
🤷   Project Name: esp32-c6-hello-v5
🔧   Destination: esp32-c6-hello-v5 ...
🔧   project-name: esp32-c6-hello-v5 ...
🔧   Generating template ...
✔ 🤷   Which MCU to target? · esp32c6
✔ 🤷   Configure advanced template options? · true
✔ 🤷   Enable WiFi/Bluetooth/ESP-NOW via the esp-wifi crate? · false
✔ 🤷   Enable allocations via the esp-alloc crate? · false
✔ 🤷   Configure project to use Dev Containers (VS Code and GitHub Codespaces)? · false
✔ 🤷   Configure project to support Wokwi simulation with Wokwi VS Code extension? · false
✔ 🤷   Add CI files for GitHub Action? · false
✔ 🤷   Setup logging using the log crate? · false
🔧   Moving generated files into: `esp32-c6-hello-v5`...
🔧   Initializing a fresh Git repository
✨   Done! New project created esp32-c6-hello-v5

Building and flashing seems to succeed, but the monitoring hangs:

❯ cargo run -vv
[...]
     Running `CARGO=~/.rustup/toolchains/nightly-aarch64-apple-darwin/bin/cargo CARGO_MANIFEST_DIR=~/esp32-c6-hello-v4 CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=esp32-c6-hello-v4 CARGO_PKG_README='' CARGO_PKG_REPOSITORY='' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.1.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' DYLD_FALLBACK_LIBRARY_PATH='~/esp32-c6-hello-v4/target/riscv32imac-unknown-none-elf/debug/build/esp-hal-common-4b0655f184eabea1/out:~/esp32-c6-hello-v4/target/riscv32imac-unknown-none-elf/debug/build/esp-riscv-rt-2022adf018f321c1/out:~/esp32-c6-hello-v4/target/riscv32imac-unknown-none-elf/debug/build/esp32c6-32bf530043214f0b/out:~/esp32-c6-hello-v4/target/riscv32imac-unknown-none-elf/debug/build/esp32c6-hal-03646f514ebc9229/out:~/esp32-c6-hello-v4/target/riscv32imac-unknown-none-elf/debug/deps:~/esp32-c6-hello-v4/target/riscv32imac-unknown-none-elf/debug:~/.rustup/toolchains/nightly-aarch64-apple-darwin/lib:~/lib:/usr/local/lib:/usr/lib' espflash flash --monitor target/riscv32imac-unknown-none-elf/debug/esp32-c6-hello-v4`
[2023-11-08T00:20:25Z INFO ] Detected 8 serial ports
[2023-11-08T00:20:25Z INFO ] Ports which match a known common dev board are highlighted
[2023-11-08T00:20:25Z INFO ] Please select a port
[2023-11-08T00:20:26Z INFO ] Serial port: '/dev/cu.usbmodem101'
[2023-11-08T00:20:26Z INFO ] Connecting...
[2023-11-08T00:20:27Z INFO ] Using flash stub
Chip type:         esp32c6 (revision v0.0)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi 6, BT 5
MAC address:       40:4c:ca:45:0a:cc
App/part. size:    177,392/4,128,768 bytes, 4.30%
[00:00:00] [========================================]      13/13      0x0
[00:00:00] [========================================]       1/1       0x8000
[00:00:01] [========================================]      70/70      0x10000
[2023-11-08T00:20:28Z INFO ] Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x15 (USB_UART_HPSYS),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x408007fe
0x408007fe - software_reset_cpu
    at ??:??
SPIWP:0xee
mode:DIO, clock div:2
load:0x4086c410,len:0xd48
0x4086c410 - __global_pointer$
    at ??:??
load:0x4086e610,len:0x2d68
0x4086e610 - __global_pointer$
    at ??:??
load:0x40875720,len:0x1800
0x40875720 - __global_pointer$
    at ??:??
SHA-256 comparison failed:
Calculated: aff89878a96cbff57c66c38aa6d1a422b7785040b5efea582babef6c357427c2
Expected: 0af544a033ab3492852b8232c904c578d5f07c9d4a423a64473f060db374ab32
Attempting to boot anyway...
entry 0x4086c410
0x4086c410 - __global_pointer$
    at ??:??
I (41) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
I (42) boot: compile time Jun  7 2023 08:02:08
I (43) boot: chip revision: v0.0
I (46) boot.esp32c6: SPI Speed      : 40MHz
I (51) boot.esp32c6: SPI Mode       : DIO
I (56) boot.esp32c6: SPI Flash Size : 4MB
I (61) boot: Enabling RNG early entropy source...
I (66) boot: Partition Table:
I (70) boot: ## Label            Usage          Type ST Offset   Length
I (77) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (84) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (92) boot:  2 factory          factory app      00 00 00010000 003f0000
I (99) boot: End of partition table
I (103) esp_image: segment 0: paddr=00010020 vaddr=42000020 size=23e80h (147072) map
I (142) esp_image: segment 1: paddr=00033ea8 vaddr=40808000 size=00020h (    32) load
I (143) esp_image: segment 2: paddr=00033ed0 vaddr=42023ed0 size=06598h ( 26008) map
I (153) esp_image: segment 3: paddr=0003a470 vaddr=40808020 size=01058h (  4184) load
I (157) boot: Loaded app from partition at offset 0x10000
I (162) boot: Disabling RNG early entropy source...

There's no output after the last line, no hello world :(

The expanded template result in:

#![no_std]
#![no_main]

use esp_backtrace as _;
use esp_println::println;
use hal::{clock::ClockControl, peripherals::Peripherals, prelude::*, Delay};

#[entry]
fn main() -> ! {
    let peripherals = Peripherals::take();
    let system = peripherals.SYSTEM.split();

    let clocks = ClockControl::max(system.clock_control).freeze();
    let mut delay = Delay::new(&clocks);

    println!("Hello world!");
    loop {
        println!("Loop...");
        delay.delay_ms(500u32);
    }
}

with the .cargo/config.toml:

[target.riscv32imac-unknown-none-elf]
runner = "espflash flash --monitor"


[build]
rustflags = [
  "-C", "link-arg=-Tlinkall.x",

  # Required to obtain backtraces (e.g. when using the "esp-backtrace" crate.)
  # NOTE: May negatively impact performance of produced code
  "-C", "force-frame-pointers",
]

target = "riscv32imac-unknown-none-elf"

[unstable]
build-std = ["core"]

and Cargo.toml:

[package]
name = "esp32-c6-hello-v4"
version = "0.1.0"
authors = [""]
edition = "2021"
license = "MIT OR Apache-2.0"

[dependencies]
hal = { package = "esp32c6-hal", version = "0.6.0" }
esp-backtrace = { version = "0.9.0", features = ["esp32c6", "panic-handler", "exception-handler", "print-uart"] }
esp-println = { version = "0.7.0", features = ["esp32c6"] }

Something I realized is that the built binary is large (larger than the available flash?):

❯ ls target/riscv32imac-unknown-none-elf/debug/esp32-c6-hello-v5

I tried opt-level = "s" and opt-level = "z" and strip = true which does reduce the size but the same result happens: there's no hello world :(

Any idea what I could be doing wrong? I'm not sure what to look for as playing with embedded is quite new for me.

Thanks!!

C3 has very little memory. When people are porting applications or adding new crates they might run into memory problems.
Consider introducing DebugAssist to the template to simplify steps when porting application to C3.

Sample code: https://github.com/georgik/esp32-memory-limit/blob/main/examples/12-alloc-stack-overflow-protection.rs#L37

Board: https://cdn.openluat-luatcommunity.openluat.com/attachment/CORE-ESP32-C3%E8%AE%BE%E8%AE%A1%E5%8E%9F%E7%90%86%E5%9B%BE_V1.2.pdf

Toolchains installed by espup

project generated using cargo generate --git https://github.com/esp-rs/esp-template, target esp32c3.

Output:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xe (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x3ce00000,len:0x92840
load:0x50285e28,len:0xfeaa50a8
Invalid image block, can't boot.
ets_main.c 333 
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0xe (SPI_FAST_FLASH_BOOT)
Saved PC:0x40047ed2
0x40047ed2 - _stack_start
    at ??:??
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x3ce00000,len:0x92840
load:0x50285e28,len:0xfeaa50a8
Invalid image block, can't boot.
ets_main.c 333

This board using a micropython firmware with custom partition table previously:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x6000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  factory, 0x10000, 0x2F0000,
vfs,      data, fat,     0x300000, 0x100000,

I tried to generate another project with esp32 target and esp32 board, it works fine.

Currently due to the limited functionality of the templating system used by cargo-generate, our template files are quite messy. It's also rather difficult to add support for a new chip, and in general I just feel that from a maintainer's perspective this project still leaves a lot to be desired.

I'm proposing we consider restructuring the project to simplify things for us. I have two possible ideas; both of these have the unfortunate side-effect of requiring a fair bit of duplication, however I feel they are both cleaner and will give us much more flexibility than we currently have.

I will outline my ideas below. It may turn out that sticking with our current approach is the right way forward, however I would at least like to discuss these other options.

cc @SergioGasquez

Per-architecture Templates

One possibility is splitting things up into two subdirectories, riscv and xtensa, much in the same way that esp-idf-template is split into cargo and cmake directories.

This removes a lot of the conditional code from our templates, and we are fairly certain that no new Xtensa devices will be released so we can be reasonably confident that this will not change much. Adding support for new devices will always require modifying the riscv template.

Per-device Templates

Taking this even a step further, we could simply have a directory for each supported device. This results in a lot of duplication, however the templates become much simpler and cleaner as a result and we have maximum flexibility. This also makes it trivial to add support for a new device.

My only concern here is that I'm not sure this level of duplication is worth the benefits.

See esp-rs/esp-idf-template#96

I have an esp32-cam-mb (an esp32-cam with a programming mb) and I am able to build and run the idf template (https://github.com/esp-rs/esp-idf-template) out of the box without any alteration. When building the esp-template, I get an error:

~/devel/turingatemyhamster/scratch/cam32-baremetal-blink$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
     Running `espflash flash --monitor target/xtensa-esp32-none-elf/debug/cam32_baremetal_blink`
New version of espflash is available: v2.0.0-rc.3

Error: espflash::connection_failed

  × Error while connecting to device
  ╰─▶ Serial port not found
  help: Ensure that the device is connected and your host recognizes the serial adapter

When I edited the file .cargo/config.toml to replace runner = "espflash flash --monitor" with runner = "espflash --monitor", it succeeded in uploading and running code, although it appears there's some other issue that prevents it reaching the "hello world!" line, but I guess that's another bug report.

For completeness, here is the successful session with esp-idf-template.

~/devel/turingatemyhamster/scratch/cam32-idf-blink$ cargo run
    Finished dev [optimized + debuginfo] target(s) in 0.12s
     Running `espflash --monitor target/xtensa-esp32-espidf/debug/cam32-idf-blink`
New version of espflash is available: v2.0.0-rc.3

Serial port: /dev/ttyUSB0
Connecting...

Chip type:         ESP32 (revision 3)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BT, Dual Core, 240MHz, Coding Scheme None
MAC address:       c8:f0:9e:4d:4c:34
App/part. size:    449296/4128768 bytes, 10.88%
[00:00:01] ########################################      16/16      segment 0x1000                                  [00:00:00] ########################################       1/1       segment 0x8000                                  [00:00:23] ########################################     228/228     segment 0x10000                                 
Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0048,len:12
ho 0 tail 12 room 4
load:0x3fff0054,len:4800
load:0x40078000,len:17448
0x40078000 - __udivmoddi4
    at ??:??
load:0x4007c428,len:4840
0x4007c428 - __udivmoddi4
    at ??:??
entry 0x4007c6a0
0x4007c6a0 - __udivmoddi4
    at ??:??
I (227) cpu_start: Pro cpu up.
I (227) cpu_start: Starting app cpu, entry point is 0x40081164
0x40081164 - call_start_cpu1
    at /home/nmrp3/devel/turingatemyhamster/scratch/cam32-idf-blink/.embuild/espressif/esp-idf/release-v4.4/components/esp_system/port/cpu_start.c:148
I (0) cpu_start: App cpu up.
I (241) cpu_start: Pro cpu start user code
I (241) cpu_start: cpu freq: 160000000
I (241) cpu_start: Application information:
I (246) cpu_start: Project name:     libespidf
I (251) cpu_start: App version:      1
I (255) cpu_start: Compile time:     Mar 13 2023 14:24:44
I (261) cpu_start: ELF file SHA256:  0000000000000000...
I (267) cpu_start: ESP-IDF:          fee50c2-dirty
I (273) cpu_start: Min chip rev:     v0.0
I (277) cpu_start: Max chip rev:     v3.99 
I (282) cpu_start: Chip rev:         v3.0
I (287) heap_init: Initializing. RAM available for dynamic allocation:
I (294) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (300) heap_init: At 3FFB23A8 len 0002DC58 (183 KiB): DRAM
I (306) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (313) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (319) heap_init: At 4008AB20 len 000154E0 (85 KiB): IRAM
I (327) spi_flash: detected chip: generic
I (330) spi_flash: flash io: dio
I (335) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Hello, world!

https://github.com/SergioGasquez/esp-rs-devcontainer

We should probably add an embassy_main macro for Xtensa to make this easier.

Generated a fresh ESP32-C3 project and didn't notice there is a CI workflow. Pushed it to a repository and found the CI failing because cargo-fmt and cargo-clippy don't get installed by the workflow

See https://github.com/bjoernQ/measure-current/actions/runs/6349992065/job/17249073866

Once esp32c6-hal is released we should support it on the template

rust-toolchain.toml can include components and target properties, so it will download them if the user does not have it

I noticed that the caching for Rust did not work. After some investigation, I saw the following errors in Enable Caching step:

Error: Command failed: rustc -vV
Error: error: in /home/runner/work/armo-firmware-rs/armo-firmware-rs/rust-toolchain.toml: invalid toolchain name: 'esp'

Looking at the rust-cache README, I found the following note:

selecting a toolchain either by action or manual rustup calls should happen
before the plugin, as the cache uses the current rustc version as its cache key

Currently, CI workflow enables the cache before setting up Rust, but the two steps should be reversed.

I'm new to rust on embedded systems. I want to use esp-hal instead of esp-idf because idf has lots of stuff and configuration I dont understand, so being more bare metal will help me learn here.

I am attempting to use the alloc crate, it would be great if the cargo generate for this template prompted the user to ask them if they want to use alloc, and gives them a good default global allocator to use, like esp-alloc

I just used cargo generate to create a new project for ESP32C3 with allocations via the esp-alloc crate. When I build I get this warning message:

warning: function `init_heap` is never used
  --> src\main.rs:10:4
   |
10 | fn init_heap() {
   |    ^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

Should I call init_heap() first thing in main()?

I am getting started on the awesome world of embedded-rust, amazing! 🦀

I am not sure, but I didn't found any document related to web-flash.

Also, in the ESP Rust Book I found that the official tool used to flash ESP32 is espflash, that is based on esptool.py.
https://esp-rs.github.io/book/tooling/espflash.html#cargo-espflash
Fortunately, with this tool I could flash the ESP32 successfully.

Could anyone tell me why the template use this web-flash tool instead of espflash?
Thanks in advance! 😃

Similar to esp-rs/esp-idf-template#95, we could add a prompt that remove complex questions (like the alloc, devcontainer, wokwi prompts)

As suggested by @jessebraham in the last community meeting, adding more and more options will make the template (even) harder to maintain and we probably should only generate a minimal project

As @MabezDev mentioned the thing users are struggling the most with is choosing the needed dependencies (and features) - so we probably should generate Cargo.toml even for more advanced configurations (embassy, wifi, ble etc.)

One thing that came to my mind is we could still support at least VSCode users by providing snippets (see https://code.visualstudio.com/docs/editor/userdefinedsnippets) - and even add more convenience

e.g. adding ./.vscode/rust.code-snippets like this

{
	"Construct SPI": {
		"prefix": "setup_spi",
		"body": [
            "//use hal::{IO, spi::{master::Spi, SpiMode}};",
	    "let io = IO::new(peripherals.GPIO, peripherals.IO_MUX);",
            "let sclk = io.pins.gpio$1;",
            "let miso = io.pins.gpio$2;",
            "let mosi = io.pins.gpio$3;",
            "let cs = io.pins.gpio$4;",
            "",
            "let mut spi = Spi::new(peripherals.SPI2, 100u32.kHz(), SpiMode::Mode0, &clocks).with_pins(",
            "    Some(sclk),",
            "    Some(mosi),",
            "    Some(miso),",
            "    Some(cs),",
            ");"
		],
		"description": "Setup SPI"
	}
}

Would give the user an easy way to create an SPI instance. Since snippets are not very powerful, they still need to figure out the right imports - we could just add a local use statement or (like in this very simple example) a commented out use statement which users can manually copy (or remove). Or don't do that and let the user use the quick-fix feature.

We could also have snippets to add dependencies to Cargo.toml instead of generating it (e.g. a snippet to add embassy or esp-wifi)

This way we could also add more elaborate snippets like setting up wifi, ble etc.

But I'm not sure if this is really a very useful thing or just sounds good in my head. I'm also not sure which snippets to include (for me I always have to look up how to setup some peripherals but maybe that's just me)

Downsides of this

• we cannot verify the snippets in CI
• needs some maintenance whenever there are breaking API changes
• might clutter the CTRL+SPACE code completion if we have a lot of these snippets

There is already a board for C6 in Wokwi: https://github.com/wokwi/esp32c6-hello-world/blob/main/diagram.json#LL6C15-L6C39, we should include it in the template to allow simulating c6 projects

The current template is a hollow shell. My wish is that it gets "blinking LED" code.

Benefits I see:

• The whole toolchain can be verified
• There is something that works and can be tweaked ( frequency of LED blinking )

Possible down side: The unwanted source code has to be removed.
(but that is outweighted by all project starts that do need / want something that proves a working target)

Hi!
I generated the sample program from this esp-template but in the .cargo/config.toml
I've finally got:

[target.xtensa-esp32-none-elf]
runner = "espflash flash --monitor"

Since version 2.0 of espflash the --monitor parameter is not valid anymore.

Our current CI takes way too long to run, 10+ minutes, and does not work at all in forks. This makes developing new features much more difficult than it needs to be.

There is some low-hanging fruit, such as ldproxy (not sure why this is being installed?), but I'm not sure if that will be enough by itself to get us to more reasonable run times.

As discussed with the community, we will drop Gitpod support as GH Codespaces is also available for everyone and does not need any extra files.

I think the current cargo_generate_version = ">=0.10.0" is too old for the features the template uses - not sure which is the minimum version, it definitely works with 0.17.6 (which I have installed)