07:30 <TiagoManczak[m]> https://www.edacentrum.de/rvf

08:13 <thejpster[m]> > https://github.com/rust-lang/rfcs/pull/3759 adds supported targets to Cargo.toml. The primary purpose is to reduce packages in cargo vendor but was left as a future possibility to keep scope small. It also considered erroring if you depended on a package on an unsupported platform but that was pushed off because people were concerned if people published over-constrained "supports" on crates.io so we also deferred that.

08:13 <thejpster[m]> https://rust-lang.zulipchat.com/#narrow/stream/436762-wg-embedded/topic/Supported.20Targets.20RFC/near/518342819

08:13 <thejpster[m]> Ed Page would love input about whether that feature is useful to us.

09:53 <RobinMueller[m]> I have a question about the RMT peripheral of the ESP32 (https://github.com/esp-rs/esp-hal/blob/main/esp-hal/src/rmt.rs). Is it possible to re-configure the channel after creation? Basically, I want to reconfigure the data pin to be low or an input pin when my neopixel is switched off. Maybe there is an even simpler way? The RMT peripheral the the smart LED adapter abstraction all consume/convert the resources I pass into

09:53 <RobinMueller[m]> them.

09:54 <RobinMueller[m]> s/./.. I could just steal the data pin and reconfigure it on mode transitions, but then the pulsing doese not work, probably because the peripheral mapping is overwritten?/

09:55 <RobinMueller[m]> * I have a question about the RMT peripheral of the ESP32 (https://github.com/esp-rs/esp-hal/blob/main/esp-hal/src/rmt.rs). I use it to drive a Neopixel lightstrip. Is it possible to re-configure the channel after creation? Basically, I want to reconfigure the data pin to be low or an input pin when my neopixel is switched off. Maybe there is an even simpler way? The RMT peripheral the the smart LED adapter abstraction all

09:55 <RobinMueller[m]> consume/convert the resources I pass into them.. I could just steal the data pin and reconfigure it on mode transitions, but then the pulsing doese not work, probably because the peripheral mapping is overwritten?

09:56 <RobinMueller[m]> * I have a question about the RMT peripheral of the ESP32 (https://github.com/esp-rs/esp-hal/blob/main/esp-hal/src/rmt.rs). I use it to drive a Neopixel lightstrip. Is it possible to re-configure the channel after creation? Basically, I want to reconfigure the data pin to be low or an input pin when my neopixel is switched off. Maybe there is an even simpler way? The RMT peripheral the the smart LED adapter abstraction all

09:56 <RobinMueller[m]> consume/convert the resources I pass into them.. I could just steal the data pin and reconfigure it on mode transitions, but then the pulsing doese not work anymore when the lightstrip is on again, probably because the peripheral mapping is overwritten?

09:58 <RobinMueller[m]> (is there an ESP matrix/chat channel? :D)

09:58 <Ralph[m]> RobinMueller[m]: https://matrix.to/#/#esp-rs:matrix.org

09:59 <RobinMueller[m]> thanks!

10:41 <KevinPFleming[m]> I've got a weird code-generation/optimization issue. Here's the code involved:... (full message at <https://catircservices.org/_irc/v1/media/download/AYUEnpFKbh64gD18mj3NCnU52IgBFM-DowicPWZMa0wOYLqi5jK5cLbU694ITXS1D0gbDt4M0g2anqLQNAxCufW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9XUGNTWEFTdW9RWlV3ZFlMREpiSW5nblo>)

10:51 <KevinPFleming[m]> In case it matters, `rx.message_buf` is a `heapless::Vec::<u8, 128>`.

10:57 <jason-kairos[m]> is the disassembly small enough to make sense of?

10:58 <jason-kairos[m]> I'd speculate that it's probably pulling in a new function (and more error checking logic)

11:00 <jason-kairos[m]> in my experience copying around data between slices/buffers/etc. in rust is quite slow for reasons that are adjacent to what I mentioned above. It can be quite the task to trick the compiler into generating the proper implementation

11:02 <KevinPFleming[m]> I haven't looked at the disassembly yet... I'll have to try that tomorrow.

11:02 <KevinPFleming[m]> I'm fine with using the for-loop, of course, I'll leave a comment in the source for why it's open-coded instead of using the library :-)

19:32 <okhsunrog[m]> <KevinPFleming[m]> "I am using protobuf, with the..." <- I saw a project where they had problems using micropb. Not sure what caused them, but everything started working smoothly once they migrated to postcard-rpc.... (full message at

19:32 <okhsunrog[m]> <https://catircservices.org/_irc/v1/media/download/AZhaYjIfmDrhI7wtJZ2sxyGBTIenLxZ4oWzS5ZZQqKhX6oHTg8vTfFdnnh_tuRijJAhkKh_2emZpCMScNKsWUUS_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9ZSXJHWXNnTGdLTk9ra0JDa2VXTVZQS1k>)

19:33 <okhsunrog[m]> okhsunrog[m]: Catherine: what did you end up using?

21:16 <GuineaWheek[m]> someday i hope we can get a rust where having firmware that actually fits on flash (with opt-level=s/z, codegen-units=1, lto=true) and a firmware that emits a non-zero amount of breakpointable lines becomes a reality

22:15 <Mathias[m]> Some of us learned this week at RustWeek that you might prefer opt-level=s on Arm targets. And codegen-units=1 does not improve size (and is worse for compilation speed?). Source: Cliff Biffle’s talk (https://rustweek.org/talks/cliff/)

22:46 <KevinPFleming[m]> I'm using 's' already, and codegen-units=1 does improve code size for me. My project is small enough that even doubling compilation time would not be an issue.