!LdaNPfUfvefOLewEIM:matrix.org

esp-rs

1133 Members
Using Rust on the ESP series microcontrollers. https://github.com/esp-rs | https://matrix.to/#/#esp-rs-community-meetins:matrix.org | https://esp-rs.github.io/book/110 Servers

Load older messages


SenderMessageTime
6 Dec 2022
@ivmarkov:matrix.orgivmarkov
In reply to @mabez:matrix.org
This seems like a good change to me, I remember having to do 100+ as casts when I tried to get mbedtls working. Semantically it makes sense too, usize is the rust equivalent of size_t
zredshift: Shall we bite the bullet then?
09:36:12
@arg2u:matrix.orgagaliullin set a profile picture.09:36:17
@zredshift:matrix.orgzredshift

Albin Hedman: I looked at the log, and saw the symbols it was missing

/home/decahe/iot-lte/.embuild/espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/esp_netif/libesp_netif.a(esp_netif_lwip_defaults.c.obj):/home/decahe/iot-lte/.embuild/espressif/esp-idf/release-v5.0/components/esp_netif/lwip/esp_netif_lwip_defaults.c:51: undefined reference to `esp_netif_lwip_ppp_input'

I searched for the function name in esp-idf:
https://github.com/espressif/esp-idf/blob/v5.0/components/esp_netif/lwip/esp_netif_lwip_ppp.c#L274
I looked for the filename:
https://github.com/espressif/esp-idf/blob/v5.0/components/esp_netif/CMakeLists.txt#L22-L25
looking for CONFIG_PPP_SUPPORT it's the deprecated name for CONFIG_LWIP_PPP_SUPPORT
https://github.com/espressif/esp-idf/blob/v5.0/components/lwip/sdkconfig.rename#L31

that's the best way to fix linker errors, for future reference

09:41:40
@zredshift:matrix.orgzredshift
In reply to @ivmarkov:matrix.org
zredshift: Shall we bite the bullet then?
sure
09:42:01
@usbalbin:matrix.orgAlbin Hedman
In reply to @zredshift:matrix.org

Albin Hedman: I looked at the log, and saw the symbols it was missing

/home/decahe/iot-lte/.embuild/espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/esp_netif/libesp_netif.a(esp_netif_lwip_defaults.c.obj):/home/decahe/iot-lte/.embuild/espressif/esp-idf/release-v5.0/components/esp_netif/lwip/esp_netif_lwip_defaults.c:51: undefined reference to `esp_netif_lwip_ppp_input'

I searched for the function name in esp-idf:
https://github.com/espressif/esp-idf/blob/v5.0/components/esp_netif/lwip/esp_netif_lwip_ppp.c#L274
I looked for the filename:
https://github.com/espressif/esp-idf/blob/v5.0/components/esp_netif/CMakeLists.txt#L22-L25
looking for CONFIG_PPP_SUPPORT it's the deprecated name for CONFIG_LWIP_PPP_SUPPORT
https://github.com/espressif/esp-idf/blob/v5.0/components/lwip/sdkconfig.rename#L31

that's the best way to fix linker errors, for future reference

Oh, thanks. That is really good to know!
09:42:32
@zredshift:matrix.orgzredshift ivmarkov: I noticed the accursed esp_app_desc patch didn't make into v5.0, for some reason, I'll also add it to esp-idf-sys if you'd like 09:45:34
@michael.desilva:matrix.orgmichael.desilva
In reply to @ivmarkov:matrix.org
And one more: even if you passed a big-enough buffer to read, you have no warranty that all of the input will be read in a single pass. Mentioning this as you might stumble on that next. :) Basically you have to read in a loop, until read returns you 0 bytes read (with a non-empty buffer, that is). STD had something like read_fully or whatever and a bunch of utilities for working with Vec. You can transform the native embedded-io Read into STD Read to use those. But read_fully is also dangerous, as then malicious folks can crash your firmware with out of mem.
This is interesting https://doc.rust-lang.org/src/std/io/mod.rs.html#706-708
09:46:29
@michael.desilva:matrix.orgmichael.desilvaAre everyone now upgrading to IDFv5?09:47:02
@michael.desilva:matrix.orgmichael.desilva * Are everyone now upgrading to IDFv5? is it just changing ESP_IDF_VERSION = { value = "branch:release/v4.4" } or there's more to do? 09:47:38
@ivmarkov:matrix.orgivmarkov zredshift: By the way - and on the topic of ISR timers - I suggest you switch to the timer to using a regular timer dispatch task with CONFIG_ESP_EVENT_POST_FROM_ISR=n until the ESP IDF enhancement request below is implemented. In the meantime I'll likely also temporarily disable the support for the embassy ISR queue, so you'll have to (temporarily) switch to the built-in timer queue from embassy-time: https://github.com/espressif/esp-idf/issues/10250 09:47:47
@michael.desilva:matrix.orgmichael.desilva * Are everyone now upgrading to IDFv5? is it just changing ESP_IDF_VERSION = { value = "branch:release/v4.4" } or there's more to do? Do I have to re-build my ESP toolchain? 09:48:09
@ivmarkov:matrix.orgivmarkov
In reply to @zredshift:matrix.org
ivmarkov: I noticed the accursed esp_app_desc patch didn't make into v5.0, for some reason, I'll also add it to esp-idf-sys if you'd like
Thank you!
09:48:26
@ivmarkov:matrix.orgivmarkov
In reply to @michael.desilva:matrix.org
Are everyone now upgrading to IDFv5? is it just changing ESP_IDF_VERSION = { value = "branch:release/v4.4" } or there's more to do? Do I have to re-build my ESP toolchain?
No it is not, you have to uncomment the rustflags here: https://github.com/ivmarkov/rust-esp32-std-demo/blob/main/.cargo/config.toml
09:49:42
@michael.desilva:matrix.orgmichael.desilva
In reply to @ivmarkov:matrix.org
No it is not, you have to uncomment the rustflags here: https://github.com/ivmarkov/rust-esp32-std-demo/blob/main/.cargo/config.toml
Thanks.
09:53:38
@zredshift:matrix.orgzredshift

ivmarkov mabez : we're using bindgen 0.60 in embuild in esp-idf-sys when bindgen 0.63 is out
0.61 has these interesting changes:

 * The `--enable-function-attribute-detection` flag is also used to detect
   diverging functions so the generated bindings use `!` as the return type.
 * The `--size_t-is-usize` flag is enabled by default.
 * The `core::ffi` module is used the sized raw integer types
   instead of `std::os::raw` if the Rust target version is `1.64` or higher and
   the `--use-core` flag is enabled.
 * new feature: `--merge-extern-blocks` flag to merge several `extern` blocks
   that have the same ABI.
10:15:32
@ivmarkov:matrix.orgivmarkov
In reply to @zredshift:matrix.org

ivmarkov mabez : we're using bindgen 0.60 in embuild in esp-idf-sys when bindgen 0.63 is out
0.61 has these interesting changes:

 * The `--enable-function-attribute-detection` flag is also used to detect
   diverging functions so the generated bindings use `!` as the return type.
 * The `--size_t-is-usize` flag is enabled by default.
 * The `core::ffi` module is used the sized raw integer types
   instead of `std::os::raw` if the Rust target version is `1.64` or higher and
   the `--use-core` flag is enabled.
 * new feature: `--merge-extern-blocks` flag to merge several `extern` blocks
   that have the same ABI.
I guess (3) is the proof that I made a mistake originally. Let's upgrade tolatest bindgen in embuild
10:21:58
@mabez:matrix.orgmabez
In reply to @zredshift:matrix.org

ivmarkov mabez : we're using bindgen 0.60 in embuild in esp-idf-sys when bindgen 0.63 is out
0.61 has these interesting changes:

 * The `--enable-function-attribute-detection` flag is also used to detect
   diverging functions so the generated bindings use `!` as the return type.
 * The `--size_t-is-usize` flag is enabled by default.
 * The `core::ffi` module is used the sized raw integer types
   instead of `std::os::raw` if the Rust target version is `1.64` or higher and
   the `--use-core` flag is enabled.
 * new feature: `--merge-extern-blocks` flag to merge several `extern` blocks
   that have the same ABI.
Oh wow I totally missed that ctypes are in core now. I guess that means we can remove https://github.com/esp-rs/esp-idf-sys/blob/master/src/lib.rs#L48-L89? I also think there is a similar (but different enough :D) definition in rust-mbedtls which could be removed too
10:27:41
@zredshift:matrix.orgzredshiftyep, I'm on it10:27:57
@zredshift:matrix.orgzredshiftI kinda want to bump some embuild dependencies other than bindgen, but I'll refrain for now10:28:19
@zredshift:matrix.orgzredshift
~/.../local/embuild >>> cargo upgrade --dry-run                                                                                                                                                                                                                                                        ±[●][master]
    Updating 'https://github.com/rust-lang/crates.io-index' index
    Checking cargo-pio's dependencies
name       old req compatible latest new req note        
====       ======= ========== ====== ======= ====        
env_logger 0.9     0.9.3      0.10.0 0.9     incompatible
structopt  0.3.22  0.3.26     0.3.26 0.3.26              
tempfile   3.2     3.3.0      3.3.0  3.3                 
    Checking embuild's dependencies
name       old req compatible latest new req note        
====       ======= ========== ====== ======= ====        
shlex      1.0     1.1.0      1.1.0  1.1                 
xmas-elf   0.8     0.8.0      0.9.0  0.8     incompatible
cargo_toml 0.12    0.12.4     0.13.0 0.12    incompatible
which      4.1     4.3.0      4.3.0  4.3                 
tempfile   3.2     3.3.0      3.3.0  3.3                 
ureq       2.1     2.5.0      2.5.0  2.5                 
    Checking ldproxy's dependencies
name       old req compatible latest new req note        
====       ======= ========== ====== ======= ====        
env_logger 0.9     0.9.3      0.10.0 0.9     incompatible
note: Re-run with `--incompatible` to upgrade incompatible version requirements
note: Re-run with `--verbose` to show all dependencies
  unchanged: anyhow, bindgen, bitflags, cmake (dep-cmake), dirs, embuild, filetime, globwalk, log, remove_dir_all, serde, serde_json, strum, thiserror, toml
warning: aborting upgrade due to dry run
10:28:45
@zredshift:matrix.orgzredshift *
~/.../local/embuild >>> cargo upgrade --dry-run
    Updating 'https://github.com/rust-lang/crates.io-index' index
    Checking cargo-pio's dependencies
name       old req compatible latest new req note        
====       ======= ========== ====== ======= ====        
env_logger 0.9     0.9.3      0.10.0 0.9     incompatible
structopt  0.3.22  0.3.26     0.3.26 0.3.26              
tempfile   3.2     3.3.0      3.3.0  3.3                 
    Checking embuild's dependencies
name       old req compatible latest new req note        
====       ======= ========== ====== ======= ====        
shlex      1.0     1.1.0      1.1.0  1.1                 
xmas-elf   0.8     0.8.0      0.9.0  0.8     incompatible
cargo_toml 0.12    0.12.4     0.13.0 0.12    incompatible
which      4.1     4.3.0      4.3.0  4.3                 
tempfile   3.2     3.3.0      3.3.0  3.3                 
ureq       2.1     2.5.0      2.5.0  2.5                 
    Checking ldproxy's dependencies
name       old req compatible latest new req note        
====       ======= ========== ====== ======= ====        
env_logger 0.9     0.9.3      0.10.0 0.9     incompatible
note: Re-run with `--incompatible` to upgrade incompatible version requirements
note: Re-run with `--verbose` to show all dependencies
  unchanged: anyhow, bindgen, bitflags, cmake (dep-cmake), dirs, embuild, filetime, globwalk, log, remove_dir_all, serde, serde_json, strum, thiserror, toml
warning: aborting upgrade due to dry run
10:29:51
@zredshift:matrix.orgzredshifthttps://github.com/esp-rs/embuild/pull/66/files10:32:11
@zredshift:matrix.orgzredshift * https://github.com/esp-rs/embuild/pull/6610:35:20
@zredshift:matrix.orgzredshift https://github.com/esp-rs/esp-idf-sys/pull/157
ivmarkov mabez
11:09:19
@zredshift:matrix.orgzredshift I want to rerun the CI when the embuild patch is merged and a new version is released on crates.io
I'm concerned about no_std risc v due to the c_char/c_uchar issue
11:18:06
@zredshift:matrix.orgzredshifthttps://github.com/esp-rs/esp-idf-hal/pull/18512:23:04
@ivmarkov:matrix.orgivmarkov
In reply to @zredshift:matrix.org
https://github.com/esp-rs/esp-idf-hal/pull/185
There are some API changes as well, so I guess it is safest to bump up the minor version as well.
13:06:48
@zredshift:matrix.orgzredshiftin esp-idf-sys too I think13:07:15
@zredshift:matrix.orgzredshiftand in embuild13:07:19
@zredshift:matrix.orgzredshiftesp-idf-svc soon13:07:38

There are no newer messages yet.


Back to Room List