owned this note
owned this note
Published
Linked with GitHub
## esp-rs esp32s3 training help
Drop questions down below on a new line and check back for answers & help.
# Questions
## Flashing error
× Communication error while flashing device
╰─▶ Timeout while running WriteReg command
I've tried different cables, checking my serial port, I'm getting the same error on two different computers (linux and M1 mac)
- What cargo-espflash version are you using?
> cargo-espflash 1.5.1
- Try updating to `1.7`: `cargo install cargo-espflash --force`
- That fixed it! Thanks!
## Monitoring withouth flashing
If you only want to open a serial monitor withouth reflashing the board you can run `cargo espflash monitor /dev/SERIAL_DEVICE`
- If no serial device is specified, `cargo-espflash` will list the available targets, so you can choose from the list.
## Project
```
git clone -b esp32s3 git@github.com:SergioGasquez/espressif-trainings.git
```
## cfg.toml editing
When changing values in cfg.toml, must one `cargo clean` afterward for the changes to be picked up by a `cargo build`?
- I think this might be the case, can't hurt to do a clean build if its not picking up the new details
- ~~It shouldn't be required to clean to pick up `cfg.toml` changes (the `build.rs` exists for our `http-client` crate, but doesn't emit any rerun-if-changed statements, so cargo defaults to considering all files within the crate to be relevent for a rebuild, and will rebuild things when it sees file timestamps change).~~ (except I overlooked that cfg.toml is in the gitignore, so it won't be considered as long as one has a valid git repo. `touch main.rs` is enough to get a rebuild though, no need to clean)
- Just ran a quick test, no `cargo clean` is required. I built a simple project which prints the SSID, flashed it, changed the `cfg.toml`, flashed again with no cleaning and the modification of the `cfg.toml` was shown.
I asked because I built the project, flashed it, and was told "Error: missing WiFi name." Then I updated cfg.toml with my wifi SSID/password, rebuilt the project, reflashed it, and was told the same thing. Then I `cargo clean`-ed, rebuilt and flashed the project, and it didn't give me that error.
## The http server exercise doesn't build
- Remove any reference to the temperature sensor, the s3 devkit doesn't have one - sorry we forgot to remove it before hand!
-
## HTTP Server typo
[The instructions to run the example](https://espressif-trainings.ferrous-systems.com/03_4_http_server.html#setup) have a small typo, a missing "r" at the end of `http_server`. It should be:
```
cargo espflash --release --example http_server --monitor $SERIALDEVICE
```
## HTTP Server troubleshoot
### Implementation of `FnOnce` is not general enough
Any tips for troubleshooting this compilation error:
```rs
server.set_handler("/", Method::Get, |request, response| {
Ok(())
})?;
```
```
error: implementation of `FnOnce` is not general enough
--> src/main.rs:40:5
|
40 | / server.set_handler("/", Method::Get, |request, response| {
41 | | Ok(())
42 | | })?;
| |______^ implementation of `FnOnce` is not general enough
|
= note: closure with signature `fn(esp_idf_svc::http::server::EspHttpRequest<'2>, esp_idf_svc::http::server::EspHttpResponse<'_>) -> Result<(), HandlerError>` must implement `FnOnce<(esp_idf_svc::http::server::EspHttpRequest<'1>, esp_idf_svc::http::server::EspHttpResponse<'1>)>`, for any lifetime `'1`...
= note: ...but it actually implements `FnOnce<(esp_idf_svc::http::server::EspHttpRequest<'2>, esp_idf_svc::http::server::EspHttpResponse<'_>)>`, for some specific lifetime `'2`
```
I change the original suggestion of `server.set_inline_handler()` to `server.set_handler()` since this method doesn't seem to exist?
- Using `.handle_get()` from the [book](https://espressif-trainings.ferrous-systems.com/03_4_http_server.html) seems to work for me.
- I have had success with `handle_get()` as well.
- Looking at type signatures, I'd guess that something about type coercion of the closure makes `handle_get()` work while `set_handler()` is unhappy.
Joe: I'll give a +1 to the suggestion to use `handle_get`. I was also following the guidance in the code and tripped, but following the guidance in the book entry set me on the path to success.
### Missing Wifi name
I am getting this error when trying to run the skeleton code in intro/http-server.
```
I (319) heap_init: At 600FE000 len 00002000 (8 KiB): RTCRAM
I (326) spi_flash: detected chip: generic
I (330) spi_flash: flash io: dio
I (335) sleep: Configure to isolate all GPIO pins in sleep state
I (341) sleep: Enable automatic switching of GPIO sleep configuration
I (349) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Error: missing WiFi name
```
If I copy/paste the same code in the intro/http-client folder I am able to run it. Any resolution?
Resolved by changing the crate name. Copy/paste error.
- Check the section name in your `cfg.toml` file. The text in the `[]` square brakets. It needs to match the crate name in the `Cargo.toml`
### Alternative to a temp sensor
I declared an identifier named `counter` in the main function, and implemented a hit counter at `/counter`. It forced me to deal with shared mutable data much like the temp sensor would have.
## MQTT publish troubleshoot
Joe: I tried using an empty `Vec<u8>` for the payload, and found that I was getting an apparent crash and reboot. Switching to an empty slice per the example fixed this. Why?
- I think this maybe because an empty Vec may not have any data associated with it. Internally within the Mqtt client it uses to slice pointer to calculate the length of the message (this is happening in esp-idf side of things). I believe someone has already submitted a fix here: https://github.com/esp-rs/esp-idf-svc/issues/146 but isn't included in the version we're using for the training.
## Wokwi
- [Rust on ESP](https://wokwi.com/rust)
- Some exercise from the training (for esp32c3) are also available:
- [intro/hardware-check](https://wokwi.com/projects/334080865809203794)
- [intro/http-client](https://wokwi.com/projects/333372159510446675)
- [intro/http-server](https://wokwi.com/projects/334083021941506642)
- [intro/mqtt](https://wokwi.com/projects/333374379294458451)
- [GDB Debugging](https://docs.wokwi.com/gdb-debugging)